Migración estructurada desde SendGrid, Mailgun, Mandrill, Postmark, Amazon SES, Mailjet o cualquier ESP hacia nuestra infraestructura europea (o hacia stack self-hosted del cliente cuando el caso lo justifica, dado que también hacemos migraciones salientes). Plazo de 4 a 6 semanas con calentamiento incluido. Entregable documentado: arquitectura final, IPs en estado operacional con placement validado, integración con tu aplicación funcionando, suppression list y plantillas migradas, DPA firmado con cláusulas locales hispanas. Garantía contractual de placement equivalente o superior al ESP de origen sobre la cohorte de envío principal del cliente. Pricing fijo por scope, sin cost overrun.
En breve
Migrar de ESP es trabajo operacional caro cuando se hace mal. La curva de aprendizaje sin guía produce típicamente: configuración DKIM mal aplicada que genera placement bajo durante semanas, calentamiento de IPs nuevas saltando pasos críticos que termina en IP quemada, suppression list mal migrada que resulta en mandar email a contactos que ya optaron por no recibir, plantillas migradas con variables rotas que generan errores en producción, eventos de webhook que no llegan al sistema interno por configuración incompleta. Cada uno de estos problemas es resoluble pero la suma de errores típicos en migración no estructurada termina costando 2 a 4 meses de operación degradada y reduciendo la conversión del email durante todo el período.
El mercado de consultoría de migración en 2026 tiene dos formas principales. Primera: consultoría por horas de especialistas independientes o agencias boutique, típicamente €120 a €250 por hora, alcance típico de 30 a 80 horas para migración mid-market. Coste total entre €4.000 y €15.000 según complejidad, con el cliente asumiendo la incertidumbre del coste porque los consultores no pueden predecir edge cases por adelantado. Segunda: servicios de migración gestionada del propio ESP de destino (Mailgun publica guía gratuita de migración desde SendGrid y ofrece ayuda de implementación pagada, similar patrón en mayoría de ESPs grandes), que es bien si te mueves a su plataforma pero no ayuda si los abandonas o te vas a self-hosted.
Resolvemos eso con scope cerrado y precio fijo. La migración tiene fases documentadas (assessment, configuración, calentamiento, cutover, validación, soporte post-engagement de 30 días), cada fase con criterios de éxito explícitos, y precio fijo según el tipo de migración. Si la migración tarda más de lo previsto por causa nuestra, absorbemos el coste adicional. Si tarda más por edge cases que el assessment no identificó, lo discutimos transparentemente con el cliente antes de continuar. La garantía contractual sobre el resultado (placement equivalente o superior al ESP de origen sobre la cohorte principal) elimina la incertidumbre del cliente sobre si la migración valdrá la pena.
La audiencia hispanohablante donde el producto entrega valor mensurable son SaaS que migran desde SendGrid o Mailgun por motivo Schrems II (procurement europeo del cliente final marcó al ESP estadounidense como problema de cumplimiento), empresas hispanas con compromiso de pricing en SendGrid escaland que descubren que el coste por encima de cierto volumen se vuelve prohibitivo, agencias hispanas saliendo de Mandrill después de los cambios de pricing y política de Intuit, equipos técnicos que decidieron mover a infraestructura propia por control técnico mayor pero necesitan ayuda con la transición.
Sobre el lado tributario, factura desde Viena en EUR. Para empresa española mecanismo de inversión del sujeto pasivo. Para empresa LATAM, tributación local. Pago anticipado al inicio del engagement con la mitad y al cutover con la otra mitad para mitigar el riesgo de ambos lados.
Sobre cuándo este producto encaja. Para migraciones simples (volumen bajo, configuración estándar SendGrid sin features avanzadas, sin requisitos regulatorios), el cliente puede ejecutar internamente con la guía gratuita del proveedor de destino o con consultor por horas. Encajamos cuando hay complejidad real: volumen alto que requiere calentamiento profesional, features avanzadas que necesitan trabajo de adaptación, requisitos regulatorios que necesitan documentación auditable, o plazo crítico (procurement europeo exige fecha de cierre antes del trimestre). Por debajo del umbral, recomendamos honestamente el camino DIY.
Sobre el patrón típico de migración hispanohablante que vemos los últimos dos años. El SaaS hispanohablante con cliente europeo medio tiene operación en SendGrid o Mailgun durante 2-5 años, se acomodó al setup, no quería cambiar. En 2024-2025 el procurement europeo del cliente final empezó a marcar Schrems II como problema concreto en las revisiones anuales. El SaaS recibe presión de cerrar antes de fin de trimestre. La migración estructurada con plazo y garantía resuelve esa presión en 4-6 semanas, lo que es ventana razonable para el cliente final. Sin estructura, la misma migración se extiende 3-6 meses con resultado incierto, y el SaaS pierde el deal.
Sobre la diferencia operacional entre migración estructurada y migración improvisada que justifica el coste. La migración improvisada típica: equipo técnico del cliente lee guía pública del proveedor de destino, hace setup en producción (no staging primero), corta tráfico parcialmente, descubre problemas durante el cutover (DKIM mal configurado que rompe alineamiento DMARC, suppression list incompleta que regenera contactos opt-out, plantillas con sintaxis incompatible que generan errores en producción, webhooks no configurados que rompen el funnel del CRM). Cada problema durante producción cuesta más que detectarlo en staging. La migración estructurada hace todo en staging primero, valida con seed accounts, descubre los edge cases antes de tocar producción. Es el equivalente a CI/CD bien hecho para migración de email.
Sobre los patrones específicos de migración por ESP de origen que vemos los últimos dos años. Migración desde SendGrid: típicamente cliente con setup mid-market que se acomodó al UI y herramientas de SendGrid, encuentra que el coste a volumen alto es desproporcionado, o procurement europeo marca SendGrid como problema Schrems II. La migración cubre setup técnico equivalente con features comparables del lado nuestro. Migración desde Mailgun: cliente con stack más técnico que ya integraba con API directamente, motivación típicamente compliance o consolidación. Migración desde Mandrill: clientes que se quedaron con Mandrill pese a los cambios de pricing y política de Intuit, ahora moviendo por presión de continuidad. Migración desde AWS SES: típicamente cliente con volumen muy alto donde el coste por email se acumula, o cliente con problemas de placement por reputación shared del SES.
Sobre la garantía contractual específica de placement equivalente que ofrecemos. La garantía cubre placement medido sobre cohorte principal de envío del cliente (definida en assessment de fase 1) durante 7 días post-cutover, comparado con baseline del ESP de origen capturado durante fase 1. Los criterios específicos: placement en Gmail consumer mediante Postmaster Tools, placement en Microsoft 365 mediante SNDS, complaint rate global, bounce rate global. Si cualquiera de estos métricas degrada más del 10% vs baseline durante los 7 días post-cutover sin causa identificable atribuible al cliente (cambio de contenido, lista, autenticación), aplicamos service credits documentados o continuamos trabajando hasta cumplir, según preferencia del cliente.
Sobre el patrón específico de migración con compliance regulatorio que vemos los últimos años. Empresa hispanohablante en sector regulado (banco bajo CNMV España o CNBV México, fintech bajo CFTC, healthtech bajo AEMPS o COFEPRIS) con auditoría regulatoria recurrente recibe observación del auditor sobre uso de ESP estadounidense post-Schrems II. La empresa necesita migrar a sub-procesador europeo con DPA documentado en plazo corto para próxima auditoría. La migración estructurada con plazo y entregable documentado cubre el requisito del auditor sin disrupción del flujo operacional crítico de la empresa. La documentación auditable del proceso forma parte del entregable, útil como evidencia de remediación ante el regulador.
Sobre la observación específica del patrón de migración de cliente con setup multi-canal complejo que vale documentar. Cliente típico mid-market tiene: ESP transaccional para email crítico (recuperación password, factura), ESP marketing para campañas (newsletters, promociones), herramienta de cold email con sub-cuentas para outbound B2B, sistema interno (CRM, ERP) que envía notificaciones vía SMTP. Migrar todo simultáneamente multiplica el riesgo; migrar secuencialmente extiende el plazo. La estrategia recomendada: primero canal crítico transaccional (alto valor, bajo volumen, baseline claro), luego marketing (volumen alto pero menos crítico), luego cold email (segregable, riesgo de reputación contenido), finalmente sistema interno (típicamente el más complejo de migrar por dependencias técnicas). Plazo total para migración completa de cliente con 4 canales: 4-6 meses con cutovers escalonados.
Sobre los criterios específicos de éxito que documentamos para cada migración con base en el assessment de fase 1. Métricas técnicas de baseline: placement por receiver principal (Gmail consumer y Workspace, Microsoft 365 corporativo y consumer, Yahoo, receivers regionales relevantes según audiencia), complaint rate global y por canal, bounce rate hard y soft, suppression efficiency (porcentaje de envíos a contactos correctamente suprimidos), authentication failure rate. La garantía contractual cubre que estas métricas se mantienen iguales o mejores durante 7 días post-cutover. Si alguna degrada más del 10% sin causa atribuible al cliente (cambio de contenido o lista), aplicamos remediation o service credits según preferencia del cliente. La política es transparente sobre criterios para que no haya ambigüedad post-cierre del engagement.
Sobre la observación específica del proceso de validación pre-cutover que diferencia migración estructurada de improvisada. Antes del cutover ejecutamos: validación de configuración técnica completa (SPF, DKIM, DMARC, rDNS verificado, autenticación SMTP funcional), envío de campaña pequeña de prueba hacia inboxes seed propias para validar placement, verificación de webhooks bidireccionales con sistema del cliente, prueba de suppression list activa con ejemplo conocido, validación de reportes de bounce y complaint feedback. Esta validación pre-cutover toma 24-48 horas adicionales pero elimina la mayoría de los problemas que aparecen en cutover improvisado. La diferencia operacional es sustancial: cutover validado tiene tasa de éxito post-go-live del 95%+; cutover improvisado tiene tasa típica del 60-70% con incidentes durante los primeros 7 días que requieren remediación urgente.
Sobre el patrón específico que justifica migración estructurada cuando el cliente tiene compromiso contractual con cliente final que exige plazo cerrado. Caso típico durante 2024-2026: SaaS hispanohablante con cliente europeo enterprise que firmó procurement marcando Schrems II como deadline de 90 días para presentar evidencia de sub-procesador europeo. Sin estructura, la migración del SaaS desde ESP estadounidense hacia proveedor europeo se extiende 3-6 meses con resultado incierto, lo que viola el deadline contractual y arriesga el contrato. Migración estructurada con plazo y entregable documentado completa el cambio en 4-6 semanas con confianza, lo que cubre el deadline con margen. La diferencia operacional es significativa: el cliente puede comprometerse al deadline contractual con confianza porque el plazo de la migración es predecible, no aspiracional.
Sobre el caso específico de cliente con proveedor estadounidense bajo contrato vigente que quiere migrar pero tiene compromiso contractual hasta cierta fecha. Patrón común: cliente con SendGrid Pro o Mailgun Foundry comprado anualmente con contrato hasta diciembre, quiere migrar pero la cancelación anticipada implica penalty significativo o pérdida de los meses ya pagados. La estrategia que aplicamos: configurar paralelización donde el cliente continúa usando el ESP de origen para parte del tráfico durante el período de overlap, mientras nosotros operamos progresivamente más volumen, hasta que la fecha de fin del contrato del ESP origen llega y el cliente cancela sin penalty. Plazo de paralelización típico: 2-4 meses antes del cierre contractual, lo que cubre completamente la migración con ventaja económica para el cliente. Coordinamos directamente con el ESP origen cuando el cliente lo prefiere para cierre limpio del contrato.
Sobre el patrón específico que vemos durante 2025-2026 de migración consolidada cuando empresa adquiere otra. Cliente que adquirió empresa hispanohablante con setup de email distinto al adquirente recibe presión de consolidar a un único proveedor para coherencia operacional, factura única, gobernanza unificada. La migración del adquirido hacia el setup del adquirente típicamente requiere: assessment del setup adquirido (que puede haber sido improvisado o legacy), mapeo de configuraciones hacia destino, migración estructurada con plazo. Coordinamos directamente con el equipo técnico del adquirido (que típicamente queda en transición durante el proceso de adquisición) para acceso a setup actual y validación de migración.
Sobre la observación específica durante 2025-2026 del impacto de cambios regulatorios en velocidad de adopción de migración. Cliente hispano con presencia en mercado UE recibe presión regulatoria continua post-Schrems II, post-bulk sender enforcement de Google y Yahoo de 2024, post-Microsoft enforcement de 2025. Cada presión regulatoria genera ola de migraciones desde proveedores estadounidenses hacia europeos. El patrón observable: ESPs estadounidenses (SendGrid, Mailgun, Mandrill, Postmark) pierden cuota de mercado entre clientes hispanos con cliente final europeo, ESPs europeos profesionales (incluyendo nosotros) ganan cuota proporcional. La migración estructurada con plazo cerrado se vuelve commodity necesario en lugar de upgrade opcional para esos clientes.
Sobre el patrón específico durante 2025-2026 de migraciones que combinan varios productos del catálogo en engagement único. Cliente que migra ESP también activa monitoreo gestionado para mantener visibilidad post-cutover, también activa DMARC gestionado para enforcement gradual durante el primer trimestre post-migración, también solicita auditoría inicial para baseline pre-migración documentado. Estos engagements combinados entregan valor superior que productos sueltos porque la coordinación interna entre equipos elimina la fricción de gestionar varios proveedores. El descuento típico para engagements combinados es del 15-25% según el bundle específico.
Abajo, los perfiles donde el plazo y la garantía contractual entregan valor mensurable.
SaaS español o latinoamericano con cliente europeo que marcó SendGrid o Mailgun como problema de cumplimiento. Necesita cerrar la migración antes del trimestre para no perder el deal. Plazo crítico, scope claro, garantía sobre el resultado.
Empresa que usaba Mandrill cómodamente hasta los cambios de pricing y política de Intuit. Necesita destino con compatibilidad de API cercana al Mandrill (template engine, webhook, suppression list) y soporte de migración profesional. Hemos hecho esa migración varias veces.
Operación con 10 millones plus al mes donde el coste de SendGrid se volvió desproporcionado para el valor entregado. Migración a infraestructura europea reduce coste mensual sustancialmente y a menudo paga el coste del proyecto en 2-4 meses.
Empresa con equipo técnico capaz de operar MTA propio pero sin experiencia previa en migración de ESP. Aprovecha nuestro engagement para hacer la transición correctamente y aprender el proceso. Salimos del scope con la operación funcionando y el equipo capacitado.
Empresa con varios productos SaaS, cada uno usando ESP distinto históricamente. Quiere consolidar a un único proveedor. Migración compleja con varios cutovers coordinados, requiere equipo dedicado por la complejidad.
Cliente regulado (banco, fintech, healthtech) donde el SLA con cliente final exige zero-downtime sobre comunicaciones críticas. La migración usa setup paralelo donde el ESP de origen y el destino operan simultáneamente durante días/semanas, con switchover gradual del 5% al 100% del tráfico, y rollback inmediato si cualquier métrica degrada.
Cliente sirviendo audiencias geográficamente separadas (UE + LATAM + EE.UU.) que migra a setup multi-PoP con routing geográfico. La migración configura PoPs distintos para cada audiencia, con coordinación de calentamiento independiente por PoP y validación final de placement por receiver geográficamente correcto.
Empresa que adquirió otra empresa con setup de email distinto y necesita consolidar a un único proveedor para coherencia operacional. La migración cubre la auditoría inicial del setup adquirido, mapeo de configuraciones del adquirido al destino, validación de que ningún flujo crítico se rompe, y cutover coordinado.
Cada fase tiene entregable concreto y validación. La migración avanza fase por fase, sin saltar.
Revisión completa de la configuración actual: ESP de origen, volumen mensual, uso de features (templates, webhooks, suppression list, sub-cuentas), integración con tu aplicación, requisitos de procurement, cualquier restricción específica. Salida: documento de arquitectura propuesta con cualquier edge case identificado.
Setup técnico en nuestra infraestructura: bloque IP dedicado asignado, configuración SPF/DKIM/DMARC para tus dominios, integración API o SMTP con tu aplicación validada en entorno de staging, suppression list importada del ESP de origen. La aplicación puede empezar a enviar a entorno de staging para validación.
Calentamiento profesional de las IPs nuevas durante 3 a 4 semanas. Volumen gradual desde 5% del envío total al inicio hasta 100% al final. Monitoreo continuo de placement, ajuste de curva por receiver. Durante esta fase parte del envío sigue saliendo por el ESP de origen mientras la cuota nueva se calienta.
Switch del 100% del envío al destino nuevo. Coordinación con cliente para escoger ventana de cutover (típicamente fin de semana de bajo tráfico). Monitoreo intensivo durante las primeras 48 horas post-cutover. ESP de origen mantiene cuenta abierta como fallback durante 7 días por si fuera necesario rollback rápido.
Validación de placement durante una semana completa post-cutover. Comparación con baseline del ESP de origen. Si placement es equivalente o superior (criterio de éxito de la garantía), firma de aceptación del cliente. Si no, ajustes hasta llegar al criterio o triggering de la garantía contractual.
Después de la firma de aceptación, 30 días de soporte continuo incluido para resolver cualquier issue de transición. Tiempo medio de respuesta documentado, ingeniero familiarizado con tu setup específico. Después de los 30 días, el cliente puede contratar el monitoreo de deliverability recurrente o continuar autogestionando.
Cada ESP tiene su propio sistema de templates con sintaxis específica (Handlebars en SendGrid, Mustache en Mailgun, Velocity en algunos legacy). La migración mapea las plantillas del ESP de origen al sistema de templates del destino, validando que las variables se resuelvan correctamente y los emails resultantes sean idénticos al original. Para clientes con cientos de plantillas, automatizamos parte del mapeo con scripts personalizados.
La suppression list (bounces, complaints, unsubscribes) se migra del ESP de origen al destino con validación de integridad: conteo de registros, formato, deduplicación. Para listas grandes (cientos de miles de registros) la migración es vía export bulk del ESP de origen + import bulk al destino, con período de overlap donde ambos ESPs respetan ambas listas para evitar enviar a contactos que optaron por no recibir.
Pricing fijo por tipo de migración. Sin cost overrun por causa nuestra. Precios incluyen el calentamiento de IPs en el destino y los 30 días de soporte post-engagement.
Para volumen 100K-1M al mes con configuración estándar.
Ideal para
SaaS pequeño-mediano migrando de SendGrid o Mailgun con setup estándar API REST sin features avanzadas.
Para volumen 1M-10M al mes con features avanzadas.
Ideal para
SaaS grande, e-commerce con email transaccional crítico, agencia con cuenta única de volumen alto.
Para empresa con varios productos consolidando a un solo proveedor.
Ideal para
Empresa con 3-5 productos SaaS o líneas de negocio, cada uno con ESP distinto, consolidando.
Para volumen 50M+ o requisitos regulatorios específicos.
Ideal para
Operación enterprise, sector regulado, multi-jurisdicción, arquitecturas novel.
Pago: 50% al inicio, 50% al cutover. Antes de IVA. Para empresa española mecanismo de inversión del sujeto pasivo. Para empresa LATAM tributación local de importación.
Consultor en retainer a €5.000 a €10.000 al mes durante 2 a 3 meses sale €15.000 a €30.000 total, que es 5x a 10x nuestro pricing Multi-plataforma. El consultor tiene más flexibilidad (puede pivotar scope mid-engagement) y atención más dedicada (te factura exclusivamente); nosotros tenemos pricing flat-rate y operamos varios engagements en paralelo, por lo que cada cliente individual recibe el scope del engagement pero no atención exclusiva fuera de cutover days. Para migraciones típicas, el modelo flat-rate funciona mejor. Para migraciones genuinamente inusuales (industrias reguladas, multi-jurisdicción, arquitecturas novel), el modelo retainer puede encajar mejor. La llamada de discovery ayuda a decidir cuál.
Sí. El producto opera en cualquier dirección. Hemos ayudado a varios clientes a migrar explícitamente fuera de nuestra infraestructura hacia otros ESPs o setups self-hosted, por razones no relacionadas con satisfacción (optimización de coste, consolidación regulatoria, mandatos internos). La migración funciona igual que las migraciones entrantes: arquitectura documentada, cutover limpio, calentamiento completo en el destino, garantía de 30 días sobre la nueva infraestructura. Tus datos exportan limpio, tus dominios transfieren limpio, no jugamos juegos de retención. Referencias de cliente para migraciones salientes están disponibles bajo petición.
La garantía cubre que el placement medido sobre la cohorte principal de envío del cliente (definida en el assessment de fase 1) es equivalente o superior al baseline del ESP de origen, medido por Gmail Postmaster Tools y Microsoft SNDS sobre 7 días post-cutover. Si no se cumple, no firmamos aceptación y trabajamos hasta cumplir o triggering de service credits documentados. La garantía no cubre cohortes secundarias menores, receivers regionales con baja muestra, o problemas causados por cambios del lado del cliente durante la migración (como cambios de contenido, listas, o autenticación).
Sí. Por debajo de 100.000 al mes, ejecutar la migración con la guía gratuita del proveedor de destino o con consultor por horas (10-20 horas a €120-€250) es opción más razonable económicamente. Encajamos a partir del Simple (€2.999) cuando el volumen, las features avanzadas o los requisitos de plazo justifican el coste. Discutimos honestamente esto en la llamada inicial.
Sí. DPA estándar RGPD firmado en onboarding incluye cláusulas contractuales tipo CE. Para empresa hispanohablante añadimos addendum con cláusulas equivalentes bajo ley local: LFPDPPP México, Habeas Data Colombia, Ley 25.326 Argentina, Ley 19.628 Chile, Ley 81 de 2019 Panamá, Ley 1581 Colombia. Documentación completa de procurement disponible para revisión jurídica del cliente antes de firma.
Plan de rollback documentado en cada migración. ESP de origen mantiene cuenta abierta durante 7 días post-cutover por si fuera necesario revertir. Si el rollback es necesario por causa nuestra, absorbemos el coste y reintentamos cutover con plan ajustado. Si el rollback es necesario por causa del cliente (cambios no comunicados durante el período de migración), discutimos en la llamada el coste adicional de retry. La política es transparencia sobre las causas, no atribución unilateral.
Llamada de discovery de 60 a 90 minutos cubriendo: ESP de origen y configuración actual, volumen y perfil de envío, features en uso, plazo deseado, requisitos de procurement, contexto de la migración (Schrems II, coste, control técnico). Salida es propuesta concreta con tipo de migración, plazo y precio fijo, o recomendación honesta de camino DIY con consultor si tu caso encaja mejor en ese segmento.
Sí. Algunos clientes deciden volver a ESP por razones operacionales (equipo de deliverability se fue, costo de mantener MTA propio sin valor proporcional, preferencia por simplificar stack). La migración del lado opuesto es similar en estructura: assessment del setup actual, configuración del ESP destino (típicamente SendGrid o Mailgun para clientes hispanohablantes con stack moderno), calentamiento de las nuevas IPs si el ESP las asigna nuevas, cutover, validación. Plazo similar de 4-6 semanas.
Sí, parte del scope estándar. La migración cubre re-configuración de webhooks para mantener flujo de eventos hacia CRM (Salesforce, HubSpot, Pipedrive) y data warehouse (Snowflake, BigQuery, Redshift). Los identificadores de mensaje cambian al migrar (cada ESP usa su propio Message-ID), lo que requiere lógica del CRM para no duplicar registros. Coordinamos con el equipo técnico del cliente sobre cómo manejar la transición de identificadores.
Mantenida si la migración se hace correctamente. La domain reputation está atada al dominio (ej: ejemplo.com) más que a la IP de envío. Mientras el contenido y la lista no cambien, la reputation del dominio se preserva durante la migración. Lo que sí cambia es la IP reputation (las IPs nuevas necesitan calentamiento), pero domain reputation acumulada no se pierde. Esto es ventaja sobre starting from scratch con dominio nuevo, donde tanto IP como domain reputation arrancan en cero.
Sí. Coordinamos cierre de cuenta del ESP de origen al final del engagement, con período de overlap de 7 días por seguridad. Durante el overlap, la cuenta del ESP de origen queda activa pero sin tráfico saliente (configuración de salida desactivada). Si en los 7 días post-cutover el cliente necesita rollback, podemos reactivar el ESP de origen rápidamente. Después de los 7 días, cierre formal de cuenta con archivado de logs según política del cliente.
Para Migración Multi-plataforma, secuencial es la default. La razón: hacer cutovers paralelos de varios productos en la misma ventana multiplica el riesgo de incidente. Si un cutover falla, ya hay otros 3 cutovers en proceso que no pueden parar. Secuencial con ventana de validación de 7 días entre cada producto es más conservador y entrega resultado más predecible. Para clientes con plazo crítico que requiere paralelo, lo discutimos con plan de contingencia más detallado.
Caso común con clientes empresariales. Identificación temprana en assessment de dependencias críticas: aplicación que envía vía API específica del ESP origen, integración con CRM que usa Webhooks específicos, scripts internos que dependen de respuestas API en formato del ESP origen. Para cada dependencia: opción A es modificar la dependencia para usar API destino (típico cuando el cliente tiene equipo técnico y disponibilidad), opción B es mantener doble setup durante período más largo (más caro pero menos disruptivo), opción C es construir capa de adaptación que traduce entre APIs (trabajo adicional de engineering). Documentamos las opciones con coste y plazo.
Solo envío. La recepción (inbound email, configuración MX, parseo de respuestas para automation) es producto distinto que algunos ESPs ofrecen pero nosotros no. Para clientes que necesitan migrar también recepción, recomendamos productos específicos según el caso: SendGrid Inbound Parse, Mailgun Routes, Postmark Inbound, Cloudflare Email Routing. La migración de envío puede coexistir con cualquier solución de recepción del cliente sin conflicto.
Política clara. Durante el assessment inicial revisamos el perfil del cliente contra nuestra AUP (no list-bombing, no listas raspadas, no contenido financiero engañoso, no infraestructura de phishing). Si el assessment revela que el tráfico actual del cliente viola AUP, comunicamos honestamente al cliente que no podemos servir ese tráfico, devolvemos el pago de assessment menos costos incurridos, y recomendamos otros proveedores donde el cliente pueda continuar. Esto pasa raramente (cerca del 5% de los engagements iniciales) pero la política es no aceptar revenue de tráfico problemático.
Discutimos tu ESP actual, volumen, features, plazo. Salida con tipo de migración recomendado y precio fijo, o recomendación honesta si DIY encaja mejor.
