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.
Antes de mover datos, los procesos y las automatizaciones deben estar replicados y probados en el nuevo sistema.
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.
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.
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 →
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.
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.
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.
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'.