El fin de semana de corte

🌐 También en 19 idiomas

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Українська · Français (Canada) · Deutsch (Schweiz)

Imagen generada con IA

Traducido con IA. Aún no revisado por la comunidad. Leer en inglés Esta sección cambió en inglés y aún no se ha vuelto a traducir. (2)

Módulo 4 de 5 del capítulo Migración y sincronización, capítulo 10 del curso Data Architect. Cada módulo se sostiene por sí solo. Anterior: La automatización durante la carga · Siguiente: Sacar los datos: mantener otro sistema sincronizado

La pregunta que responde este módulo: ¿cómo haces el cambio, y cómo demuestras que la migración funcionó?

Es viernes por la noche. Los usuarios se han ido, el equipo de migración está conectado y alguien dice: “Lo hemos probado tres veces. Adelante”. De acuerdo. ¿Qué es exactamente lo que vamos a hacer? ¿Cuándo deja de cambiar el sistema antiguo? ¿Cuándo es la extracción final? ¿Quién desactiva la automatización, quién lanza cada carga? ¿Y si a medianoche llevamos dos horas de retraso, o falla el 3 por ciento de las cuentas? ¿Quién decide si seguimos? ¿Cómo demostramos que los datos están bien, y cuándo pueden volver los usuarios? Y si sale mal: ¿cómo salimos? El corte no es “ejecutar la migración”. Es una transición controlada de un estado conocido a otro.

Empieza por el dibujo

Aquí está nuestro panorama una vez más. Este es el fin de semana en que se ejecuta esa flecha ámbar, y luego desaparece.

Clic para ampliar

El fin de semana en que se ejecuta esta flecha. El lunes por la mañana, ya no está.

Pero ese fin de semana cambia más que una flecha. Los manifiestos de los socios dejan de llegar a RouteDesk y empiezan a llegar a través de la capa de integración. Los envíos salientes del propio RouteDesk, el archivo de estado nocturno de Keystone y el webhook de Redrock, tienen que salir ahora de Salesforce. Los coordinadores planifican las rutas de las entregas del lunes en Field Service, no en RouteDesk. Y el lunes por la mañana, 330 camiones salen de los centros de distribución con rutas del nuevo sistema. Todo en este módulo trata de llegar a ese lunes con seguridad, y de saber qué haríamos si no pudiéramos.

Producción debería ser aburrido

Quiero que el corte en producción resulte casi decepcionante. Ya hemos ejecutado el proceso, lo hemos cronometrado, hemos visto los fallos, hemos probado los bypasses, hemos conciliado los resultados y hemos practicado la vuelta al funcionamiento normal. Producción es el mismo guion con datos nuevos. Si estamos inventando la migración el fin de semana de corte, ya estamos en apuros.

Eso exige un ensayo general, no “cargamos las cuentas en el sandbox”. De principio a fin: una extracción como la final, las transformaciones, los controles de calidad, la secuencia de carga, los controles de automatización e integración, la conciliación, el procesamiento aplazado, la vuelta al modo normal, todo cronometrado, a escala de producción o representativa, en un sandbox Full. Registra cuánto tardó cada paso, qué falló, qué necesitó ayuda manual, qué confundió a la gente, dónde esperamos, qué nos sorprendió. Luego mejora el runbook. El primer ensayo te enseña cómo funciona la migración; el siguiente debería demostrar que aprendiste. Y como el módulo 2 trajo las claves de vuelta, un ensayo no tiene que empezar desde cero cada vez: corrige una transformación, recarga solo las filas que tocó y vuelve a ejecutar la conciliación. Para RouteDesk, eso significa el fin de semana completo en un sandbox Full: la extracción, el almacén de datos de preparación, las oleadas del módulo 1, el bypass del módulo 3, el cambio de los envíos de los socios y la conciliación, con un cronómetro en marcha.

El runbook es arquitectura ejecutable

No “sábado por la mañana: migrar los datos”. Algo más parecido a:

