El Día del Cutover: La Lista de Verificación que Previene Desastres

El día del cutover no es el momento para improvisar. Cada migración de CRM que salió mal tuvo la misma causa raíz: ningún plan escrito. Los equipos que ejecutan cutovers limpios trabajan desde una lista de verificación, tienen un disparador de rollback definido antes de que se importe el primer registro y se comunican con el equipo de ventas en cada etapa.

Esto es lo que parece un mal cutover: una empresa de 200 personas migró de Salesforce a un nuevo CRM un viernes por la tarde. La importación se ejecutó bien. A la hora 6, el equipo de ventas estaba bloqueado fuera de ambos sistemas porque el congelamiento de datos no se había comunicado correctamente. Tres elementos faltantes en la lista de verificación lo causaron: sin procedimiento de congelamiento de datos, sin comunicación enviada a los representantes con anticipación, sin un DRI (Directamente Responsable Individual) nombrado para la ventana del cutover. El equipo hizo rollback durante el fin de semana y reprogramó para tres semanas después. Si ese sistema de origen era Salesforce, la comparación Rework vs. Salesforce cubre las diferencias de configuración específicas que deben configurarse en el destino antes de que los representantes inicien sesión por primera vez.

Esta guía es el plan desde el que ejecuta. Imprímalo. Léalo la noche anterior. Asigne a cada elemento un responsable.

T-Menos 48 Horas: Lista de Verificación Pre-Cutover

Lista de Verificación Pre-Cutover (10 elementos)

Si alguno de estos 10 elementos está incompleto a las T-menos 48 horas, postergue el cutover. Un retraso de una semana es mejor que un go-live fallido.

T-Menos 2 Horas: Congelamiento de Datos

El congelamiento de datos es una de las partes más mal manejadas de una migración. La mayoría de los equipos lo anuncian demasiado tarde, no lo hacen cumplir y terminan con el origen y el destino divergiendo durante la ventana de importación.

Por qué importa: Si un representante crea un nuevo contacto en el CRM de origen a las 9:15am y su importación se ejecuta de 9:00am a 12:00pm, ese contacto no estará en el destino. El representante cree que sus datos se perdieron. Esa desconfianza en el nuevo sistema comienza el primer día y es difícil de deshacer.

Cómo hacerlo cumplir:

Envíe un mensaje de Slack/Teams 2 horas antes de la ventana de congelamiento con la hora exacta: "La entrada de datos en [CRM de origen] se bloqueará de 10:00am a 2:00pm hoy."
Cambie los permisos de usuario del CRM de origen a solo lectura para todos los usuarios no administradores durante la ventana de importación. Este es el único método de cumplimiento confiable.
Para Salesforce: configuración de perfil — elimine permisos de Crear/Editar para todos los objetos excepto para usuarios administradores. La guía de Salesforce Data Loader tiene los pasos de secuencia de importación para ejecutar una vez que el congelamiento esté en vigor.
Para HubSpot: No hay un "modo de solo lectura" único — lo más cercano es eliminar temporalmente a todos los usuarios no administradores de la cuenta. Para la mayoría de los equipos, la comunicación es el método de cumplimiento. La documentación de importación de HubSpot cubre el proceso de importación post-congelamiento y lo que muestra el registro de importación para el QA.
Para Pipedrive: Configuración > Gestionar Usuarios — puede restringir permisos por usuario. La guía de importación de Pipedrive documenta qué sucede cuando llegan contactos duplicados durante una ventana de importación, relevante si algún registro se filtra durante el congelamiento.

Qué hacer con los deals que llegan durante la ventana de congelamiento: Esto sucederá. Un representante recibe un lead entrante a las 10:30am durante el congelamiento. La respuesta: tome nota, no lo ingrese en el sistema de origen y escríbalo directamente en el destino después del go-live. Informe al equipo sobre esto antes de que comience el congelamiento.

