Migrar de Excel a un sistema: qué validar antes de contratar
Para migrar de Excel a un sistema multiusuario, primero comprobá que no alcance con mejorar la colaboración en la planilla o configurar un producto existente. Si necesitás desarrollo, contratá un proceso acotado con reglas documentadas, permisos por rol y un ensayo de migración y corte. Copiar las filas a una aplicación no prueba que la operación esté resuelta.
Primero comprobá si hace falta salir de Excel
Que varias personas editen una planilla no obliga a contratar un sistema nuevo. Microsoft documenta coautoría en Excel con versiones compatibles, formatos admitidos y almacenamiento en OneDrive o SharePoint Online. Revisá esas condiciones con IT antes de atribuir los bloqueos a una limitación inevitable del producto.
La decisión cambia cuando necesitás controlar operaciones: quién puede modificar cada registro, qué estados habilitan un cambio y cómo se resuelven dos actualizaciones sobre el mismo pedido. Anotá el incidente concreto que querés evitar. Un archivo lento, una fórmula incorrecta y una aprobación sin responsable requieren intervenciones diferentes.
Tampoco confundas coautoría con automatización concurrente. La documentación del conector Excel Online (Business) indica que no admite modificaciones simultáneas del mismo archivo desde varios clientes o conectores y advierte sobre conflictos e inconsistencias. Es una condición de ese conector, consultada el 3 de noviembre de 2026; no una prohibición general de colaborar en Excel.
Compará tres caminos con el mismo proceso
Pedí que cada alternativa complete una operación representativa: crear un registro, corregirlo, aprobarlo y consultarlo desde otro rol. Incluí una excepción real del proceso con datos ficticios. La siguiente matriz es un criterio de evaluación propuesto por Duotach, no un benchmark ni una recomendación universal.
| Camino | Cuándo evaluarlo | Qué comprobar |
|---|---|---|
| Excel con colaboración ordenada | Las reglas y el acceso al archivo alcanzan | Versiones compatibles, permisos y recuperación |
| Plataforma configurable | Un producto existente cubre el circuito | Reglas, roles, exportación e integraciones en una prueba |
| Aplicación a medida | Queda una brecha operativa concreta | Reglas por registro, conflictos y migración aceptados |
La unidad de migración es la regla, además de la fila
Antes de pedir presupuesto, elegí un circuito acotado. Por ejemplo: desde que se recibe una solicitud interna hasta que queda aprobada. Identificá archivos de entrada, columnas calculadas, listas auxiliares, macros, adjuntos y reportes que consumen el resultado. Un total visible puede depender de una excepción que sólo conoce quien mantiene la planilla.
Armá una correspondencia por campo: columna de origen, significado, regla de transformación, destino y responsable de validar. Conservá identificadores como texto cuando sus ceros iniciales importen; distinguí un vacío de un cero y una fecha de un texto que parece fecha. No elimines duplicados por nombre sin una regla de identidad aceptada.
Acordá qué histórico se importa, qué queda disponible para consulta y cómo se conserva el origen. Si hay datos personales o información restringida, el acceso a las muestras y al entorno de ensayo debe estar autorizado. El proveedor no necesita una copia irrestricta de todos los archivos para una primera conversación comercial.
Un ensayo ficticio para comparar propuestas
Imaginá una planilla de solicitudes con tres filas: S-001 pendiente por 120 unidades; S-002 aprobada por 80; S-003 anulada por 50. El resultado esperado del ensayo es conservar tres solicitudes y sumar 80 unidades aprobadas. Son datos inventados para mostrar la prueba; no un caso de cliente ni un resultado de Duotach.
Agregá una segunda fila S-002 con otra cantidad. El sistema debe aplicar la política acordada: rechazar el conflicto o enviarlo a revisión, conservando evidencia. No debe inventar una identidad ni elegir silenciosamente la última fila. Pedí un registro de importados, rechazados y pendientes que permita reconciliar el archivo completo.
Después, dos usuarios abren S-001. Uno modifica la cantidad y el otro intenta aprobar una versión anterior. La prueba debe mostrar el comportamiento contratado: advertir el cambio y exigir revisión, o aplicar otra política explícita que el negocio haya aceptado. Tener una base de datos no demuestra por sí solo que ese control esté construido.
Acordá el corte y el tratamiento de movimientos nuevos
El ensayo y la carga final son momentos diferentes. Entre ambos pueden entrar solicitudes, correcciones y anulaciones. Definí una hora de corte con zona horaria, quién deja la planilla en sólo lectura y cómo se trasladan los cambios posteriores a la copia usada en el ensayo.
Para cada etapa, designá un único origen autorizado para registrar operaciones. Si necesitás comparar ambos sistemas, usá una copia de consulta o un procedimiento de reconciliación; dos fuentes editables sin una regla de sincronización recrean el problema que querías resolver.
El plan de vuelta atrás debe contemplar las operaciones aceptadas por el sistema nuevo. Restaurar el archivo anterior no incorpora automáticamente esos movimientos. Acordá cómo se exportan, quién los reconcilia y qué condición obliga a posponer el corte. Hacé el ensayo en un entorno separado, con responsables de operaciones e IT.
Qué evidencia pedir antes de aceptar la migración
Usá criterios escritos antes de construir. La tabla siguiente propone controles para adaptar al proceso: no acredita que una aplicación o proveedor ya los cumpla. Si una prueba falla, registrá el dato afectado y repetí la reconciliación después de corregirlo.
Una demo con registros nuevos puede mostrar pantallas sin probar el histórico, los permisos ni los conflictos. Pedí evidencia sobre la misma versión candidata a entrega y sobre el mismo lote autorizado. Para código, accesos y documentación, completá esta revisión con la guía de entrega de software a medida.
| Control | Prueba propuesta | Evidencia |
|---|---|---|
| Datos | Reconciliar identidades, cantidades y estados | Origen de cada registro y diferencias explicadas |
| Reglas | Repetir cálculos y excepciones conocidas | Resultado esperado frente al obtenido |
| Permisos | Intentar cambios desde un rol sin autorización | Acción bloqueada también fuera de la pantalla |
| Concurrencia | Editar y aprobar versiones distintas | Conflicto resuelto según la política acordada |
| Corte | Incorporar una corrección posterior al ensayo | Movimiento presente una sola vez en el destino |
Qué cambia el alcance de la propuesta
Compará por separado relevamiento, reconstrucción de reglas, limpieza, carga inicial, integraciones, permisos, ensayo de corte y acompañamiento. El peso del archivo no alcanza para cotizar: una hoja pequeña puede contener macros y excepciones que cambien todo el circuito.
Definí cuántos procesos entran, quién resuelve datos dudosos, qué histórico se conserva y cuáles son las pruebas de aceptación. Acordá también infraestructura, licencias y mantenimiento posterior. No presupongas que una aplicación propia elimina costos recurrentes ni que incluye cualquier cambio futuro.
La IA puede proponer correspondencias o ayudar a documentar fórmulas, pero esas propuestas necesitan revisión. No hace falta agregar IA al sistema final para resolver permisos, estados y concurrencia. La condición de aceptación sigue siendo que las reglas y los datos acordados funcionen.
Consultar por un sistema para tu operación
Duotach desarrolla software a medida para empresas. Si el proceso necesita una aplicación propia, contanos qué registra hoy la planilla, quién la usa, qué sistemas intervienen y qué control falta. La consulta permite conversar sobre el alcance; el relevamiento de archivos y las pruebas específicas se acuerdan como trabajo pago.
El resultado buscado es un circuito que tu equipo pueda operar y aceptar con evidencia. Esta guía no fija una tarifa, un plazo de entrega ni un ahorro: dependen del proceso, los datos, las dependencias y las condiciones contratadas.
Definí el primer circuito
Contanos qué registra tu planilla y qué control necesita el equipo.