Paso	Acción	Responsable	Duración prevista	Prueba / criterio de salida
1	Confirmar que RouteDesk es de solo lectura tras el último camión del sábado	Responsable de operaciones	10 min	Confirmación por escrito; hora del último cambio registrada
2	Extracción final de RouteDesk al almacén de datos de preparación	Equipo de datos	45 min	Recuentos y totales de control capturados
3	Confirmar el bypass en el usuario de migración	Equipo de Salesforce	10 min	Un registro de prueba se guarda sin enviar eventos de estado
4	Carga incremental: los cambios del sábado, upsert por la clave del socio	Equipo de migración	30 min	Resultados e ID nuevos de vuelta en el almacén de datos de preparación
5	Conciliar con las cifras esperadas	Equipo de datos y operaciones	30 min	Recuentos, totales e informes agregados aprobados
6	Pasar los manifiestos y los envíos de estado de los socios a la capa de integración	Equipo de integración	30 min	Un manifiesto de prueba con upsert y un estado enviado, por socio
…	…	…	…	…
14	Quitar el bypass al usuario de migración	Equipo de Salesforce	10 min	Conjunto de permisos desasignado, y comprobado

Ahora sabemos qué pasa, quién lo hace, cuánto esperamos que tarde y qué demuestra que cada paso está completo. Eso es mucho más sólido que una lista de comprobación que dice “Cargar órdenes de trabajo”. Fíjate en el paso 14. El bypass del módulo 3 es un permiso para saltarse reglas de negocio, así que quitarlo es un paso del runbook con un responsable, no algo que esperamos que alguien recuerde.

Día −7, día −1, día 0

Llamo a la puesta en producción el Día 0: normalmente un domingo u otro día fuera del horario laboral. Steve Trucking entrega seis días a la semana, así que el Día 0 es el domingo sin camiones en la carretera. El Día +1 es el posterior; el Día −1 y el Día −7 son anteriores. Y en cualquier carga grande, pregunto: ¿tengo que esperar al Día 0 para cargar todos los datos? Si la carga tarda horas y el origen sigue cambiando, voy a necesitar una carga incremental de todas formas. Así que:

• Día −7: la carga inicial. Carga la mayor parte de los datos una semana antes, mantenidos invisibles mediante el uso compartido, para que los usuarios y los informes no los vean. Los usuarios de pruebas de humo (un administrador del sistema) los validan donde están. Pregunta al negocio qué se vería perjudicado por cargar pronto; si la respuesta es “me rompería los informes”, cárgalos ocultos. Es mucho más sencillo abrir el uso compartido el Día 0 que pasar cinco horas cargando un millón de registros y todos sus hijos dentro de la ventana.
• Día −1: la carga de actualización. Trae lo que cambió desde el día −7, y protege la línea de salida: ¿siguen los usuarios cambiando el origen?, ¿están escribiendo las integraciones?, ¿se están ejecutando trabajos programados? Congela el origen, ponlo en solo lectura o define exactamente cómo se capturarán los cambios posteriores a la extracción.
• Día 0: el incremental. Carga lo que cambió desde el día −1 (a veces un incremental al principio de la ventana y uno final al terminar), concilia, decide el go o el no-go, abre el uso compartido y restablece el funcionamiento normal.

Para RouteDesk, el Día −7 es el domingo anterior: entran las 190.000 órdenes de trabajo entregadas, ocultas mediante el uso compartido, y los usuarios de pruebas de humo las revisan durante toda la semana. El historial apenas cambia, así que la mayor parte de la carga está hecha antes de que empiece el fin de semana. El Día −1 es el sábado por la noche, cuando ha vuelto el último camión: RouteDesk pasa a ser de solo lectura, y la actualización trae los cambios de la semana. El Día 0 es el domingo: una pequeña carga incremental y luego los controles de paso.

Clic para ampliar

Día −7: la mayor parte de los datos, una semana antes, donde nadie puede verlos todavía.

Clic para ampliar

Día −1: los cambios de la semana, y el origen deja de moverse.

Clic para ampliar

Día 0: una pequeña carga incremental y luego los controles de paso.

Clic para ampliar

Día +1: sale el primer camión, y se agota el reloj de la reversión.

