Arquitectura y despliegue
Migración y modernización: cambiar de plataforma sin dejar de operar
01 · Inventario
- Funciones y datos
- Integraciones e informes
02 · Ensayo
- Migración de prueba
- Validación de conteos y totales
03 · Paralelo
- Dual run acotado
- Comparación de resultados
04 · Corte
- Criterios acordados
- Plan de vuelta atrás ensayado
05 · Retirada
- Seguimiento de adopción
- Apagado del sistema antiguo
El problema
Por qué hay que decidirlo bien
Las migraciones fallan más por la planificación que por la tecnología. Un fin de semana de corte que se alarga, datos que no cuadran el lunes, una integración olvidada que deja de recibir ficheros o usuarios que siguen usando el sistema viejo porque el nuevo no hace algo que daban por hecho. Cuando ocurre, si no hay forma de volver atrás, la empresa queda atrapada entre dos sistemas a medias. El reto es reducir la incertidumbre antes del corte: inventariar, ensayar, comparar resultados y decidir con criterios acordados cuándo se da el paso.
Escenarios
Situaciones en las que se plantea
Ejemplos de lo que se podría diseñar. No describen proyectos realizados.
01
Traslado de servidores propios a la nube
Una aplicación que lleva años en un servidor local debe pasar a la nube. Se empaqueta, se reproduce el entorno, se migra una copia de los datos para ensayar y se planifica el corte con una ventana y un plan de reversión acordados.
02
Cambio de motor de base de datos
La base de datos actual pierde soporte. Se mapean tipos, procedimientos y consultas, se migran los datos con validaciones automáticas de conteos y sumas de control y se ejecuta la aplicación contra ambos motores para comparar resultados.
03
Ejecución en paralelo antes del corte
Durante un periodo acordado, las operaciones se procesan en el sistema antiguo y en el nuevo. Se comparan resultados como facturas, saldos o existencias, y las diferencias se investigan hasta que quedan explicadas o corregidas.
04
Migración por grupos de usuarios
En lugar de un corte único, se traslada primero una sede o un departamento. Su experiencia permite corregir problemas de datos, formación y procesos antes de extender el cambio al resto de la organización.
Decisiones técnicas
Qué hay que decidir y con qué criterio
01
Inventario y fases
Se recogen funciones, datos, integraciones, tareas programadas e informes del sistema actual. Con ese mapa se definen fases con un objetivo verificable cada una y un punto de decisión antes de pasar a la siguiente.
02
Contratos de datos e interfaces
Cada integración con otros sistemas se documenta con su formato, frecuencia y responsable. Si el nuevo sistema cambia algo, se acuerda con los sistemas consumidores o se mantiene una capa de compatibilidad temporal.
03
Migración de datos verificable
Scripts repetibles en lugar de copias manuales, ensayos completos con datos reales anonimizados si procede, conteos, totales y muestras comparadas, y un registro de los datos que no pudieron migrarse y por qué.
04
Ejecución en paralelo (dual run)
Se fija qué se compara, durante cuánto tiempo y qué nivel de diferencia es aceptable. La ejecución paralela consume esfuerzo de los usuarios, así que su duración se acota y se justifica.
05
Criterios de corte y vuelta atrás
Antes del corte se acuerdan las condiciones para darlo por bueno y las que obligan a revertir. El procedimiento de reversión, incluida la recuperación de los datos generados tras el corte, se ensaya como parte del plan.
06
Adopción por parte de los usuarios
Formación práctica, documentación breve de los cambios, personas de referencia en cada equipo y un canal para reportar problemas en las primeras semanas. Retirar el sistema antiguo solo cuando su uso real ha cesado.
Riesgos y límites
Lo que conviene tener presente
- Siempre aparece alguna función o integración no documentada; el inventario reduce el riesgo, pero no lo elimina.
- La vuelta atrás se complica con cada día que pasa tras el corte, porque los datos nuevos también deben devolverse al sistema antiguo.
- La ejecución en paralelo duplica temporalmente el trabajo y puede generar cansancio si se alarga sin criterios claros.
- No siempre es posible migrar sin interrupción; la ventana de parada, si la hay, se estima tras estudiar datos y dependencias.
Preguntas frecuentes
¿Se puede migrar sin parar el servicio?
A veces, con sincronización continua de datos y cambio gradual del tráfico, pero no siempre compensa ni es posible. Se valora tras estudiar volumen, dependencias y ventanas disponibles, y se acuerda con el negocio la parada aceptable.
¿Cuánto debe durar la ejecución en paralelo?
Lo suficiente para cubrir los ciclos relevantes del negocio, por ejemplo un cierre mensual si afecta a facturación. Se fija al inicio con criterios de salida claros para no alargarla indefinidamente.
¿Migrar y modernizar a la vez es buena idea?
Depende del riesgo. Cambiar plataforma y funcionalidad simultáneamente dificulta saber qué causa cada diferencia. A menudo conviene trasladar primero con cambios mínimos y modernizar después, aunque no es una regla fija.
Sectores, capacidades y lecturas relacionadas
Sectores donde se plantea
Capacidades relacionadas
- Modernización legacySustituir por partes un software antiguo que sigue sosteniendo la operación, empezando por entender bien qué hace.
- Integraciones ERPConectar el ERP con tiendas, almacenes, CRM o herramientas de campo para que pedidos, facturas y existencias no se gestionen dos veces.
- Integración de sistemasConexiones entre aplicaciones que mueven datos con reglas claras, detectan errores y permiten saber qué versión de cada dato es la buena.
Más en arquitectura y despliegue
Cuéntanos qué sistema quieres trasladar y de qué depende hoy tu operación
Ninguna modalidad está disponible por defecto en todos los proyectos: se elige tras evaluar requisitos, sistemas existentes y riesgos.
Sin compromiso de aceptación: estudiamos cada caso antes de proponer nada. Cómo tratamos la información que compartes.