PowerMTA to KumoMTA, remapped and operated — translation is the easy part.

No, and that is the heart of why this migration is more work than it looks. There is no automatic converter because the two are not dialects of one language — PowerMTA's pmta.conf is a flat file of directives parsed once at startup, while KumoMTA's configuration is Lua that runs at delivery time and hooks into lifecycle events. Translating one to the other is concept remapping, not find-and-replace: a virtual-MTA block becomes an egress source, a retry ladder becomes adaptive traffic shaping, bounce rules become a Lua classifier. KumoMTA's own team offers paid config-conversion for exactly this reason. A managed migration is that remapping done by people who have done it before.

Two reasons, and neither is that PowerMTA is bad — it was the commercial standard for two decades for good reason. The first is the license server: PowerMTA checks a license periodically, and if that validation fails — an expired file, a connectivity problem reaching the licensing server — the MTA stops accepting new messages. That is an external dependency on a vendor's infrastructure sitting in the critical path of your sending. The second is cost and architecture: PowerMTA's licensing runs around $8,000 a year, while KumoMTA is Apache-2.0 open source with no license file and no phone-home, built in Rust and cloud-native from the start. Below roughly five million messages a day, the open-source engine wins the math cleanly.

Not if it is done as a staged cutover rather than a switch flipped overnight, which is exactly why the process matters more than the config translation. The reputation you have built on your sending IPs is the asset worth protecting, so a proper migration runs KumoMTA in parallel with PowerMTA first, sending a small slice of traffic — five to ten percent on a canary path — while the main domain reputation stays untouched. Throughput, latency, deferral, and bounce categorization are compared against PowerMTA until parity is proven, then traffic ramps gradually from ten to fifty to ninety to a hundred percent over about two weeks. Done this way, the move is invisible to mailbox providers. Postmark migrated its entire PowerMTA estate to KumoMTA this way and kept sixteen years of reputation intact.

Lua is the scripting language KumoMTA uses for configuration instead of a static file — your settings become code that executes, which is what gives KumoMTA its programmability. It is one of the easier languages to learn; Cisco and Adobe Lightroom embed it for the same reason, and a simple conditional in a KumoMTA policy is readable even if you have never written Lua. That said, the learning curve is real and it is the honest reason some teams hesitate: writing and debugging policy, traffic-shaping rules, and bounce classifiers is a genuine upfront investment. A managed migration removes that requirement — we write and operate the Lua so your team does not have to learn it to keep sending.

Weeks, not days, and that honesty matters more than a fast-sounding number. A typical engagement runs in phases: configuration translation in the first weeks — virtual-MTAs to egress sources, retry intervals to traffic shaping, bounce rules to Lua classifiers — then a shadow deployment carrying a small canary share, then a progressive cutover ramping traffic over about two weeks, then decommissioning PowerMTA with a cold standby kept for a month as insurance. The exact length depends on how intricate your existing pmta.conf is and how many domains and streams you run. Anyone promising a same-week migration of a real production estate is describing a rollback waiting to happen.

Yes — the IPs and the reputation built on them are the asset the staged cutover exists to protect, so they carry through the move rather than being replaced. KumoMTA sends from the same dedicated IPs your PowerMTA setup used; the shadow-and-canary sequence is designed so mailbox providers see no change in the sending identity, only in the engine behind it. The years of reputation carry across untouched, the way Postmark kept sixteen of them.

When the move would cost more than it returns, and there are real cases. If you send well above five million messages a day and depend on SLA-backed enterprise support from an established partner network, PowerMTA's mature services ecosystem may be worth its license. If your team has deep PowerMTA expertise, no appetite for Lua, and no plans to run the new engine themselves, an unmanaged migration can leave you worse off — there are documented cases of teams reversing back to PowerMTA when Lua complexity outweighed the license savings. The managed path exists precisely to resolve that tension: you get KumoMTA's economics and architecture without owning the Lua operations. But if none of the reasons to move apply to you, the honest answer is to stay on PowerMTA.