Migra desde Mandrill — ahora Mailchimp Transactional — a un stack transaccional europeo sin un plan de marketing atado encima

No mientras te quedes en Mandrill. El plan de marketing Mailchimp ha sido requisito duro desde abril de 2016 y el rebrand de otoño 2025 a Mailchimp Transactional no lo cambió. Standard a $20/mes es el camino más barato; los planes Essentials y Free siguen sin calificar independientemente de cómo luzca el resto de tu stack. Para un cliente Mandrill de 100K/mes corriendo 4 bloques, el impuesto de plan de marketing ronda el 20% de la factura — no trivial pero tampoco catastrófico. Para un cliente de 2M/mes en Premium $350 (que algunos paths de ventas enterprise empujan), el impuesto está en el mismo orden de magnitud que una IP dedicada.

Los equipos que vemos migrando más agresivamente son aquellos donde el plan Mailchimp marketing es peso muerto. Si tu marketing corre en HubSpot, Customer.io, Klaviyo, Brevo o construido in-house, los $20-$350 Standard-Premium pagan por una interfaz a la que nadie en tu empresa entra. Nuestro modelo elimina esa línea — servicio transaccional de producto único, sin precondición de plan de marketing. Para equipos que sí usan campañas Mailchimp marketing junto al transaccional, la doble suscripción es genuinamente una feature (facturación unificada, plantillas editables por marketer), y no fingimos lo contrario.

Para uso operativo puro, 30 días basta. Investigas una pregunta de entrega la misma semana, afinas un patrón de queja dentro del mismo ciclo de campaña, normalmente no necesitas mirar un password reset de hace cuatro meses. Los lugares donde esto incomoda son auditoría, resolución de disputas, requerimiento regulatorio y evidencia de chargeback. Una procesadora de pagos preguntando "muéstrenme la prueba de que enviaron la confirmación de pedido el 14 de mayo" tres meses después encuentra un log vacío. Un regulador pidiendo a servicios financieros o salud prueba de notificación al cliente encuentra lo mismo. Un equipo de disputas de chargebacks necesitando demostrar notificación de despacho encuentra lo mismo.

El workaround estándar es capturar cada evento de send y webhook hacia tu propio data warehouse — S3, BigQuery, Redshift, Snowflake — y tratar el dashboard de Mandrill como una vista en vivo de 30 días en vez de sistema de registro. La mayoría de equipos que llevan más de 12 meses en Mandrill ya lo tiene montado. Los equipos que no, pero que necesitan retención larga, son aquellos para los que este argumento aterriza más fuerte. En nuestro lado, 365 días de retención es estándar, y tramos más largos están disponibles para industrias donde la retención de auditoría a siete años es la norma operativa.

Mandrill (ahora Mailchimp Transactional) está dentro de Intuit, con sede en EE. UU. Como prácticamente todos los proveedores cloud estadounidenses que sirven a clientes UE, Mailchimp apoya las transferencias de datos personales desde EEE, Reino Unido y Suiza hacia sus servidores en EE. UU. en el EU-US Data Privacy Framework certificado en julio de 2023. El DPF reemplazó al Privacy Shield invalidado por el TJUE en Schrems II en 2020. En diciembre de 2025, NOYB emitió un aviso público de que el DPF está bajo presión legal seria, citando el caso SCOTUS Trump v. Slaughter que cuestiona la independencia de la FTC — pilar de la arquitectura de enforcement que la Comisión Europea exigió al aprobar el DPF. Los alegatos orales en SCOTUS se escucharon en diciembre de 2025 y se espera ampliamente sentencia en junio o julio de 2026.

Si el DPF se invalida o debilita materialmente, el respaldo contractual de Mailchimp son las Cláusulas Contractuales Tipo (SCC), que aplican automáticamente vía el Data Processing Addendum. El problema con las SCC post-Schrems II es que requieren un Transfer Impact Assessment demostrando que las leyes de vigilancia estadounidense (FISA Sección 702, CLOUD Act) no socavan las protecciones — demostración que se ha vuelto legalmente difícil de hacer tras la admisión bajo juramento de la filial francesa de Microsoft en el Senado francés en junio de 2025 de que no puede garantizar soberanía contra autoridades estadounidenses. Para clientes en LATAM con regulación local (LOPD-GDD España, LFPDPPP México, LGPD Brasil, Ley 25.326 Argentina), el panorama es análogo — autoridades como AEPD, ANPD, INAI y SIC han endurecido criterio sobre transferencias internacionales. En nuestro lado, la pregunta no se plantea — estamos incorporados en UE, servidores en Stockholm y Fráncfort, DPA entre dos entidades UE.

