Off PowerMTA without Gmail noticing, without losing reputation, without rewriting the app.

"Bird says the new pricing is industry-standard. Is the migration justified?"

The pricing justification from Bird reflects a strategic positioning argument rather than a cost-driver analysis; the underlying production cost of running PowerMTA per customer has not changed during 2024-2025 to support a 4-12x price increase. The pricing shift reflects post-acquisition portfolio repositioning, where Bird optimizes the PowerMTA revenue contribution toward the enterprise tier and accepts attrition at the lower tiers; that is a legitimate business strategy for Bird but it does not align with the customer interest. The "industry-standard" framing typically references comparable commercial MTAs (GreenArrow, MailerQ, Halon) that are similarly priced; what the framing omits is that the open-source alternative (KumoMTA) is built by the same engineers and delivers functional parity. The migration is justified when the savings exceed the migration cost over a reasonable payback horizon (12-24 months); the free audit produces the per-customer answer to that question.

"Will Gmail or Outlook reputation be affected by switching to KumoMTA?"

No, the receivers do not have visibility into the customer-side MTA technology. Receivers only see the IP, the DKIM signature, the sending domain, the message headers, and the message content; none of these change during the migration. The same IPs continue sending; the same DKIM keys continue signing; the same domains continue in the From and Return-Path; the same content continues being delivered. The reputation accumulated on the existing IPs over months or years carries through the migration without interruption because the reputation is anchored to the IP (controlled by hosting provider, not changing) and the DKIM domain pair (controlled by the customer, not changing). The documented AWeber migration to KumoMTA preserved reputation; the EMP 2024-2026 migration history records zero customers experiencing reputation degradation traceable to the MTA technology change. This is structurally different from the Postfix-to-MTA migration where the new IPs typically warm up alongside the old; in the PowerMTA-to-KumoMTA case the IPs do not change.

"How does the Lua scripting compare to declarative pmta.conf for our ops team?"

The transition introduces a learning curve but the productivity ceiling is higher in Lua. The standard PowerMTA configurations (virtual MTAs, DKIM signing, per-ISP throttling, bounce processing) have direct Lua equivalents that customers can copy-paste from the KumoMTA documentation and adjust for their specific values; the migration runbook EMP delivers includes the production-ready Lua for the customer's specific configuration. The Lua learning curve becomes meaningful when customers want to write conditional logic or integrate with external systems, which is exactly the scenario where Lua becomes more productive than PowerMTA: declarative configs cannot do "if Microsoft complaints above 0.05 percent then throttle this domain for the next 4 hours" but Lua can express that in 8 lines. The customer ops teams that adopt Lua productively are the ones that previously worked around PowerMTA limitations with external scripts; for those teams the Lua becomes a positive transition because the scripting moves into the MTA process where it is more efficient and more reliable.

"What is the support model after migration?"

KumoMTA support has two layers: community Discord and optional paid support from the KumoMTA team. The community Discord is active with the founding team and core contributors responding to issues; for non-emergency questions the community channel is typically faster than vendor email support. The paid support tier (kumomta.com/support) provides SLA-backed response for enterprise customers requiring contractual guarantees; pricing varies by SLA tier but is structured per-incident rather than per-license, which is significantly different from PowerMTA bundled support. EMP offers a maintenance retainer at 1,800 USD per month for customers preferring external support; the retainer includes quarterly health reviews and on-call response to incidents. The Enterprise migration tier includes 90 days of EMP on-call support included in the migration fee; after the 90 days the customer chooses retainer, KumoMTA paid support, or community-only based on the in-house operational maturity.

"Can we keep PowerMTA for some streams and KumoMTA for others?"

Yes, hybrid environments are valid and EMP designs them when the customer profile justifies. The typical hybrid pattern keeps PowerMTA running for streams that depend on specific PowerMTA features (proprietary integrations, Windows-specific deployment, SparkPost Signals analytics) while KumoMTA handles streams without those dependencies. The hybrid extends the timeline for full migration because both MTAs remain in production indefinitely until the dependencies are resolved; some customers operate hybrid permanently because the migration cost of the remaining streams exceeds the license savings. The hybrid does not affect IP reputation because the IPs can serve either MTA; the routing layer decides which MTA gets which traffic. Approximately 22 percent of EMP PowerMTA-to-KumoMTA engagements result in hybrid rather than full migration; the audit identifies which scenario applies during the initial discovery.

"What is the realistic timeline for our specific environment?"

The timeline depends on three variables documented during the audit. First, configuration complexity: number of virtual MTAs, custom routing rules, integration points; simple configurations migrate in 4-6 weeks, complex configurations require 10-16 weeks. Second, customer-side validation bandwidth: the parallel delivery period requires customer operations team review of the KumoMTA behavior under real traffic, which the customer team has to schedule; this is often the longest variable. Third, business calendar constraints: customers avoid cutover during peak sending seasons (Black Friday, year-end campaigns, regulatory deadlines), which can extend the timeline by 4-8 weeks if the migration straddles a peak period. The audit delivers the customer-specific timeline estimate; EMP commits to that timeline in the SOW with explicit milestones rather than discovering schedule slippage during execution.