Cualquier migración de plantillas de correo desde Pardot debería empezar por un único email que tu equipo pueda explicar de principio a fin. Define su objetivo, identifica cada campo y enlace, y comprueba que la versión en la plataforma de destino mantenga intacta la acción que debe realizar el destinatario. Mover un archivo HTML visualmente atractivo es solo una parte del trabajo.
Utiliza Migma para preparar una referencia creativa ya validada, mientras los responsables de Account Engagement y de la plataforma de destino gestionan sus propios datos, automatizaciones y reglas de envío. Esta guía no pretende que Migma sustituya los registros de Salesforce, el lead scoring ni la lógica de journeys B2B: se centra en la pieza de email en sí y en las evidencias necesarias para dar por buena su migración.
Separa la decisión creativa de la decisión de plataforma
La guía de alternativas a Pardot de Brevo, con fecha del 7 de septiembre de 2026, ilustra la magnitud del cambio que supone una migración. La citamos aquí como referencia de partida, no como base para replicar una comparativa de herramientas ni para afirmar que una plataforma sustituye por completo todas las capacidades de Account Engagement.
Documenta con precisión qué vas a migrar exactamente. Una newsletter puntual, una plantilla reutilizable y un correo automatizado de nutrición (nurture) tienen dependencias muy distintas. La migración del diseño puede estar lista mientras el journey asociado sigue pendiente de configuración. Registra ambos hitos por separado en el seguimiento del proyecto.
Elige un correo representativo con un conjunto de variables fácil de controlar. No utilices como primera prueba de aceptación tu newsletter con condicionales más compleja, pero tampoco escojas un mensaje tan básico que no ponga a prueba ninguna de las funciones clave del proceso.
Crea una referencia fiable para el revisor
Reúne los textos aprobados, la estructura visual, la identidad del remitente, la dirección de respuesta, las imágenes, los enlaces de destino y la audiencia prevista. Guarda una captura de pantalla y una copia legible junto a la pieza original, e indica la versión y la fecha en que el responsable dio el visto bueno.
Migma permite crear correos editables e importar diseños. Aprovéchalo para maquetar o ajustar la creatividad definitiva y solicita la aprobación formal del responsable. Evita rediseñar un correo sobre la marcha durante la migración sin avisar: si cambias el diseño en silencio, resultará muy difícil distinguir si una diferencia visual es intencionada o se trata de un error de importación.
Si el equipo decide aplicar un rediseño, indícalo de forma explícita. Comprueba que el nuevo mensaje cumple su propósito antes de contrastar el comportamiento técnico. Una estructura más limpia siempre ayuda, pero no compensa un enlace de baja roto o un botón que dirija a una oferta equivocada.
Mapea el significado antes de sustituir la sintaxis
Crea una hoja de trabajo para los campos con cinco columnas: función visible, campo de origen, campo de destino, muestra validada y comportamiento ante valores vacíos. La sintaxis exacta de cada plantilla debe extraerse de la documentación y del editor de cada plataforma. Evita buscar y reemplazar etiquetas de forma indiscriminada entre sistemas con arquitecturas diferentes.
Por ejemplo, un saludo inicial exige un valor válido para el nombre de pila y un texto alternativo si el campo está vacío. Los datos de contacto de un asesor requieren una regla de asignación clara. El enlace a un producto debe apuntar a la URL adecuada para ese segmento concreto. Y un campo denominado «owner» resulta ambiguo hasta que el equipo define si se refiere al propietario de la cuenta, al del lead o al autor del mensaje.
Haz pruebas con registros ficticios para comprobar valores cortos, textos largos, campos vacíos y caracteres especiales como apóstrofes. Revisa el resultado tal como lo verá el destinatario final, no solo la vista previa del editor sin datos reales. Una etiqueta de combinación (merge field) que parece correcta en el código fuente puede resolverse mal tras la importación.
Comprueba las cuatro rutas que utiliza el lector
Verifica la acción principal, la vía de respuesta, la gestión de preferencias y cualquier enlace a documentos o páginas de destino. Cada una de estas rutas debe tener un responsable asignado. Quien diseña el correo no puede garantizar que una landing page mantenga el comportamiento esperado en sus formularios simplemente porque el botón se vea bien en el mensaje.
| Ruta | Evidencia que se debe registrar |
|---|---|
| Acción principal | El enlace de destino coincide con la oferta aprobada y la audiencia adecuada |
| Respuesta | Una respuesta directa llega al equipo encargado de gestionarla |
| Preferencias | La plataforma de destino aplica la configuración de bajas y consentimientos acordada |
| Contenido complementario | Las imágenes y los documentos enlazados siguen accesibles en las ubicaciones previstas |
Esta tabla recoge evidencias de validación operativa, no una lista de integraciones de Migma. Antes de dar por sentado un traspaso automático con un solo clic, confirma qué opciones de exportación o entrega técnica admite la plataforma de destino que hayas elegido.
Valida el correo final con datos reales
Pasa la versión validada en Migma por Email Preflight. Revisa las previsualizaciones en los principales clientes de correo, la redacción, los enlaces y las alertas sobre riesgos de entregabilidad. Después, compara el mensaje final ya poblado con datos en la plataforma de destino frente a la referencia aprobada: cualquier cambio introducido por el motor de envío debe someterse a su propia revisión.
Presta atención a las líneas de asunto largas, el texto de vista previa (preheader), la visualización en dispositivos móviles y la legibilidad del contenido cuando las imágenes están bloqueadas. Comprueba que el mensaje principal se entienda incluso si los elementos gráficos decorativos no cargan. Preflight ayuda a evitar errores operativos comunes, pero no garantiza un renderizado idéntico ni asegura la entrada en la bandeja principal de todos los buzones.
Asegúrate de que el responsable de operaciones confirme qué sistema gestiona el primer envío real tras la migración. Evita que el entorno antiguo y el nuevo puedan lanzar el mismo mensaje simultáneamente. Si hace falta revertir el proceso, concilia las tareas pendientes antes de volver a cambiar de responsable técnico.
Escala solo cuando la validación esté documentada
Guarda el registro de aceptación junto a la plantilla: incluye la versión definitiva, la tabla de mapeo de campos, los casos de prueba utilizados, la persona que validó el diseño y las limitaciones técnicas que queden por resolver. Este registro facilitará las siguientes migraciones, ya que servirá como criterio concreto de lo que se considera un trabajo completado.
Si este primer correo saca a la luz campos sin asignar o dudas sobre quién gestiona cada proceso, resuélvelo antes de migrar bloques enteros de plantillas. Inicia la revisión creativa en Migma, mantén una referencia contrastada y traslada los correos uno a uno según su caso de uso. Un despliegue gradual y verificado resulta mucho más fácil de auditar que una carpeta llena de plantillas importadas sin garantías sobre su comportamiento en producción.
Preguntas frecuentes
¿Exportar una plantilla equivale a completar la migración de Pardot?
No. La validación del diseño debe separarse de los contactos, la puntuación de leads, los permisos, la lógica de journeys y la propiedad de los envíos. Esta guía se centra en la referencia del correo y en su comportamiento final una vez poblado de datos.
¿Conviene copiar directamente la sintaxis de las etiquetas de combinación (merge fields)?
No. Utiliza la sintaxis admitida por cada plataforma y mapea primero el significado de cada campo. Comprueba valores válidos, vacíos, largos y atípicos directamente en el resultado final de destino.
¿Se puede aprovechar la migración para rediseñar la plantilla?
Sí, siempre que el responsable lo apruebe de forma explícita. Documenta con claridad la versión aprobada para que el equipo distinga los cambios visuales intencionados de posibles errores de transferencia.
¿Qué debe incluir el registro de validación del primer correo?
Debe recopilar la referencia revisada, la versión, la ficha de mapeo de campos, las rutas de enlaces verificadas, los casos de prueba ficticios, el revisor, el responsable operativo del envío y las limitaciones pendientes.