Sale del trap de licencia anual sin perder un correo. Migración con tráfico en paralelo, monitoreo de deliverability día por día y rollback plan listo si algo se desvía.
Migrar PowerMTA a KumoMTA suena simple: instalar uno, apagar el otro. La realidad es que entre uno y otro hay diferencias técnicas que, si se ignoran, generan caídas de inbox placement del 5-15% durante 2-4 semanas. Para una operación enviando 2M correos/mes, eso son USD 30.000-90.000 de ventas no atribuidas. El ahorro anual de licencia PowerMTA (USD 4.500-12.000) se pierde en una sola migración mal ejecutada.
PowerMTA agrupa lógica en VirtualMTAs configuradas en pmta.conf. KumoMTA usa event handlers Lua que toman decisiones por mensaje. La traducción uno-a-uno casi nunca es óptima: hay decisiones que se hacían vía VirtualMTA pool en PowerMTA que en KumoMTA se modelan mejor con get_queue_config + get_egress_path Lua. Hacer la traducción literal funciona pero pierde 30-40% de la performance de KumoMTA.
Las mismas IPs que tenía PowerMTA pasan a KumoMTA. La reputación construida sigue. Pero los filtros de Gmail/Microsoft detectan cualquier cambio de patrón de envío (timing, throttling, retry logic) como señal sospechosa. Si KumoMTA arranca con throttling distinto a PowerMTA, la reputación cae temporalmente aunque las IPs sean las mismas. El plan correcto incluye replicar el patrón de envío inicial.
En lugar de "apagar PowerMTA y prender KumoMTA", el plan correcto es: KumoMTA recibe 10% del tráfico desde día 1, sube a 25% día 7, 50% día 14, 75% día 21, 100% día 30. PowerMTA decrece en paralelo. Cualquier desviación de KumoMTA se detecta en el 10% antes de afectar al 100%. Y el rollback es trivial: subir % de PowerMTA, bajar % de KumoMTA.
Si el equipo técnico del cliente no entiende Lua scripting de KumoMTA, cualquier ajuste post-migración requiere llamar al consultor. Capacitamos al equipo durante el proyecto: 6 sesiones de 90 minutos cubriendo configuración base, event handlers, troubleshooting, observabilidad. El cliente termina con autonomía operativa real, no dependencia.
Migración asistida con paralelo gradual, monitoreo continuo, capacitación técnica. El cliente termina autónomo en KumoMTA con la confianza de que cada métrica está documentada antes y después.
Documentación de configuración actual PowerMTA: VirtualMTAs, pools, throttling, retry policies, bounce handling, integraciones. Baseline de métricas actuales: inbox placement por ISP, throughput, bounce rate, complaint rate. Identificación de casos especiales (transaccional vs marketing en pools separados, etc.).
KumoMTA instalado en infraestructura separada (puede ser mismo VPS o uno paralelo según preferencia). Traducción de la configuración PowerMTA a Lua event handlers, manteniendo paridad funcional. Tests internos con seed list antes de tocar tráfico real.
Cambio de routing en el sistema upstream del cliente: 10% del tráfico se envía a KumoMTA, 90% a PowerMTA. Selección del 10% es aleatoria por mensaje, no por segmento (para no sesgar mediciones). Monitoreo diario de KPIs en ambos sistemas.
Si KPIs de KumoMTA están a paridad o mejores que PowerMTA, subimos: 25% día 7, 50% día 14, 75% día 21, 100% día 30. Si KPIs se desvían, pausamos en el porcentaje actual y diagnosticamos. Rollback disponible en cualquier punto: bajar a 0% KumoMTA, 100% PowerMTA con cambio de configuración upstream.
6 sesiones de 90 minutos distribuidas en las 6 semanas: configuración base, event handlers Lua, throttling y queues, observabilidad con Prometheus/Grafana, troubleshooting común, casos avanzados. El equipo termina capaz de operar KumoMTA sin dependencia.
Cuando KumoMTA está al 100% del tráfico durante 7 días sin desviaciones, decomisamos PowerMTA. Entregamos reporte comparativo de métricas antes/después documentando el cambio. Si KPIs salieron mejores con KumoMTA, los números justifican el proyecto. Si salieron iguales, el ahorro de licencia justifica el proyecto.
Renovación próxima de licencia USD 4.500-12.000. Tiempo justo para migrar antes del vencimiento. Proyecto agendado para terminar 30 días antes de vencimiento, dando tiempo de buffer si algo se desvía.
PowerMTA cobra por volumen. Operación pasó de tier USD 6.000 a tier USD 12.000. Migración a KumoMTA elimina el costo escalonado. ROI del proyecto en 6-8 meses.
Equipo cómodo con Lua/Rust prefiere KumoMTA sobre PowerMTA legacy. Migración no es solo ahorro de costo: es modernización de stack. Mejor experiencia operativa para el equipo, menos legacy debt.
Lógica de routing compleja, integraciones con sistemas internos custom, observabilidad avanzada. Lua scripting de KumoMTA permite implementar lo que en PowerMTA requería parches. Migración con incremento de capabilities, no solo cambio de tecnología.
USD 1.500 es el mínimo para una operación simple: 1-3 IPs, marketing único (no transaccional separado), volumen <500k/mes, sin integraciones especiales. Casos más complejos: USD 2.400 (operación con marketing + transaccional separados, 4-8 IPs, volumen 500k-5M/mes). USD 3.800 (operación enterprise: 10+ IPs, múltiples streams, integraciones complejas con backend, observabilidad avanzada). Cotización exacta en consultoría inicial sin costo.
Con parallel run de 30 días, el riesgo material es bajo. El riesgo mayor es: descubrir durante migración que algunas integraciones legacy del cliente no funcionan con KumoMTA (típicamente apps muy viejas que asumían comportamiento específico de PowerMTA). Lo detectamos en discovery inicial. Si encontramos bloqueador insuperable, lo decimos antes de empezar y cancelamos sin cargo de penalización.
Durante el proyecto (30-45 días) y 30 días post-decomiso de PowerMTA: nosotros somos responsables de cualquier desviación de KPIs. Después de los 30 días post-decomiso, el cliente opera autónomo. Si quiere mantener nuestra presencia, plan de gestión continua USD 199-449/mes según complejidad. Sin plan, soporte hora-ingeniero USD 65/h disponible.
Sí, ese es el punto del parallel run. Durante los 30 días de transición gradual, el envío total no se detiene. PowerMTA y KumoMTA operan simultáneamente con el routing upstream distribuyendo el porcentaje correcto. La única "pausa" técnica son 2-3 ventanas de 15-30 minutos para cambios de configuración upstream (típicamente fuera de horario de pico).
Sí. La configuración PowerMTA queda documentada y backup completo se mantiene durante 6 meses post-decomiso. Si después de los 6 meses el cliente quiere volver (caso teórico que nunca hemos visto), el rollback es trivial pero requiere comprar licencia PowerMTA nueva.
Pasa rara vez pero es legítimo. Razones típicas: equipo técnico no se acostumbra a Lua, integraciones complejas requieren más trabajo del estimado, decisión organizacional. Si la decisión se toma antes del 50% del proyecto, reembolsamos 60% del pago. Después del 50%, el proyecto se factura completo (porque KumoMTA queda instalado y configurado, listo para usarse cuando el cliente decida).
Conversación de quince minutos por WhatsApp. Le decimos exactamente qué incluiría su cotización para esto, sin formularios largos.
