Migración de datos: qué acordar antes de cambiar de sistema

1. Escribe qué se traslada y qué seguirá en el origen

Un mensaje de «importación completada» describe una ejecución. Para aceptar el cambio, el equipo necesita comprobar también sus registros, relaciones y recorridos de trabajo. Esta guía propone una ficha para preparar esa conversación, sin asumir que cualquier sistema permite exportar o importar todo lo necesario.

Empieza por una tarea reconocible: consultar pedidos pendientes, continuar atenciones o preparar un reporte operativo. Luego identifica la información que esa tarea utiliza. Una propuesta que diga solamente «migrar la base de datos» deja abiertas decisiones que afectan el proyecto.

Completa esta ficha copiable con referencias internas autorizadas. Para la primera conversación basta describir los conjuntos; no adjuntes bases de clientes ni credenciales. El alcance puede separar datos activos e históricos, pero esa decisión necesita al responsable del proceso. No elimines información como efecto secundario de la migración.

Oracle incluye la selección, correspondencia, transformación y comprobación de datos dentro de la planificación de un ERP; sus instrucciones son una referencia de ese contexto, no una obligación de usar su producto.

Desliza la tabla si no ves todas las columnas.

2. Acuerda cómo comparar antes de cargar

Dos sistemas pueden representar de manera distinta un mismo pedido. Define qué significa cada estado, qué identificador permanece y cómo se resolverán campos vacíos o valores que el destino no admite. Si se corrige un dato, conserva una relación entre el original, la regla aplicada y el resultado.

La comparación debe usar el mismo conjunto y momento de referencia. Si el origen sigue recibiendo operaciones mientras revisas el destino, una diferencia podría corresponder a un cambio posterior. Documenta cómo se distinguirán esos cambios de los errores de traslado.

Las herramientas pueden apoyar esta comprobación. Por ejemplo, AWS DMS compara filas entre origen y destino y reporta diferencias en los escenarios que admite; su documentación también advierte del consumo adicional de recursos al validar. Eso no demuestra que cualquier ERP sea compatible con DMS ni sustituye la revisión del proceso de negocio.

3. Usa criterios de aceptación que el negocio pueda revisar

Ejemplo ficticio: una distribuidora cambia su aplicación de pedidos. El alcance aprobado contiene 200 clientes y 500 pedidos abiertos, todos en CLP, con un monto total de pedidos de $18.000.000 en la fecha de corte. Los números solo ilustran la ficha: no describen a un cliente ni el resultado de un proyecto de Digital Dev.

Conteos y totales coincidentes pueden ocultar errores que se compensan entre sí. Por eso la ficha combina controles globales, identificadores, relaciones y revisión del contenido. Acordar que no se aceptarán duplicados establece una condición del ejemplo; no garantiza que una ejecución vaya a cumplirla.

Registra cada control como cumplido, pendiente o no cumplido, con evidencia y responsable. Evita cerrar un pendiente solo porque la carga terminó. La guía de AWS para pequeñas y medianas empresas incluye conciliación, integridad, pruebas de usuarios y revisión de integraciones como parte de la validación. La tabla siguiente es una propuesta editorial propia.

Desliza la tabla si no ves todas las columnas.

4. Ensaya la transición y asigna la decisión

Antes del cambio real, prepara un ensayo autorizado en un entorno de prueba. Elige datos y volumen representativos con la protección correspondiente; registra duración observada, errores, correcciones y resultados. Una muestra pequeña sirve para probar reglas, pero no permite prometer la duración de la carga completa.

La planificación de Microsoft para Dynamics 365 contempla ensayar el cambio, asignar responsables y establecer quién decide si se puede entrar en producción. La aplicación concreta depende del proyecto. Para tu ficha, deja estas tres decisiones por escrito. La fecha se acuerda con esa evidencia y con la disponibilidad de las personas necesarias; no se deduce del tamaño del archivo ni de una demostración comercial.

• Ejecución: quién realiza y registra la carga y quién atiende una falla de acceso o del proveedor.
• Aceptación: quién comprueba los datos y el recorrido; qué condiciones impiden empezar a operar.
• Coordinación: quién autoriza continuar, posponer o aplicar la contingencia, y cómo informa a los equipos afectados.

5. Define la reversión considerando las operaciones nuevas

Volver al sistema anterior requiere saber qué ocurrió desde el cambio. Si ya se registraron pedidos o modificaciones en el destino, el origen podría haber quedado desactualizado. El plan debe indicar cómo identificar y tratar esas operaciones antes de retomar el trabajo.

AWS distingue la reversión sin nuevos datos de aquella que debe manejar transacciones posteriores al cambio. La referencia trata migración a AWS; aquí se utiliza únicamente para explicar esa diferencia, sin trasladar una receta técnica a cualquier ERP.

Pide una contingencia viable y ensayada para tus aplicaciones: condición que la activa, responsable, punto recuperable y comprobación de lo que seguirá pendiente. Un respaldo aislado no resuelve por sí solo el tratamiento de operaciones nuevas. No asumas reversión instantánea ni ausencia de pérdida de información.

6. Lleva una ficha concreta a la cotización

Para comenzar, prepara los nombres de ambos sistemas, el proceso que cambiará, los conjuntos incluidos y una excepción que hoy cueste resolver. Añade quién puede facilitar documentación y accesos autorizados. La revisión permitirá distinguir el traslado inicial de una integración continua por API o webhooks.

Pide que la propuesta separe preparación de datos, desarrollo o configuración, ensayo, carga, aceptación y acompañamiento posterior. Los costos de exportación, licencias o intervención de otros proveedores deben identificarse cuando correspondan. Si también cambia el equipo que mantiene la aplicación, utiliza la guía de recepción de software de otro proveedor.

¿Estás preparando un cambio de sistema? Cuéntanos qué aplicaciones participan, qué proceso debe continuar y qué datos necesitas trasladar. En Digital Dev podemos revisar el contexto para delimitar el trabajo de software e integración y las comprobaciones necesarias antes de proponer una implementación.

Criterio editorial y alcance de las fuentes

Guía institucional de Digital Dev, elaborada con asistencia de IA. Ficha y ejemplo de aceptación propios; referencias técnicas identificadas en el texto. No se atribuye revisión personal a un integrante del equipo ni experiencia en productos específicos por enlazar su documentación.