From legacy Postfix with house scripts to enterprise MTA, without losing a message.

"Why migrate at all if Postfix has been working?"

If Postfix has been working and the four scale signals are not lit, EMP recommends staying on Postfix. Approximately 20 percent of EMP discovery engagements end with the recommendation to stay and a refund of the unused execution-phase budget. The migration produces value only when the operational complexity of legacy Postfix exceeds the operational complexity of the target MTA, which happens when volume is above the 1 million daily ceiling, when multi-IP rotation requires external orchestration, when transactional and marketing streams require isolation, or when the team that wrote the custom scripting is no longer at the company. Below those thresholds the migration is structural over-investment; the budget produces more visible business impact when allocated to deliverability work (authentication, sender reputation, content optimization) than to MTA replacement. The honest framing reflects EMP business model: customers who pursue migration without the underlying justification end up with a more capable platform they do not need plus the operational learning curve of the new MTA, and the engagement ends with mutual frustration rather than customer success.

"How does EMP choose between PowerMTA and KumoMTA without bias?"

The selection criteria are documented and the discovery deliverable shows which variables drove the recommendation. PowerMTA wins when: budget includes 30,000 to 200,000 USD annual licensing, vendor support with enterprise SLA is required, compliance explicitly names a commercial MTA, in-house engineering team is small and prefers managed configuration. KumoMTA wins when: budget is constrained, open-source transparency is preferred for audit, in-house team has Rust or Lua scripting capability, the deployment is greenfield or significantly redesigned. The 55/45 split in EMP migrations historically reflects the real population mix; if EMP recommendations were biased toward one vendor the split would not converge to this ratio. EMP publishes the selection methodology in the discovery document section that the customer audits.

"What is the message loss risk during migration?"

Zero in EMP 2024-2026 migration history; the parallel delivery design is structured specifically to make message loss impossible. The application layer sends each message exactly once to the routing proxy; the proxy decides which MTA receives the message based on the current traffic split; the chosen MTA processes the message normally. Duplicate sends are prevented by the proxy's exactly-once delivery semantic. The message identifier reconciliation step running during parallel delivery verifies that each Message-ID logged at the source appears exactly once in the receiving provider's bounce or delivery logs; any discrepancy triggers investigation before cutover proceeds. The technical pattern is well-established (parallel running in IT system migration generally) and the email-specific variant has been used by Postmastery, Sinch Mailgun migration team, and similar specialist groups for over a decade.

"What is the cost of PowerMTA licensing year over year?"

PowerMTA licensing in 2026 ranges from 30,000 USD annually for small-volume deployments (under 5 million monthly) to 200,000+ USD for large enterprises (above 50 million monthly), with the specific quote depending on volume tier, support level, and contract length. EMP does not resell PowerMTA licenses; the customer contracts directly with the PowerMTA vendor (formerly Port25, acquired by SparkPost then by Bird) and EMP delivers the installation, configuration, and migration work separately. The economic comparison: a 10 million monthly program pays approximately 60,000-80,000 USD PowerMTA licensing annually plus the EMP migration fee of 14,500-28,500 USD one-time; the same program on KumoMTA pays zero software licensing and the EMP migration fee is comparable. Over 5 years the PowerMTA program pays approximately 300,000-400,000 USD in licensing the KumoMTA program does not pay; the calculus has to include the value of vendor support and compliance positioning that PowerMTA provides.

"Can EMP train our team rather than fully running the migration?"

Yes, the engagement structure adjusts to customer preference. The Discovery + Plan tier is the EMP-light variant where the customer team executes the migration internally using the EMP plan as the runbook; EMP delivers the document, conducts 2 readout calls, and is available for 4 hours of question-and-answer support during the customer execution. This works for organizations with capable in-house DevOps and email engineering teams that need the structured plan but not the hands-on execution. Approximately 35 percent of EMP migrations follow this pattern; the customer ends up paying 2,400 USD instead of 14,500-58,000 USD and absorbs the execution effort internally. EMP recommends the EMP-light variant explicitly when the customer team has the capability; the recommendation appears in the discovery readout when applicable. The Standard, Multi-IP, and Enterprise tiers exist for customers without the in-house capability or with bandwidth constraints that justify external execution.

"What if we discover during migration that a custom milter cannot be translated?"

The discovery phase explicitly inventories every custom component including milters and identifies translation gaps before execution begins. Approximately 5 to 15 percent of custom components have no direct equivalent in the target MTA; the gaps are documented in the discovery deliverable with the options: replicate the milter functionality via custom Lua scripts in KumoMTA (typically the lower-cost option because Lua is easier to maintain than C or Python milter code), implement the equivalent logic as application-level pre-processing before the message reaches the MTA (works for header rewriting and content transformation), accept the feature change and document the behavior difference for the customer team to approve. The custom work scope is fixed-fee in the execution tier; EMP does not discover custom work during execution and request additional budget. The 5-15 percent rate reflects the realistic distribution; some legacy environments hit 25-30 percent custom work which the Enterprise tier handles, some greenfield environments approach 0 percent.