[Blog]()Cambio 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. **[Jonathan Perez]()**Cofundador · Diseño, producto y ventas 8 de octubre de 2026 · 7 min de lectura **Respuesta breve** Un plan de corte debe indicar cuándo deja de escribir el sistema anterior, qué valida el negocio y quién autoriza continuar o volver atrás. Ensaya la recuperación y decide cómo tratarás operaciones creadas después del cambio. Restaurar una copia anterior sin reconciliarlas puede perder pedidos, cobros o movimientos. ## 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. [Descargar hoja CSV]() En esta guía - [Define la ventana según tu operación]() - [Ejemplo ficticio: 24 pedidos y dos capturas posteriores]() - [Ensaya con personas y dependencias disponibles]() - [Escribe una reversa que realmente se pueda ejecutar]() - [Cierra el corte con una revisión posterior]() ## 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. ## Revisemos tu ensayo de cambio y reversa Tu último ensayo y el calendario de cierres permiten discutir cuándo cortar, qué fallo detendría el cambio y qué operaciones nuevas tendrías que conciliar para volver. Podemos revisarlos en una consulta gratuita. - Calendario de pedidos, despachos y cierres críticos - Lista de conectores, impresoras y responsables - Último ensayo con tiempos y operaciones nuevas por reconciliar [Agendar diagnóstico gratuito]()[Consultar por WhatsApp]() Relacionado - [Consultoría de software]() - [Software a la medida]() ## Preguntas frecuentes ### ¿Una copia permite volver atrás automáticamente? 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. ### ¿Conviene operar ambos sistemas al mismo tiempo? 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. ### ¿Quién decide cancelar el cambio? 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. ### ¿Cuánto tiempo debo reservar? 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 1. [Cutover stage]()AWS 2. [Plan your migration]()Microsoft Última actualización: 8 de octubre de 2026 ## Sigue leyendo [Migración de datos8 oct 2026 ### Migrar datos sin duplicados: claves, conflictos y revisión antes de importar]()[Continuidad operativa8 oct 2026 ### Un respaldo no basta: cómo probar restauración, pérdida y tiempo de regreso]()[Aceptación de software8 oct 2026 ### Cómo aceptar un sistema: pruebas de negocio y pendientes verificables]() --- Canonical: https://nightlysoftware.com/blog/corte-sistema-plan-reversa Updated: 2026-10-08 Description: Ensaya el cambio de sistema, define quién puede detenerlo y revisa cómo recuperar operaciones nuevas. Descarga la hoja de corte y reversa.