Plan de migración a HubSpot con checklist de cutover completo
La migración a HubSpot tiene un momento de máximo riesgo: el cutover. Es el punto en que el equipo deja de usar el sistema antiguo y empieza a trabajar exclusivamente en HubSpot. Si algo falla aquí, la confianza del equipo en el sistema nuevo se resiente durante meses.
Este plan cubre todas las fases: desde el mapeo inicial de datos hasta el cierre definitivo del sistema anterior, incluyendo el plan de rollback que la mayoría de proyectos ignoran hasta que lo necesitan.
Semana -4: Preparación e importación y mapeo de datos
- Auditoría de datos del sistema origen completada (volumen, duplicados, completitud)
- Documento de mapeo de campos campo a campo aprobado
- Propiedades personalizadas creadas en HubSpot
- Pipeline de ventas configurado y validado con el equipo comercial
- Permisos y roles de usuario configurados
Semana -3: Migración de procesos y automatizaciones
Antes de mover datos, los procesos y las automatizaciones deben estar replicados y probados en el nuevo sistema.
- Flujos de trabajo principales replicados y probados
- Secuencias de email y plantillas disponibles
- Reglas de asignación de leads configuradas
- Integraciones con el stack conectadas y verificadas
- Formularios web redirigidos a HubSpot
El plan de rollback: lo que la mayoría ignora
Un plan de migración a HubSpot serio incluye el escenario de fallo. Tener el rollback documentado antes del cutover da confianza al equipo y al management. No es pesimismo: es gestión de riesgo profesional.
Día del cutover: checklist operativo
No hagas el cutover en viernes. Si algo falla, el soporte no está disponible el fin de semana y el equipo empieza el lunes sin sistema operativo. El martes o el miércoles es el día ideal.
Semana +4: Cierre del sistema antiguo
- Exportación final del sistema origen para archivo
- Baja de licencias del sistema anterior
- Integraciones con el sistema antiguo desconectadas
- Retrospectiva del proyecto documentada
¿Por dónde empezar?
Si quieres valorar cómo aplicar esto en tu empresa, el primer paso es una conversación. Sin compromiso, sin pitch.
Habla con el equipo de MomentumHUB →
Preguntas frecuentes
¿Cuánto tiempo debe estar el sistema antiguo en modo solo lectura después del cutover?
Entre dos y cuatro semanas como mínimo. Este periodo permite al equipo contrastar datos históricos y detectar errores de migración antes de cerrar definitivamente el sistema anterior. Cerrarlo el mismo día del cutover elimina la red de seguridad más importante del proyecto.
¿Qué pasa con los datos introducidos en el sistema antiguo entre el inicio de la migración y el cutover?
Se suelen gestionar de dos formas: o se establece una fecha de congelación del sistema antiguo (no se introducen datos nuevos a partir de X fecha) o se hace una migración incremental de los últimos registros justo antes del cutover. La segunda opción es más compleja pero evita el periodo de congelación.
¿Cómo se comunica el cutover al equipo sin generar resistencia?
La comunicación del cutover debe hacerse con al menos dos semanas de antelación, explicando qué va a cambiar, qué no va a cambiar y qué soporte van a tener el día del cambio y durante las semanas siguientes. Los early adopters que han participado en las pruebas son los mejores embajadores del cambio con sus compañeros.
¿Qué garantías debe ofrecer el partner durante el periodo de cutover?
El partner debe estar disponible con tiempo de respuesta reducido (máximo 2 horas para incidencias críticas) durante el día del cutover y la primera semana post-migración. Esto debe estar en el SOW como SLA específico del periodo de estabilización, no como 'haremos lo que podamos'.