La ventana de congelamiento debe ser al menos 1 hora antes de que comience la importación. No empiece a importar en el momento en que el congelamiento entre en vigor — déle un margen de una hora para que cualquier ingreso de datos de último momento se complete y sincronice.

Horas 1–3: La Ejecución de la Importación

Está ejecutando desde el documento de secuencia de importación. Sin improvisación.

Secuencia de Importación

Ejecute las importaciones en este orden exacto. Cada paso depende del anterior para la resolución de relaciones:

Companies / Accounts — Sin dependencias. Ejecute primero.
Contacts — Depende de las Companies (para la asociación de empresa). Verifique que el recuento de registros de empresa coincide antes de continuar.
Deals / Opportunities — Depende de los Contacts (para la asociación de contacto). Verifique que el recuento de registros de contacto coincide antes de continuar.
Activities (llamadas, emails, notas, tareas) — Depende de Contacts y Deals. Ejecute al final.
Objetos Personalizados — Si aplica. Ejecute después de todos los objetos estándar.

Entre cada paso:

Verifique el registro de importación para detectar errores antes de continuar con el siguiente objeto
Anote el recuento de registros y compárelo con lo esperado
Verifique manualmente 3 registros para confirmar que la importación más reciente se ejecutó correctamente

Qué buscar en el registro de importación:

Errores de conversión de tipo (valor de texto en campo numérico)
Fallos de campo requerido (registros omitidos porque un campo requerido era nulo)
Fallos de resolución de relaciones (contacto importado pero la asociación de empresa falló)
Detección de duplicados (si el destino tiene reglas de deduplicación, algunos registros pueden bloquearse)
Errores de límite de velocidad o tiempo de espera (las importaciones grandes pueden alcanzar límites de API; pause y reanude si es necesario)

Para conjuntos de datos grandes (50.000+ registros): Ejecute la importación en lotes de 10.000–15.000 registros por lote. Esto le da un punto de recuperación si la importación falla a mitad y hace que el QA sea más fácil — puede verificar cada lote antes de ejecutar el siguiente. Para migraciones a gran escala donde RevOps gestiona la transición, el modelo de madurez de RevOps es contexto útil — ayuda a establecer expectativas realistas sobre cuánta limpieza post-cutover necesitan los equipos en diferentes niveles de madurez.

No comience el QA hasta que la importación esté completamente terminada. Es tentador empezar a verificar registros durante la ejecución de importación. Espere. Los datos parciales son engañosos y desperdiciará tiempo en problemas que se resuelven cuando se importan el resto de los datos.

Horas 3–4: QA de Go-Live

Esta es su verificación final antes de activar el interruptor. Trabaje sistemáticamente a través de la lista de 15 verificaciones. Cada verificación tiene un veredicto de aprobado/reprobado.

Lista de Verificación de QA de Go-Live (15 verificaciones)

Verificaciones de recuento de registros:

Total de contactos en el destino = recuento esperado (±0,5%)
Total de empresas en el destino = recuento esperado (±0,5%)
Total de deals en el destino = recuento esperado (±0,5%)
Total de deals abiertos en el destino = recuento de deals abiertos en origen

Verificaciones puntuales de precisión de campo (abra 10 registros cada uno): 5. [ ] Las etapas del ciclo de vida de los contactos muestran valores válidos (sin nulos, sin valores no mapeados) 6. [ ] Las etapas de deal mapean correctamente a las etapas del pipeline de destino 7. [ ] Los montos de deal se muestran como números (no como texto) 8. [ ] Los campos de fecha (fecha de cierre, fecha de creación) se muestran en formato correcto

Integridad de las relaciones: 9. [ ] Muestra aleatoria de 10 contactos — todos tienen la asociación de empresa correcta 10. [ ] Muestra aleatoria de 10 deals — todos tienen al menos una asociación de contacto 11. [ ] Muestra aleatoria de 5 deals — el propietario del deal está asignado correctamente

Verificación de informes: 12. [ ] Informe de pipeline por etapa: el valor total de deals abiertos coincide con el origen dentro del 1% 13. [ ] Contactos por etapa del ciclo de vida: el recuento por etapa coincide con el origen dentro del 2% 14. [ ] Deals creados en este período: el recuento coincide con el origen (considerando la ventana de congelamiento)

Función del sistema: 15. [ ] Pruebe la creación de un nuevo contacto en el destino — los workflows básicos se disparan correctamente, sin errores

Puntuación del QA:

15/15 verificaciones pasan: Proceda a la decisión de go-live
13–14/15 verificaciones pasan: Evalúe los fallos — ¿son bloqueantes? Los problemas menores de visualización son diferentes a los campos de relaciones rotos
<13/15: No vaya en vivo. Diagnostique los fallos, determine el alcance del impacto y tome la decisión de rollback

Hora 4: La Decisión de Go/No-Go

Esta es la decisión que separa los cutovers planificados de los caóticos. Los criterios para ir en vivo y los criterios para hacer rollback deben definirse antes de comenzar — no debatirse durante la ventana de QA.

Criterios de go (todos deben ser verdaderos):

Puntuación de la lista de verificación de QA: 14/15 o mejor
Sin problemas bloqueantes (todos los deals abiertos tienen la etapa correcta, todos los contactos tienen una etapa del ciclo de vida válida)
Totales de informes dentro de la tolerancia (valor del pipeline dentro del 1%, recuentos de etapas dentro del 2%)

Disparadores de rollback (cualquiera es suficiente):

El recuento de registros está desviado más del 2% sin explicación (se perdieron registros en la importación)
Los campos de relaciones están rotos a escala (más del 5% de los deals no tienen asociación de contacto)
Se detectó corrupción del tipo de campo (campos de moneda importándose como texto, rompiendo los informes de ingresos)
El propio CRM de destino está experimentando problemas de rendimiento que impiden el uso normal

Quién toma la decisión: Nombre a una persona con anticipación. No es una decisión de comité. El DRI (Directamente Responsable Individual) nombrado toma la decisión basándose en los criterios anteriores, sin necesitar consenso. Cuando todos deciden, nadie decide rápidamente — y el retraso agrava el problema.

Cómo comunicar la decisión:

Go: Envíe el mensaje de go-live (plantilla abajo) inmediatamente
No-go/rollback: Envíe el mensaje de rollback inmediatamente, luego siga el procedimiento de rollback

No demore la comunicación mientras "investiga" un problema. Envíe el mensaje de estado primero, luego investigue.

Horas 4–5: Procedimiento de Rollback

Si dispara un rollback, no está fallando — está ejecutando el plan. Un rollback es mejor que ir en vivo con datos corruptos.

Procedimiento de rollback:

Envíe la comunicación de rollback al equipo de ventas inmediatamente: "Hemos identificado un problema durante el QA y estamos regresando a [CRM de origen] por ahora. Puede reanudar el trabajo en [CRM de origen] — no se perdieron datos. Comunicaremos la fecha de go-live reprogramada dentro de 24 horas."
Vuelva a habilitar el acceso completo al CRM de origen (revierta los permisos de congelamiento de datos).
Limpie la importación del CRM de destino. La mayoría de los CRM permiten una eliminación masiva o un "restablecimiento en blanco" para los datos importados durante una ventana específica. Haga esto antes de que el equipo comience a hacer cualquier edición en el destino — necesita una pizarra en blanco para la reimportación.
Preserve el trabajo realizado. Exporte los registros de importación, registros de error y notas de QA. Estos se convierten en los insumos para corregir la causa raíz.
Programe una sesión de debriefing para el siguiente día hábil. ¿Qué falló? ¿Qué necesita cambiar el documento de mapeo? ¿Cuánto tiempo tomará la corrección? Establezca un cronograma de re-ejecución realista.

