BlogCambio de sistema
Cambio de sistema: ensayo, corte y condiciones para volver atrás
Volver al sistema anterior después de capturar pedidos nuevos requiere reconciliar datos. Decide esa condición antes de hacer el cambio.
Hoja de prueba: Cambio de sistema: plan de corte y reversa
Volver al sistema anterior después de capturar pedidos nuevos requiere reconciliar datos. Decide esa condición antes de hacer el cambio. Registra datos, resultado esperado, evidencia, responsable y resultado observado.
Define la ventana según tu operación
El horario menos ocupado no siempre es el mejor para cambiar. Una transportista puede despachar de madrugada; una distribuidora recibe pedidos al cierre; una fábrica mantiene equipos en turno continuo. Elige una ventana con responsables disponibles y una forma acordada de registrar trabajo si el sistema queda detenido. Anota la zona horaria y el último documento válido del sistema anterior.
Microsoft recomienda presentar procedimientos de reversa probados y definir autoridad para la decisión. AWS distingue regresar antes de que cambien los datos de hacerlo después de nuevas transacciones. Esa diferencia también aplica a un sistema de negocio: cambiar una dirección de acceso no resuelve por sí solo los datos creados durante el corte.
Ejemplo ficticio: 24 pedidos y dos capturas posteriores
Una distribuidora ensaya detener su sistema anterior a las 18:00. El archivo de control contiene 24 pedidos abiertos y sus reservas. A las 18:20 el equipo valida el sistema nuevo; a las 18:25 captura N-025 y N-026. A las 18:30 falla la impresión de rutas. Este caso es sintético y no representa una migración realizada por Nightly.
Si se vuelve a la copia de las 18:00, N-025 y N-026 no existen allí. Antes de reabrir, el responsable debe decidir si corregir la impresión en el sistema nuevo o exportar y registrar esos pedidos en el anterior, conservando sus referencias y evitando reservas dobles. El ensayo debe incluir ambas rutas posibles. No se propone escritura simultánea en dos sistemas sin una reconciliación diseñada.
| Momento | Pregunta para continuar | Condición para detener |
|---|---|---|
| Antes de congelar captura | ¿Copia, usuarios e integraciones están listos? | Falta un acceso o recuperación ensayada |
| Después de importar | ¿Cuadran pedidos y reservas por estado? | Diferencias sin explicación |
| Antes de admitir trabajo nuevo | ¿El equipo completa el flujo crítico? | No puede despachar o confirmar |
| Después de nuevas capturas | ¿La reversa conserva cada operación nueva? | No hay una reconciliación ejecutable |
Ensaya con personas y dependencias disponibles
La prueba necesita más que abrir la página principal. Incluye consulta, captura, autorización, impresión y exportación, además de archivos adjuntos y conexiones externas. Un conector que sigue leyendo del sistema anterior puede producir información contradictoria aunque la interfaz nueva funcione. Define quién pausa cada tarea automática y quién comprueba su reanudación.
| Caso del ensayo | Resultado esperado | Evidencia que conservar |
|---|---|---|
| Congelar a las 18:00 | Ningún pedido nuevo entra al sistema anterior | Último folio y registro de bloqueo |
| 24 pedidos abiertos | Mismos importes y reservas por pedido | Comparación identificada |
| Repetir el lote inicial | Sin nuevos pedidos ni reservas duplicadas | Conteos y referencias |
| Falla antes de nuevas capturas | Regreso al sistema anterior dentro del plazo acordado | Cronología del ensayo |
| Falla después de N-025 y N-026 | Ambas operaciones sobreviven una sola vez | Conciliación de pedidos |
| Conector reanudado | Retoma desde el punto acordado, sin reenviar trabajo cerrado | Registro del conector |
Escribe una reversa que realmente se pueda ejecutar
Cada paso necesita responsable, requisito, duración observada y comprobación final. «Restaurar respaldo» deja preguntas abiertas: qué versión, dónde, con qué credenciales y qué ocurre con los archivos y trabajos pendientes. El tiempo empieza cuando se declara la interrupción y termina cuando el negocio puede completar el flujo acordado. Prueba la restauración de respaldos por separado antes del corte.
Fija la hora límite para tomar la decisión y el canal de comunicación. Si una comprobación se retrasa, marca desconocido; no lo conviertas en aprobado por silencio. Las restricciones del proveedor, la velocidad de transferencia y la disponibilidad del equipo condicionan el plan. Un ensayo fallido es información para corregir el alcance o cambiar la fecha, no una razón para ocultar el problema.
Cierra el corte con una revisión posterior
Durante el periodo acordado, revisa documentos creados, diferencias y tareas pendientes, no solo disponibilidad. Conserva el sistema anterior de la manera permitida por tu contrato y política de datos; no lo elimines porque la primera pantalla respondió. Para identidades consulta migrar datos sin duplicados, y para criterios de entrega usa pruebas de aceptación de negocio.
En la hoja descargable, completa hora, dueño y resultado observado del ensayo antes de reservar la ventana real. Con un calendario operativo, inventario de conexiones y muestra de pedidos anonimizados, una consulta gratuita de consultoría de software puede ayudar a delimitar qué debe demostrarse antes de cambiar.
Relacionado
Preguntas frecuentes
No. La copia puede no contener trabajo creado después. Además, recuperar la base no garantiza recuperar archivos, accesos o conectores. El ensayo debe comprobar el flujo del negocio y documentar cómo conservarás operaciones nuevas.
Solo cuando existe una regla explícita sobre dónde se escribe y cómo se comparan resultados. Capturar el mismo pedido en dos sistemas sin claves y conciliación puede duplicar trabajo. Mantener uno en consulta puede ser más sencillo que permitir escritura doble.
Una persona autorizada por el negocio debe tener la decisión, apoyada por quienes verifican datos y operación. Déjalo escrito con condiciones y hora límite. El proveedor puede informar el riesgo técnico; la aceptación de la operación corresponde al responsable acordado.
Derívalo de un ensayo comparable y deja margen para verificar y comunicar. El tamaño del archivo no basta: importan dependencias, permisos, personas e integraciones. No prometas una duración con una prueba que solo midió la copia de la base.
Fuentes
- Cutover stageAWS
- Plan your migrationMicrosoft
Última actualización: