Planificación de migración entre proveedores SMTP — el plan operativo de 4-6 semanas para no romper nada

"Tenemos que migrar de proveedor SMTP" es frase que aparece más a menudo de lo que parece: cambio de pricing del proveedor actual, problemas de deliverability acumulados, necesidad de IPs dedicadas, requisito regulatorio nuevo, consolidación de stack post-adquisición. La migración mal hecha rompe la reputación construida durante años en pocos días — y recuperarla cuesta meses. La migración bien hecha protege todo lo construido y mejora donde corresponde. Este post es el plan operativo de 4-6 semanas que separa una de la otra.

El error que mata: el "big bang switchover"

La migración fallida típica es así: el equipo cambia las credenciales SMTP del proveedor viejo al proveedor nuevo en producción durante un fin de semana, espera lo mejor el lunes. Lo que pasa: las IPs nuevas no tienen reputación construida, los receptores las ven como sender desconocido enviando volumen alto súbitamente (señal típica de spammer), el filtrado a spam empieza inmediatamente. Las dos primeras semanas, deliverability cae 30-60%. Tickets de soporte explotan: "no estoy recibiendo facturas", "el password reset no llega", "no me confirmaron el pedido". El equipo entra en pánico y considera revertir, pero revertir tampoco es trivial.

El big bang funciona solo si el volumen es muy bajo (menos de 5.000 mensajes mensuales — receptores no detectan patrón) o si el proveedor nuevo aplica políticas de warming automático (poco común). Para cualquier volumen serio (50.000+ mensuales), el big bang es garantía de problemas.

La alternativa correcta es migración por fases con warming en paralelo. Más lenta de planificar pero predecible en resultado.

Fase 1 (Semana 0) — Auditoría del estado actual

Antes de tocar nada, documentar exhaustivamente qué se está migrando. Esto evita sorpresas durante la migración.

Inventario de flujos de email. ¿Qué sistemas envían? Aplicación principal, billing, sistema de tickets, monitoring, backup notifications, marketing platform, sistema de reviews — cada uno es flujo separado. Para cada uno: volumen mensual, naturaleza (transaccional crítico, marketing opt-in, alerts internos, etc.), criticidad al business.

Inventario de IPs y dominios actuales. ¿Qué IPs están en uso? ¿Cuál es la reputación actual de cada una en Gmail Postmaster Tools, Microsoft SNDS, Yahoo CFL? ¿Hay IPs dedicadas o solo shared pool? ¿Qué dominios firma DKIM, con qué selectores? ¿Cuál es la configuración SPF actual y qué includes tiene?

Métricas baseline. Inbox placement actual (medido con seed list), bounce rate, complaint rate, ratio de envío exitoso. Estas son las métricas que se compararán durante la migración para detectar degradación.

Razón de la migración documentada. ¿Por qué cambiamos? Si es pricing, ¿qué se gana? Si es deliverability, ¿el problema es del proveedor o de prácticas internas? Si es features, ¿qué necesitamos del nuevo? Documentar razón evita perder objetivo durante el proceso largo.

Fase 2 (Semanas 1-2) — Setup paralelo y warming inicial

Configurar el proveedor nuevo en paralelo al actual. Sin migrar tráfico aún. Objetivos:

Configurar autenticación correcta en el dominio. SPF actualizado para incluir las IPs/includes del proveedor nuevo (mantener también las del actual — coexistencia). DKIM nuevo configurado en proveedor nuevo con selector distinto (por ejemplo nuevo2026q4) y publicado en DNS, mientras DKIM antiguo sigue activo. DMARC sin cambios todavía.

Verificar setup con tráfico de prueba. Enviar 50-100 emails desde el proveedor nuevo a una lista de prueba interna. Verificar autenticación pasa (mail-tester.com, Authentication-Results headers), DKIM firma con dominio correcto, llega a inbox.

Empezar warming de IPs nuevas con flujo controlado. Si el proveedor nuevo entrega IPs dedicadas, empezar warming con un flujo de bajo riesgo y alta engagement: por ejemplo, internal newsletters al equipo, notifications a clientes opt-in confirmados. Volumen muy bajo durante días 1-3 (1.000-2.000 diarios), incrementar progresivamente. Plan de warming completo en otro post de este blog.

Fase 3 (Semanas 2-3) — Migración por flujo, empezando por el menos crítico

Aquí es donde la migración progresiva muestra su valor. En lugar de mover todos los flujos a la vez, mover uno cada pocos días, empezando por el menos crítico al business.

Orden recomendado típico:

• Día 1: notificaciones internas al equipo (si algo va mal, lo notamos rápido sin afectar clientes)
• Días 4-5: monitoring alerts a destinatarios internos
• Días 7-9: notifications product no críticas (newsletters, weekly digest)
• Días 11-13: marketing opt-in (si aplicable)
• Días 15-17: transaccional bulk (recibos, status updates)
• Días 19-21: transaccional crítico (password resets, confirmaciones de pago)
• Días 22+: cualquier sistema legacy específico que requiera coordinación adicional

Para cada flujo migrado: cambiar la configuración SMTP del sistema correspondiente, monitorear métricas durante 24-48h antes de pasar al siguiente. Si aparece degradación (bounce rate sube, inbox placement baja, complaints crecen), pausar la migración y diagnosticar antes de continuar.

Importante: el proveedor antiguo sigue activo en cada flujo no migrado todavía. Sin downtime de servicio. Si algo va mal en un flujo migrado, revertir es cambiar credenciales de vuelta — minutos de operación, no horas.

Fase 4 (Semana 4) — Validación y monitoreo intenso

Con todos los flujos migrados, dos semanas de validación intensa antes de retirar el proveedor antiguo:

Métricas comparadas día a día. Inbox placement medido con seed list semanalmente. Bounce rate por flujo. Complaint rate por flujo. Engagement metrics (open rate, click rate). Comparar con baseline pre-migración. Esperable: ligera degradación temporal en deliverability mientras IPs nuevas terminan de construir reputación, recuperación gradual hasta o por encima del baseline.

Ticket monitoring. Cualquier ticket de cliente que mencione "no recibí email", "llegó tarde", "fue a spam", se revisa inmediatamente. Si el patrón aparece concentrado en algún flujo o receptor (todos los Gmail, todos los Outlook), indica problema específico que abordar.

FBL y Postmaster Tools activos. Inscribir las IPs nuevas en Microsoft SNDS, Gmail Postmaster Tools, Yahoo CFL desde el primer día. Monitorear ratios de complaint, reputation classification, autenticación.

Fase 5 (Semanas 5-6) — Retirada del proveedor antiguo

Cuando las métricas son estables y mejores o equivalentes al baseline, retirar el proveedor antiguo:

Limpiar configuración DNS. Quitar de SPF los includes del proveedor antiguo (esto previene que tráfico fraudulento desde IPs viejas pase autenticación). Mantener DKIM antiguo durante 2-3 semanas más para verificar emails antiguos en cola; después eliminar el registro DNS y archivar la clave privada.

Procesar bounces atrasados. Bounces que llegan vía Return-Path al proveedor antiguo deben procesarse antes de cancelar la cuenta. Configurar forwarding o exportar logs.

Cancelar contrato con proveedor antiguo. Solo después de las semanas de overlap. Documentar cancellation effective date, descargar logs históricos para archivo, confirmar facturación final.

El plan de rollback documentado

Antes de empezar la fase 3, documentar el rollback plan completo: qué pasos exactos, en qué orden, con qué credenciales, en qué sistemas, para volver al proveedor antiguo si algo va mal. Este documento debe poder ejecutarse en menos de 30 minutos por cualquier ingeniero senior del equipo, sin necesidad de consultar a quien hizo la migración.

Triggers para considerar rollback: bounce rate sube por encima de 5%, inbox placement cae más de 15 puntos, ratio de complaint sobre 0.5%, blacklist incident en IPs nuevas. Cualquiera de estos señala que algo está fundamentalmente mal y mejor revertir mientras se diagnostica.

El rollback no es fracaso — es opción operativa que protege el business. Equipos sin plan de rollback acaban tomando decisiones bajo presión durante incident, lo cual nunca termina bien.

Lecciones operativas frecuentes

El warming no se puede saltar. La tentación de "el volumen es bajo, no necesitamos warming" es fuerte y casi siempre equivocada. Aunque el volumen sea modesto, una IP nueva con reputación neutral enviando volumen súbito es señal sospechosa para receptores. Warming gradual evita el problema sin coste real.

La autenticación es 80% del trabajo. Si SPF, DKIM, DMARC están bien configurados y aligneados con el proveedor nuevo desde el inicio, la migración va bien por defecto. Si la autenticación está mal o parcial, todos los demás esfuerzos compensan poco.

Documentar todo durante la migración. Cuándo se cambió cada flujo, qué métricas mostraban antes/después, qué problemas aparecieron y cómo se resolvieron. Este documento es activo de la operación — la próxima migración (que habrá) usa esto como referencia.

Comunicación interna previene pánico. Equipos de soporte deben saber que hay migración en curso, qué tickets esperar, cómo escalar. Si soporte recibe "no llegó mi factura" sin saber del contexto, el ticket escala innecesariamente. Briefing simple del plan elimina mucho ruido operativo.

Una migración SMTP bien planificada parece aburrida — sin drama, sin pánico, sin tickets explotando. Esa es exactamente la señal de que se hizo bien. La migración exitosa es invisible operativamente; la migración fallida domina la atención del equipo durante semanas.