Cronograma de rollback: Apunte a completar el rollback y restaurar el acceso al CRM de origen dentro de los 90 minutos de la decisión. Cuanto más tiempo estén los representantes en el limbo, más desconfianza se acumula.

Reprogramación: Agregue al menos 5 días hábiles a la nueva fecha de cutover. Esto le da tiempo para corregir la causa raíz, ejecutar otra importación sombra para verificar la corrección y obtener la aprobación de las partes interesadas antes de volver a intentarlo. Apresurarse a la re-ejecución es cómo se falla dos veces.

Hora 5: Comunicación de Go-Live

Si el QA pasa y ha decidido ir en vivo, comunique inmediatamente.

Plantilla de Comunicación de Go-Live

Slack / Teams (envíe primero):

[Nombre], equipo — [Nombre del CRM] está en vivo. Puede comenzar a usar el nuevo sistema ahora.

Notas rápidas:

Sus datos están en [Nombre del CRM] a partir de hoy

Si está buscando algo y no puede encontrarlo, publique en #crm-support — lo ayudaremos

[CRM de origen] está en modo de solo lectura y permanecerá accesible por 30 días si necesita referencia histórica

DRI para preguntas del primer día: [Nombre] — contáctele directamente o en #crm-support

Email (envíe dentro de los 30 minutos del go-live):

Asunto: [Nombre del CRM] está en vivo — lo que necesita saber

La migración está completa. A partir de ahora, [Nombre del CRM] es el sistema de registro para toda la actividad de ventas.

Lo que necesita hacer hoy:

Inicie sesión en [Nombre del CRM] en [URL] usando sus credenciales de [email/SSO]

Verifique que sus deals abiertos muestran la etapa y el monto correctos

Si algo se ve mal, contacte a [Nombre] en [información de contacto] — no lo corrija usted mismo todavía

Acceso de solo lectura a [CRM de origen]: [CRM de origen] todavía es accesible como archivo de solo lectura hasta [fecha 30 días desde ahora]. Úselo como referencia para actividades históricas. No ingrese nuevos datos en [CRM de origen].

Soporte del primer día: [Nombre] está disponible hoy y mañana para preguntas. Slack: #crm-support. Email: [dirección].

Gracias por su paciencia durante la migración.

Envíe ambos mensajes dentro de los 5 minutos de la decisión de go-live. No espere hasta haber hecho una revisión final. La velocidad de comunicación es lo que previene la confusión de "¿está en vivo el sistema o no?"

Días 1–3: Monitoreo Post-Cutover

El go-live no es el final — es el comienzo del período de estabilización. Los errores comunes del primer día aparecen cuando los representantes comienzan a usar el sistema de maneras que el QA no cubrió.

Lista de Verificación de Monitoreo Diario (Días 1–3)

Día 1 (dentro de las 2 horas del go-live):

Verifique puntualmente 20 registros del pipeline abierto activo de un representante — ¿están correctas las etapas, los contactos y los montos?
Revise el canal #crm-support para ver los problemas reportados — clasifique y responda dentro de los 15 minutos
Verifique que los nuevos registros creados post-go-live se guardan correctamente (verificación básica de función del CRM)

Día 1 (fin del día):

Recuento de problemas reportados — categorice como calidad de datos, mapeo de campos o error de usuario
¿Algún problema que requiera una corrección (no capacitación del usuario)? Identifique la causa raíz y registre para resolución
Actualización de estado al liderazgo de ventas: X problemas reportados, Y resueltos, Z en progreso

Días 2–3:

Revisión diaria del registro de problemas — ¿se repiten los mismos problemas? Los problemas recurrentes sugieren un error de mapeo sistémico, no un caso aislado
Verifique que la automatización basada en etapa de deal se dispara correctamente (los nuevos deals que avanzan por las etapas deben disparar las secuencias correctas)
Verifique la precisión del informe: ¿el informe de pipeline coincide con lo que los representantes reportan en sus pipelines?

Errores comunes del primer día y correcciones:

Error	Causa probable	Corrección
Contacto muestra la etapa del ciclo de vida incorrecta	El mapeo de lista de selección no incluyó un valor	Actualice el registro manualmente, corrija el documento de mapeo para registros similares
Monto de deal muestra $0 o texto	La conversión del tipo de campo de moneda falló	Encuentre los registros afectados mediante un filtro de informe, actualice los montos masivamente
Historial de actividad faltante para un contacto	La importación de actividad falló o la relación no se resolvió	Revise el registro de importación para ese ID de contacto; reimporte actividades para los registros afectados
El representante no puede ver sus registros asignados	El campo de asignación de usuarios no se resolvió correctamente	Reasignación masiva en el panel de administración del destino
La secuencia de automatización no se dispara	Los nombres de etapa del pipeline no coinciden con las condiciones del disparador de automatización	Actualice el disparador de automatización para que coincida con los nuevos nombres de etapa

La regla de las 48 horas: La mayoría de los problemas del primer día aparecen dentro de las 48 horas. Si no ha escuchado sobre un problema para el día 3, probablemente no lo hará. Mantenga el monitoreo activo durante 3 días, luego cambie a un ritmo de seguimiento semanal.

Errores Comunes

Sin criterios de rollback definidos. Sin criterios predefinidos, la decisión de rollback se convierte en un debate de comité durante una crisis. El equipo pasa 45 minutos discutiendo si el 3% de deals huérfanos es "suficientemente malo" para hacer rollback mientras los representantes esperan. Defina los criterios antes de comenzar.

Sin congelamiento de datos. Así es como el origen y el destino divergen. Un representante crea un deal a las 10:45am durante la ejecución de importación. Está en el origen pero no en el destino. El representante cree que la migración perdió su trabajo. Es un problema de moral y confianza que es completamente prevenible.

QA de go-live insuficiente. Terminar la importación e ir en vivo en 30 minutos se siente eficiente. Omite el QA que detecta los campos de moneda rotos y los registros de deal huérfanos. La ventana de QA de 90 minutos vale la pena.

Sin DRI nombrado para soporte del primer día. Decirle a los representantes que "pregunten a alguien" no es un plan de soporte. Una persona nombrada, visible en la comunicación, a quien se puede contactar directamente. Esa persona resuelve preguntas en el acto o escala — no las pospone. La guía de implementación y adopción del CRM tiene un plan estructurado de onboarding de representantes para el primer y segundo día, vale la pena leer antes de redactar la comunicación de go-live.

Cutovers el viernes por la tarde. Este problema aparece constantemente. Hay presión para hacer el cutover el viernes para que los representantes tengan el fin de semana para "ajustarse". Lo que realmente sucede: los problemas aparecen el viernes por la tarde, el equipo de migración se ha ido por el fin de semana y los representantes pasan el lunes lidiando con problemas de datos sin resolver. Programe los cutovers para el martes o miércoles por la mañana. El equipo está fresco, el soporte está disponible y los problemas se resuelven dentro del mismo día hábil. Desde el punto de vista de la continuidad del pipeline, leer sobre cultura de higiene del pipeline antes de la semana del cutover ayuda — explica qué necesitan ver los representantes el primer día para mantener la confianza en los datos del nuevo sistema.

Qué Hacer Después

Programe el cutover para un martes o miércoles por la mañana, no para un viernes. Envíe la lista de verificación pre-cutover de T-menos 48 horas al responsable de migración hoy y confirme que todos los 10 elementos tienen fechas de completitud asignadas.

Si su importación sombra aún no ha sido aprobada, no programe el cutover en absoluto. La aprobación de la importación sombra es el requisito previo para todo lo que hay en esta guía. Y una vez que el polvo se asiente, use el artículo de gestión de datos de leads como línea de base para las prácticas continuas de calidad de datos que evitan que el mismo trabajo de limpieza sea necesario en la próxima migración.

Data Migration Guide