No es una forma inusual de hacer el corte; es la habitual, con otros nombres. La propia orientación de Salesforce para trasladar un sitio de B2C Commerce dice que hay que migrar todos los datos que se pueda “lo más cerca posible antes del corte real. Idealmente, durante el corte solo debería hacer falta copiar la diferencia respecto al día anterior, para minimizar el tiempo de inactividad” (B2C Commerce Realm Split FAQ (se abre en una pestaña nueva), Salesforce Help). La orientación de Microsoft para su propia plataforma es una migración completa “alrededor de un mes antes de la puesta en producción, seguida de cargas semanales de diferencias”, con la diferencia final “después de congelar los sistemas de origen y de destino” (Data migration planning for go-live (se abre en una pestaña nueva), Microsoft Learn). Y el servicio de migración de bases de datos de AWS incorpora la misma idea: una carga completa mientras captura los cambios, y luego “detén tus aplicaciones y deja que los cambios restantes fluyan hacia el destino” (Components of AWS DMS (se abre en una pestaña nueva), AWS; las tres consultadas el 2026-10-27). Los plazos cambian con el volumen: un mes o una semana antes, diferencias semanales o diarias. El matiz de Salesforce es el que añado yo: cargar pronto oculto mediante el uso compartido, para que los datos estén en su sitio y revisados, y nadie los vea hasta el Día 0.

Conocimiento para el examen. Para una migración grande con una ventana de corte corta, carga la mayor parte de los datos días antes, ocultos a los usuarios mediante el uso compartido, y luego carga solo lo que cambió (una actualización antes de la ventana, una carga incremental dentro de ella). Congela o captura los cambios del origen desde la extracción en adelante, y valida con usuarios de prueba antes de abrir el acceso.

Para el corte, lo importante son los controles de paso en torno a esas cargas. Para el Día −7 ya no quiero estar diseñando la migración: las correspondencias, las transformaciones, la secuencia de carga, las decisiones sobre la automatización, los usuarios de migración, los informes de conciliación, el runbook, los criterios de reversión y las excepciones conocidas están estables, porque han empezado las cargas reales. Las cosas todavía pueden cambiar, pero cada cambio tardío reduce el ensayo. En algún momento dejas de mejorar la migración y empiezas a proteger el corte. Y sabe cuándo dejó de moverse el origen, o sabe exactamente cómo capturarás lo que cambió después de tu extracción.

Esa segunda mitad es la marca de agua: el punto hasta el que estaba al día cada extracción, para que la siguiente carga sepa qué cambió desde entonces. Para RouteDesk, la marca de agua es el momento de cada extracción: todo lo que RouteDesk cambió después de la extracción del Día −7, el domingo, está en la actualización del sábado. Eso solo funciona si RouteDesk registra cuándo cambió por última vez una entrega, así que comprueba que lo hace, y que las pantallas de cada centro de distribución lo actualizan. Si no, compara instantáneas: vuelve a extraer y encuentra las diferencias por clave. Más lento, pero es una marca de agua en la que puedes confiar. Sin ella, procesar las diferencias es una conjetura.

Luego, el día 0 es ejecución. Sigue el runbook, anota las horas reales, los ID de trabajo, los recuentos, los errores y las decisiones. Si falla el paso 17, no saltes al 24 porque alguien crea que ahorra tiempo: entiende la dependencia, usa el procedimiento de recuperación, actualiza el estado. El equipo debería poder decir siempre dónde estamos, qué está completo, qué ha fallado, qué viene después y si seguimos dentro de la ventana.

Deja fuera a los usuarios cuando necesites control

A nadie le gusta el tiempo de inactividad. Pero fingir que el sistema está disponible mientras cambiamos sus cimientos puede ser peor, y “queremos cero tiempo de inactividad” no debe convertirse en silencio en “no tenemos ni idea de qué versión de los datos tiene la autoridad”. A veces la estrategia más limpia es dejar fuera a los usuarios, hacer el corte, demostrar el resultado y dejarlos volver. ¿Cómo?

• Las formas duras: congelar a los usuarios, cambiar sus horas de inicio de sesión o restringir los rangos de IP. No los desactives: eso rompe la propiedad y todo lo que cuelga de ella.
• La forma suave: un flujo de inicio de sesión (login flow) que deja entrar a la gente y la lleva a una sala de espera: “el sistema está en mantenimiento; vuelve más tarde”. Más amable que unos errores que hacen pensar a los usuarios que su cuenta está rota. Nunca pongas ese flujo de inicio de sesión a los administradores del sistema; si se rompe, no entra nadie.
• Deja siempre una puerta trasera: un grupo de administradores del sistema (y tus usuarios de prueba) que puedan seguir entrando.
• Las sesiones persisten. Dejar fuera a los usuarios no cierra las sesiones que ya están abiertas, así que planifica cómo sacar a la gente que sigue trabajando: un aviso, una hora límite o, con trabajo a medida, una forma de cerrarles la sesión.

