En este paso conviertes la migración en un plan por etapas con fechas, dueños, un periodo en paralelo acotado y un punto de no retorno explícito. El entregable: un cronograma firmado que incluye el plan de reversa y la lista de integraciones a reconectar. El plan no elimina las sorpresas; les da un lugar donde caer sin romper la operación.
Las migraciones que salen bien comparten la misma anatomía en cuatro etapas:
Junto a las etapas, el plan lista cada integración y formulario que hoy apunta al CRM viejo, con dueño y fecha de reconexión. Es la lista que armaste en la auditoría del paso 2; si es larga, coordinala con los patrones de la guía de integración de datos.
El periodo en paralelo —ambos sistemas activos— es la red de seguridad del proyecto y su mayor riesgo si se maneja mal. La regla que lo hace funcionar: escritura única. Cada equipo escribe en UN solo sistema en cada momento; el otro es de consulta. El piloto escribe en el nuevo mientras el resto sigue en el viejo; nunca los dos a la vez para el mismo equipo.
Complemento obligatorio: congelamiento de cambios en el origen. Desde la migración de prueba en adelante, nadie crea campos, ni etapas, ni workflows en el CRM viejo. Cada cambio posterior al mapeo del paso 3 es una diferencia silenciosa entre lo que probaste y lo que vas a migrar de verdad.
Un paralelo sin regla de escritura no es una red de seguridad: son dos versiones de la verdad divergiendo un poco más cada día.
Duración sana: 2 a 4 semanas. Menos de dos semanas no alcanza para que el piloto revele la fricción real; más de un mes, el equipo carga doble, los datos divergen y la migración empieza a competir contra su propia fatiga.
El punto de no retorno es la fecha en que el CRM viejo pasa a solo lectura y el nuevo se vuelve la única verdad. Se define ahora, en el plan, con tres componentes: la fecha, los criterios objetivos para cruzarla (validación del paso 5 aprobada, piloto operando sin bloqueos, integraciones críticas reconectadas) y el dueño de la decisión —una persona, no un comité.
Antes de esa fecha, el plan de reversa es simple y tiene que estar escrito: si la validación falla o el piloto encuentra un bloqueo grave, se sigue operando en el viejo y se re-corre la migración; nada se pierde porque el viejo nunca dejó de ser la verdad. Después de esa fecha, no hay vuelta atrás barata: por eso los criterios para cruzarla son objetivos y no "se siente bien". Definir esto por adelantado evita la peor versión del proyecto: el limbo de meses con dos CRMs a medio usar porque nadie quiere firmar el corte.
La fecha del cutover se elige esquivando tres trampas: el cierre de trimestre (nadie valida datos con la cuota encima, y el forecast en plena mudanza es un chiste caro), tu temporada alta (retail no migra en noviembre, punto) y las vacaciones de las personas clave (el admin del CRM viejo y el líder comercial tienen que estar en el país y despiertos la semana del corte). La ventana clásica que funciona: inicio de un mes tranquilo, cortando un jueves o viernes para usar el fin de semana como colchón y arrancar el lunes con el equipo completo.
Con el plan firmado, empieza lo concreto: paso 5, ejecución y validación con datos reales. El panorama completo vive en la guía de migración de CRM.
Lo de arriba es un capítulo. El método completo está en la guía para migrar de CRM sin perder historial: de decidir si migrar hasta los primeros 90 días en la plataforma nueva. En una migración el orden pesa más que la herramienta — léela completa antes de exportar nada.