No directamente. No corremos infraestructura SMS, y no planeamos hacerlo. Las relaciones con operadores, el compliance país-por-país de números telefónicos, la economía de códigos cortos y el panorama de fraude SMS son una disciplina operativa distinta de la deliverability de email, y los proveedores que lo hacen bien — MessageBird (ahora Bird), Sinch, Twilio — lo hacen a una escala que no igualaríamos. Para equipos que necesitan email transaccional más SMS transaccional, el patrón que funciona es: email por nosotros, SMS por Bird o Sinch. Ambos tienen APIs transaccionales limpias y opciones razonables de jurisdicción UE si eso le importa a tu DPO.

El API unificado email+SMS que Mandrill envía post-rebrand es una conveniencia real para flujos de notificación omnichannel. Si esa conveniencia es la razón estructural por la que estás en Mandrill, el cálculo de migración cambia. La mayoría de equipos con los que hablamos usa SMS solo para recuperación de contraseña o 2FA, donde el coste por mensaje está dominado por los fees del operador y el ahorro lado email en nuestra infraestructura ahoga el ruteo SMS ligeramente menos consolidado. Trabajamos la matemática caso por caso.

En su mayoría sí, con revisión de algunos helpers custom. Mandrill usa Handlebars como lenguaje base de plantillas con una capa de helpers custom y la sintaxis merge_vars de personalización que ha sido estable desde la versión original de Mandrill. Nuestro motor de plantillas es más cercano al Handlebars estándar, con el mismo patrón de sustitución por variable de merge y la misma sintaxis de bloques condicionales. El script de migración que corre nuestro equipo maneja típicamente el 90% de la conversión de sintaxis automáticamente. El 10% que necesita revisión manual suele ser condicionales profundamente anidados, helpers específicos de Mandrill (la familia {{#equal}} en particular tiene diferencias sutiles entre proveedores) y plantillas Mailchimp del lado marketing que importaban fragmentos.

Para equipos que usan plantillas almacenadas en Mandrill vía API (messages/send-template.json), los nombres de plantilla y variables de merge se recrean de nuestro lado durante la semana 1. El código de aplicación no suele necesitar cambios más allá de apuntar las credenciales SMTP o el endpoint REST a nosotros. Para equipos que renderizan Handlebars del lado aplicación y usan Mandrill puramente como relay, cambia aún menos.

Inbound se transfiere limpio. El webhook inbound de Mandrill rutea mensajes parseados al endpoint de tu aplicación, típicamente usado para creación de ticket desde reply, threading de conversaciones o automatización downstream. Nosotros enviamos el mismo patrón: ruteo de webhook inbound con payloads JSON parseados que se acercan al esquema de SES/Mandrill. Los registros MX se cambian durante la semana 1 junto a las actualizaciones de SPF y DKIM. La mayoría de integraciones inbound no necesita cambios del lado aplicación más allá de actualizar la lógica de verificación de firma del webhook para usar nuestro esquema HMAC en vez del de Mandrill.

El caso borde es equipos usando el Rules Engine de Mandrill para inbound — una feature que te deja definir condiciones del lado servidor sobre mensajes entrantes (p. ej., rutear mensajes con un patrón de asunto específico a un endpoint, otros a otro). Nuestro equivalente es lógica de ruteo del lado webhook que implementas en tu extremo, que es más flexible pero mueve la lógica condicional fuera de la configuración del proveedor hacia el código de aplicación. La migración suele simplificar esto; los equipos que intentaron mantener la config del Rules Engine de Mandrill dentro del proveedor frecuentemente encuentran su propio router de webhook más limpio una vez centralizado.

Para los primeros 12 meses y el comprador correcto, sí — el descuento es real. La elegibilidad es estrecha: cliente nuevo de Mandrill, inscrito o inscribiéndose en Standard/Premium/Legacy Monthly con cuenta creada en los últimos 90 días, en país elegible, sin compliance holds. Si cumples todo eso, el 50% off sobre 1M+ emails por 12 meses es una de las mejores ofertas de cabecera en el mercado transaccional. A 2M/mes (80 bloques), el descuento ahorra cerca de $640/mes durante un año, lo cual es relevante.

Lo que la promo no cambia es lo que pasa en el mes 13. El precio de lista regresa al tramo de volumen estándar, la precondición de plan de marketing sigue, y cualquier preocupación estructural sobre retención de logs o soberanía no se mueve. Para equipos cuyos drivers de migración son solo coste y cuyo volumen pega elegible de la promo limpio, quedarse en Mandrill los 12 meses y migrar en el mes 11-12 es estrategia legítima. Hemos hecho varias migraciones exactamente en ese cronograma y lo decimos abiertamente cuando el driver primario del cliente es el precio de cabecera durante la ventana promocional.