Servicio de migración a Klaviyo

Migrar a Klaviyo significa trasladar datos y comportamientos

Una migración de email marketing no termina al importar contactos. También hay que trasladar qué mensajes recibe cada persona, por qué entra en una secuencia, cuándo debe salir y qué información necesita el equipo para seguir trabajando. Si solo se copia la base, las automatizaciones, las exclusiones y los formularios pueden quedar desconectados.

Empieza por definir el motivo del cambio: una integración que falta, límites del sistema actual, dificultad para gestionar los recorridos o necesidad de centralizar el trabajo. Esa decisión permite distinguir lo que se debe conservar de lo que conviene rediseñar. La configuración de Klaviyo para ecommerce debe responder a esas necesidades concretas.

El alcance debe nombrar cuentas, tiendas, idiomas, canales y personas responsables. Acuerda también qué historial se necesita conservar y qué limitaciones tiene la plataforma de origen. No prometas trasladar todos los datos con el mismo significado sin comprobar antes qué puede exportarse y cómo se representa en destino.

Prepara un inventario antes de fijar la fecha del cambio

Recorre el sistema actual con quien lo utiliza. No te limites a las campañas más visibles: revisa formularios, segmentos, exclusiones, automatizaciones, plantillas, integraciones, mensajes de la tienda y procesos manuales. Identifica quién depende de cada pieza y qué ocurriría si dejara de funcionar.

La tabla propone un inventario mínimo para convertir la migración en entregables verificables. Añade enlaces a la configuración y una decisión por pieza: conservar, reconstruir, retirar o investigar.

El inventario también sirve para estimar el coste y alcance del proyecto. Una cuenta con pocas plantillas pero varias integraciones propias puede exigir más trabajo que otra con muchos mensajes basados en el mismo diseño.

Mapea campos y estados antes de importar

Crea una tabla de equivalencias entre origen y destino. Para cada campo, registra nombre, significado, formato, ejemplo y uso posterior. Dos campos llamados «fecha de compra» pueden representar cosas distintas: el último pedido de un perfil o la fecha de un evento concreto.

Klaviyo documenta vías de importación y un procedimiento para incorporar bajas históricas. Una migración debe conservar esas exclusiones; disponer de una dirección de email no equivale a tener una suscripción activa.

Define qué fuente prevalece cuando hay registros contradictorios y cómo se investigarán las excepciones. No resuelvas un conflicto de estados eligiendo automáticamente el que permita enviar. Mantén fuera de los envíos los casos que requieran aclaración hasta verificar su situación.

Primero prueba con una muestra pequeña que incluya los casos difíciles: datos incompletos, idiomas distintos, direcciones repetidas y estados diferentes. Comprueba fechas, valores vacíos y caracteres especiales. La igualdad del total de registros no demuestra que el mapeo sea correcto.

Por ejemplo, en una tienda ficticia el campo «idioma» contiene tanto «es» como «Español». El plan puede normalizarlos al mismo valor, conservar el original para trazabilidad y dejar los valores desconocidos pendientes de revisión. La decisión debe hacerse antes de que ese campo determine el idioma de un email.

Reconstruye los recorridos con sus reglas reales

Para cada automatización de email, escribe el evento de entrada, las condiciones, las esperas y los motivos de salida. Decide qué ocurre con las personas que ya estaban dentro del sistema anterior. Reiniciarlas todas desde el primer mensaje puede repetir comunicaciones; ignorarlas puede dejar un seguimiento incompleto.

No supongas que el mismo nombre de evento implica el mismo dato. Comprueba un caso reciente de la tienda y los campos que necesita la pieza. Un bloque de productos, un enlace al carrito o una condición de compra debe basarse en la información que llega realmente a destino.

En una migración desde Mailchimp, las etiquetas dinámicas de las plantillas necesitan adaptación, incluida la de baja. Copiar el HTML no basta para conservar su comportamiento en Klaviyo.

Define qué sistema será responsable de cada mensaje durante la transición. Incluye las notificaciones que salen directamente de la tienda: el equipo debe saber cuáles se mantienen y cuáles se sustituyen. Preparar el nuevo recorrido no autoriza a activar dos versiones a la vez.

Conserva las decisiones de contenido junto a las técnicas. Si se cambia el orden de mensajes o se retira una oferta antigua, registra el motivo y quién lo aprueba. Así se puede distinguir un cambio deliberado de un error de traslado.

Pruebas de aceptación antes del primer envío real

Klaviyo permite previsualizar con datos de perfil o evento cuando corresponde. Las pruebas de presentación no cubren todo el comportamiento en envío real; valida también los recorridos de prueba y sus enlaces.

La siguiente matriz describe resultados esperados que el equipo debe acordar. Utiliza contactos de ensayo controlados y evita activar comunicaciones a la base completa para comprobar una regla.

La aprobación debe identificar la versión probada. Si después cambia un evento, una condición o una plantilla, revisa qué pruebas quedan invalidadas y repítelas antes de activar esa parte.

Planifica el cambio de sistema y la posible reversión

El plan de puesta en marcha debe indicar quién ejecuta cada paso, quién lo revisa y qué señal obliga a detenerse. Acuerda una ventana de cambio con margen para comprobar altas, compras y envíos. Evita hacer coincidir la transición con una campaña importante si el equipo no podrá atender incidencias.

La convivencia temporal puede servir para comprobar datos, pero necesita responsabilidades claras de envío. Define qué se pausa en origen, qué se activa en destino y cómo se tratarán los cambios que ocurran entre la exportación y el cambio definitivo. Registra también las bajas nuevas de ese intervalo.

Antes de empezar, prepara una reversión posible: qué configuración se puede restaurar, qué datos habría que conciliar y quién puede autorizarlo. Detener el nuevo sistema no significa encender automáticamente todos los mensajes antiguos. Revisa la actividad ya realizada para evitar repeticiones.

Incluye la entregabilidad en esta fase: dominios, autenticación, selección inicial y seguimiento. La migración técnica y la evaluación del envío son trabajos relacionados, pero una importación correcta no demuestra que el canal ya funcione como se espera.

Cómo saber que la migración está terminada

El cierre debe comparar origen y destino por categorías relevantes, no solo por el total de perfiles. Explica duplicados, registros excluidos, errores y datos que no se pudieron trasladar. Conserva el informe de conciliación junto con el inventario inicial y las decisiones aprobadas.

No elimines el acceso anterior antes de guardar los informes y configuraciones que se acordó conservar. Revisa también las integraciones y credenciales temporales cuando ya no hagan falta. La retirada debe dejar un responsable claro de la operación habitual y de las incidencias pendientes.

• Contactos, exclusiones y campos revisados mediante recuentos y muestras.
• Altas nuevas y eventos de tienda comprobados en destino.
• Recorridos activados con sus pruebas de aceptación aprobadas.
• Responsabilidad de envío única para cada mensaje trasladado.
• Plantillas, enlaces, preferencias y personalización verificados.
• Informes anteriores conservados con sus definiciones.
• Documentación, accesos y seguimiento entregados al equipo.

Después del cambio, compara las métricas con periodos y definiciones compatibles. Un nuevo modelo de atribución puede cambiar el informe sin representar ventas adicionales. La migración está bien cerrada cuando el equipo puede operar, comprobar y explicar el nuevo sistema, no cuando termina la carga del archivo.

Fuentes y lecturas

• Klaviyo · Migrating subscribers and unsubscribes
• Klaviyo · Migrating from Mailchimp
• Klaviyo · Preview and test emails