En Steve Trucking es domingo, así que las personas para las que hay que planificar son los agentes de atención que contestan al teléfono, los coordinadores que se preparan para el lunes y los 300 usuarios de los socios minoristas que podrían entrar en el portal para consultar una reclamación. Los flujos de inicio de sesión se asignan por perfil (Custom Login Flows (se abre en una pestaña nueva), Salesforce Help, consultado el 2026-10-27), así que el perfil de los socios puede recibir la sala de espera (“tus entregas se están trasladando a un sistema nuevo; volvemos el lunes a las 6 de la mañana”) mientras los usuarios de pruebas de humo y los administradores entran y salen.

No te lo inventes la semana anterior. Decide qué vivirán los usuarios, y díselo.

Conocimiento para el examen. Para mantener fuera a los usuarios durante un corte, congela sus cuentas, restringe el horario de inicio de sesión o los intervalos de IP, o usa un flujo de inicio de sesión (asignado por perfil) como sala de espera. No desactives a los usuarios: rompe la propiedad y lo que cuelga de ella. Mantén la posibilidad de iniciar sesión para los administradores y los usuarios de prueba.

Go/no-go, y el reloj de la reversión

A las 2:00 de la madrugada, con doce horas a cuestas, no es el momento de inventar los criterios de go/no-go. Defínelos antes del corte: objetos críticos conciliados, tasa de fallos por debajo de un umbral aprobado, ningún defecto crítico de datos sin resolver, relaciones obligatorias validadas, integraciones críticas verificadas, automatización restablecida y probada, rendimiento aceptable, validación de negocio hecha, tiempo suficiente para los pasos posteriores. Si no, “go” se convierte en “ya hemos llegado hasta aquí”. Eso no es arquitectura. Es el sesgo del coste hundido.

“Tenemos un plan de reversión.” Bien. ¿Hasta cuándo? Migramos, abrimos Salesforce y durante seis horas los usuarios crean casos, actualizan cuentas, introducen oportunidades, cambian datos de contacto, mientras las integraciones envían datos a otros sitios. ¿Podemos restaurar el viernes por la noche? No sin perder trabajo legítimo. La reversión se complica cuanto más tiempo funciona el sistema nuevo, así que define el punto de reversión: antes de él, volvemos al estado anterior con el procedimiento probado; después de él, la recuperación necesita otra estrategia. La reversión tiene un reloj, y el runbook debería mostrarlo. Para Steve Trucking el reloj es fácil de leer: hasta que el primer camión del lunes salga con una ruta de Field Service, todavía podemos devolver a los coordinadores a RouteDesk, por eso sigue en solo lectura y sin tocar hasta entonces. Después, cada entrega hecha, cada foto tomada y cada estado enviado vive solo en Salesforce, y volver atrás perdería trabajo real. A partir de ese momento, recuperarse significa corregir hacia delante.

Revertir tampoco es solo borrar lo que cargaste. La automatización puede haber creado hijos, las integraciones pueden haber enviado registros a otros sitios, los usuarios pueden haber cambiado registros migrados, puede haber archivos adjuntos, eventos publicados, registros existentes actualizados. Los efectos distribuidos son la razón por la que los controles de automatización e integración del módulo 3 son arquitectura del corte.

¿Y qué te hace revertir? Según mi experiencia, rara vez es el cargador. Son los datos desconocidos: descubres que se pasó por alto algo clave, o que había un envío de datos en marcha que nadie había tenido en cuenta. El mejor plan de reversión es no necesitarlo: conoce todos tus datos clave, y cada envío que los toca, antes del corte. RouteDesk tiene dos que es fácil olvidar, porque salen, no entran: el archivo de estado nocturno que recoge Keystone y el webhook que le dice a Redrock lo que pasó. Retira RouteDesk sin trasladarlos, y el lunes por la noche Keystone no recibe nada. Nadie cargó datos erróneos; simplemente se detuvo un envío.

Cuatro formas en que demuestro los datos

