Migrar de plataforma es una de esas decisiones que se toman por frustración y se pagan durante meses. Antes de la parte técnica hay una pregunta que conviene contestar en serio.
La pregunta previa
¿El problema es la herramienta o es lo que se está haciendo con ella? En la mayoría de las cuentas que auditamos, los journeys no funcionan por falta de taxonomía de eventos, por segmentación pobre o por ausencia de medición. Nada de eso lo arregla cambiar de plataforma: se muda tal cual, y encima se pierden meses.
Cuándo la migración sí se justifica
- Límite real del modelo de datos. La plataforma actual no soporta los objetos o relaciones que tu producto necesita, y estás resolviéndolo con parches.
- Costo desalineado. El precio escala por una variable que no se corresponde con tu valor, típicamente perfiles totales en vez de perfiles alcanzados.
- Canales que no cubre. Necesitás WhatsApp, in-app o push con reglas finas y la herramienta actual no llega.
- Deuda técnica insalvable. La cuenta acumuló años de automatizaciones sin gobierno y reconstruirla adentro cuesta lo mismo que migrar.
Si ninguna de esas cuatro aplica, lo que necesitás es una auditoría, no una migración.
Qué se migra y qué no
| Elemento | ¿Se migra? | Nota |
|---|---|---|
| Perfiles y atributos | Sí | Es lo más importante y lo que no se puede reconstruir |
| Estado de suscripción y consentimiento | Sí, obligatorio | Perderlo es un problema legal, no técnico |
| Taxonomía de eventos | Se rediseña | La migración es la mejor oportunidad para arreglarla, no para copiarla |
| Histórico de eventos | Normalmente no | Se acumula desde cero. Conviene conservar la plataforma vieja en solo lectura un tiempo |
| Journeys | Se reconstruyen | Copiarlos tal cual arrastra los errores. Se aprovecha para depurar |
| Plantillas | Sí, adaptadas | Cambia la sintaxis de variables y de lógica condicional |
| Reputación de envío | No | Se reconstruye con calentamiento progresivo del dominio |
El runbook
- Auditoría de lo que existeInventario de journeys activos, cuáles disparan de verdad, cuáles están dormidos y cuáles se contradicen entre sí. Casi siempre hay journeys corriendo que nadie recuerda haber creado.
- Rediseño de la taxonomíaQué eventos y propiedades necesita el sistema nuevo. Es el paso que convierte una mudanza en una mejora.
- Migración de perfiles y consentimientoCon validación de integridad y verificación explícita del estado de suscripción por canal.
- Reconstrucción de journeys, por prioridadPrimero los transaccionales y los de mayor impacto. No todos: los que se justifiquen.
- Convivencia y validaciónAmbas plataformas corriendo, con corte journey por journey y comparación de resultados entre las dos.
- Calentamiento del dominioVolumen progresivo para reconstruir reputación. Saltarse este paso es la forma más rápida de terminar en spam.
- Corte y solo lecturaSe apaga la plataforma vieja y se conserva en modo consulta mientras haga falta el histórico.
Cómo lo hacemos
Somos Platinum Partner de Customer.io, así que tenemos acceso directo a su equipo durante la migración. Pero antes de proponerte migrar auditamos lo que tenés, y si la respuesta es que no conviene, esa es la respuesta.
Preguntas frecuentes
¿Cuánto tarda una migración a Customer.io?
Depende de la cantidad de journeys activos y de la salud de la taxonomía de eventos, no del tamaño de la base. Migrar una cuenta con pocos journeys bien definidos es cuestión de semanas; una con decenas de automatizaciones acumuladas durante años lleva más, y buena parte de ese tiempo es decidir qué no migrar.
¿Se cortan las comunicaciones durante la migración?
No debería. Se trabaja con un período de convivencia: los journeys críticos siguen corriendo en la plataforma vieja mientras se construyen y validan en la nueva, y el corte se hace journey por journey, no todo de golpe.
¿Se pierde el historial de eventos?
El histórico de eventos generalmente no se migra: se arranca a acumular desde el día uno en la plataforma nueva. Lo que sí se migra son perfiles, atributos, suscripciones y estados de consentimiento, que es lo que no se puede reconstruir.
¿Y la reputación de envío?
Se pierde si cambiás de infraestructura de envío, y por eso hay que calentar el dominio de forma progresiva. Es la parte de la migración que más veces se subestima y la que más daño hace si se salta.
¿Conviene migrar o arreglar lo que tengo?
En la mayoría de los casos que vemos, arreglar. La migración se justifica por límites reales de la herramienta, no por frustración con los resultados. Si los journeys no funcionan hoy, no van a funcionar mejor en otra plataforma.
Antes de migrar, veamos si hace falta
Media hora sobre tu cuenta actual. Si el problema no es la herramienta, te lo decimos.
Agendá un diagnóstico de 30 min →