Después de la carga no pregunto “¿dijo la API que todo fue bien?”. Quiero cuatro tipos de prueba, y uso los cuatro: recuentos, totales, comprobaciones puntuales e informes agregados.

Recuentos. ¿Cuántos registros deberían existir, y cuántos existen? Cuentas de origen seleccionadas: 500.000. Duplicados consolidados: 20.000. Excluidas por una política aprobada: 5.000. Previstas: 475.000. En el destino: 475.000. Bien, pero los recuentos por sí solos no son una prueba; puedes tener el número correcto de registros y los datos equivocados.

Totales. Donde los números importan, compara totales de control: importe de las facturas, valor de los pedidos, saldo pendiente, cantidad. Los dos sistemas tienen 100.000 facturas, pero el heredado suma 412.800.000 dólares y Salesforce 398.100.000. Alto. Los totales revelan lo que se les escapa a los recuentos.

Comprobaciones puntuales. Mira registros reales, no solo los fáciles: uno sencillo y uno complejo, un cliente grande y uno pequeño, uno con muchos hijos, uno que se transformó, uno que pasó por la desduplicación, uno con un historial inusual. Rastrea cada uno del origen al destino: campos, relaciones, propiedad, historial, External ID. Las medias esconden fallos individuales graves.

Informes agregados. Compara la forma: cuentas por estado, pedidos por año, casos por estado, clientes por segmento, ingresos por mes. Si el origen dice 82.000 clientes en Arizona y Salesforce dice 8.200, tenemos una pista: un código de estado que no se mapeó, un año excluido, un estado mal traducido, un archivo saltado. El recuento de filas puede parecer correcto mientras la distribución cuenta la historia.

Para RouteDesk, cada prueba tiene su comprobación, y cada una detecta algo que las demás no ven.

Clic para ampliar

Cada prueba detecta lo que las demás no ven. Usa las cuatro.

El informe agregado es el que miraría primero. Recuerda los códigos de estado del módulo 1: nueve centros de distribución, nueve formas de escribirlo. Si las entregas por semana del CD 7 salen un 40 por ciento por debajo de las de RouteDesk, puede que el recuento de toda la carga parezca cercano, pero el DONE/INST de un centro de distribución no se convirtió.

Conocimiento para el examen. Demuestra una migración con algo más que “sin errores”: recuentos de registros frente a cifras esperadas fijadas antes de la carga, totales de control de los importes que importan, comprobaciones puntuales de registros reales rastreados de principio a fin, e informes agregados que comparan la forma de los datos. Los responsables de negocio también la validan.

Van con dos reglas. Primera, fija las cifras previstas antes de la carga (módulo 1): recuento del origen, exclusiones aprobadas, duplicados consolidados, registros en cuarentena, destino previsto. Luego compara y explica la diferencia. Una cifra prevista inventada después de ver el resultado no es conciliación; es racionalización. Segunda, cero errores puede seguir estando mal. Mapea Billing State en Shipping State y todas las filas se cargan sin errores de API: una ejecución técnica perfecta, una arquitectura equivocada. Por eso importa la conciliación de negocio, no solo los registros técnicos.

Los responsables de negocio también validan

El equipo técnico puede demostrar los recuentos, las claves, las relaciones y el éxito de la carga. Los usuarios de negocio reconocen lo que nosotros no: “estos no son nuestros clientes activos”, “ese estado no se usa desde 2022”, “estas cuentas pertenecen a la región equivocada”, “este cliente debería tener tres contratos activos”. Así que la validación de negocio es un paso explícito de la puesta en marcha, con personas con nombre, informes con nombre, registros con nombre y una aprobación con nombre, no “échale un vistazo cuando tengas tiempo”.

La autoridad cambia de manos el Día 0

¿Por qué no moverlo todo el día 0? El Número de Ceros. Si la migración completa tarda 18 horas y el negocio tolera 4 horas de inactividad, tenemos un problema, y mover los datos antes lo resuelve. El historial entra antes del corte mientras el sistema heredado sigue teniendo la autoridad; la ventana solo tiene que ocuparse de lo que cambió, de lo que no pudo cargarse antes, de las relaciones finales, la validación y la conciliación. En lugar de mover ocho años de historial durante la interrupción, estamos cerrando una brecha.

Pero los datos cargados antes necesitan protección. Si los datos de producción llegan el día −7, ¿pueden verlos los usuarios, editarlos, puede reaccionar la automatización, pueden publicarlos las integraciones, pueden actuar sobre ellos los agentes? La respuesta debería ser: todavía no. Así que los mantenemos ocultos mediante el uso compartido, con propietario y bajo control, con la automatización y las integraciones retenidas (módulo 3). Una carga previa no es “meter los registros antes”. Es meterlos antes sin dar por accidente la autoridad al sistema nuevo antes de tiempo.

Antes del corte, el sistema heredado tiene la autoridad y Salesforce guarda una copia preparada y cada vez más actual. Durante el corte cerramos la diferencia. En el momento acordado, la autoridad cambia de manos, y después Salesforce tiene la autoridad. Para Steve Trucking ese momento es el Día 0: a partir de entonces, la verdad de una entrega vive en Salesforce, y RouteDesk es un registro de solo lectura del pasado. Ahí es donde se encuentran los capítulos 6, 9 y 10: identificar los registros, la autoridad, el movimiento y el corte no son problemas separados; son vistas del mismo ciclo de vida de los datos.

Así que no dejes que dos sistemas crean a la vez que son el maestro. Si el sistema heredado sigue siendo editable después del corte, un coordinador cambia una franja de entrega en Salesforce, otro la cambia en el sistema heredado, y los dos sistemas creen que son sus dueños. ¿Gana la última escritura? ¿Gana Salesforce? ¿Revisión humana? Si eso queda sin respuesta, no hemos terminado una migración; hemos creado dos copias editables. La regla del capítulo 9: el permiso técnico no es autoridad de arquitectura.

No toda migración necesita una sincronización continua. Si sustituimos por completo el sistema heredado, llega el Día 0, se cargan las diferencias finales, la conciliación se supera, los usuarios se trasladan, el sistema antiguo pasa a solo lectura y con el tiempo se archiva o se retira. No construyas una integración permanente porque “las migraciones suelen tener integraciones”. Si el sistema antiguo está muerto, deja de alimentarlo. Ese es RouteDesk: el lunes es de solo lectura, luego se retira, y nada se sincroniza con él. La sincronización que sí necesita Steve Trucking es otra flecha, de Salesforce a Snowflake, diseñada en el capítulo 9 y tratada en el módulo 5.

Clic para ampliar

La diferencia se cierra, la autoridad cambia de manos y la migración termina. El envío a Snowflake continúa.

También ocurre lo contrario. Una transición que dura meses, usuarios activos en los dos sistemas, unidades de negocio que se trasladan en momentos distintos: puede que la sincronización tenga que empezar antes de que termine la migración. Ahora la migración sigue moviendo la base histórica mientras la sincronización mantiene coherentes los registros vivos, y esa es una arquitectura mucho más difícil. Necesitas saber qué proceso es dueño de qué cambios, o la carga y la sincronización se sobrescribirán entre sí. Así que define la frontera de forma visible: antes de este punto estamos construyendo el estado de destino; después de él estamos manteniendo la coherencia. Puede ser una marca de tiempo, un evento de corte, la transición de una unidad de negocio, un cambio objeto a objeto, una marca de agua. Si nadie sabe decirme si un registro pertenece al proceso de migración o al de sincronización, tenemos una propiedad solapada, y ahí es donde los registros se pierden o se procesan dos veces.

Vuelta a la normalidad, y luego hipercuidado

Restablece el funcionamiento normal de forma deliberada: la automatización, los trabajos programados, las integraciones, los consumidores de eventos, los agentes, el acceso de los usuarios, en un orden que importa. Para Steve Trucking: quitar el bypass al usuario de migración, volver a activar el suscriptor de Change Data Capture desde el punto de corte (para que Snowflake reciba los cambios del lunes, no la carga del fin de semana), ejecutar la carga de recuperación única del módulo 3 y luego dejar entrar a los coordinadores. Recuerda la avalancha de puesta al día del módulo 3: cuando vuelve una integración, ¿qué cree que pasó mientras estaba apagada? Cuando vuelven los usuarios, ¿está de verdad listo cada servicio crítico? La vuelta a la normalidad forma parte del corte.

Luego estamos en marcha, pero no hemos terminado. Durante un periodo de estabilización (llámalo hipercuidado), vigila los errores de la migración, los fallos de integración, la automatización inesperada, los duplicados nuevos, las relaciones que faltan, los problemas de rendimiento, los problemas de datos que comunican los usuarios y la deriva de la conciliación. El riesgo de la migración no desaparece en el momento en que los usuarios inician sesión.

Luego limpia: los usuarios y permisos temporales de migración, la configuración del bypass, los datos de preparación, los scripts temporales, la configuración exclusiva de la migración, los archivos con datos sensibles del origen, las integraciones temporales, el acceso al runbook. No dejes andamios de la migración pegados a producción porque “puede que algún día los necesitemos”. La arquitectura temporal también necesita un plan de salida. No olvides el almacén de datos de preparación. Después de RouteDesk, guarda en sus tablas en bruto ocho años de nombres, direcciones y números de teléfono de destinatarios. Conserva lo que la política de conservación diga que hay que conservar, como evidencia, y luego borra el resto, en una fecha de la que alguien sea responsable.

Y conserva las pruebas: la extracción final, la versión de la transformación, los archivos de carga, los resultados de los trabajos, los archivos de errores, los informes de conciliación, las aprobaciones, el runbook con las horas reales, la decisión de go/no-go y las excepciones. Tres semanas después alguien preguntará si un registro ya estaba mal antes de la migración o por culpa de ella. Deberías poder responder. Confía, pero verifica no termina cuando se completa la carga.

La IA puede ayudar a vigilar el corte. El go/no-go no es suyo.

La IA es útil bajo la presión del corte: resumir los fallos, clasificar los errores, comparar informes, detectar anomalías, seguir el runbook, hacer aflorar las desviaciones respecto al ensayo. Pero el go/no-go combina las pruebas técnicas, el impacto en el negocio, el tiempo que queda, la posición de reversión y la tolerancia al riesgo. La IA puede hacer aflorar las pruebas. Las personas responsables toman la decisión.

Más allá del examen: lo que cambia la IA. La IA puede hacer más rápidas la monitorización y la conciliación del corte, sobre todo encontrando patrones en grandes conjuntos de datos de errores y validaciones. Mantén una responsabilidad humana explícita sobre el go/no-go, la reversión y la aceptación de los riesgos de migración no resueltos.

Lo que decide aquí un arquitecto

• La profundidad del ensayo, el plan de cargas del Día −7, Día −1 y Día 0 y el punto de reversión (qué se carga pronto, oculto mediante el uso compartido), y el runbook que hace repetible el corte en producción.
• Cómo se deja fuera a los usuarios y cómo se les deja volver, con una puerta trasera y usuarios de prueba, y cómo se controlan mientras tanto la automatización, las integraciones y los agentes.
• Los criterios de go/no-go, el procedimiento de reversión y el punto a partir del cual la reversión deja de ser la recuperación segura, y los datos y flujos desconocidos que hay que encontrar primero.
• Cómo se demuestra la migración con recuentos, totales, comprobaciones puntuales e informes agregados, frente a valores previstos fijados antes de la carga.
• Qué validación de negocio, qué pruebas y qué estabilización posterior a la puesta en marcha se exigen antes de dar la migración por completa.

El corte es una prueba

Los scripts se ejecutaron: no basta. La API devolvió éxito: no basta. Los recuentos de filas cuadraron: sigue sin bastar. Quiero recuentos, totales, comprobaciones puntuales e informes agregados, la validación de negocio, el sistema devuelto a la normalidad, saber si seguimos dentro de la ventana de reversión y pruebas de exactamente lo que pasó. El corte en producción debería ser aburrido, porque hicimos el trabajo duro de pensar antes del viernes por la noche. Confía, pero verifica. Luego deja volver a los usuarios.

Explora

• Others who cut over the same way: Salesforce Help, B2C Commerce Realm Split FAQ (se abre en una pestaña nueva); Microsoft Learn, Data migration planning for go-live (se abre en una pestaña nueva); AWS, Components of AWS DMS (se abre en una pestaña nueva); all checked 2026-11-01. ⟲
• Salesforce Help: Freeze or Unfreeze User Accounts (se abre en una pestaña nueva) and Custom Login Flows (se abre en una pestaña nueva) (login flows are assigned by profile), checked 2026-11-01. ⟲
• En este curso: Datos maestros e identidad e Integración y movimiento de datos.