PowerMTA to KumoMTA migration

# PowerMTA: a VirtualMTA with its IP and per-domain rate (config directives)
<virtual-mta pool-a-1>
  smtp-source-host 198.51.100.10 mta1.example.com
  <domain gmail.com> max-msg-rate 180/min </domain>
</virtual-mta>

# KumoMTA: the same intent as an egress source + shaping (Lua + TOML helper)
egress_sources = {
  ['pool-a-1'] = { source_address = '198.51.100.10', ehlo_domain = 'mta1.example.com' },
}
# shaping.toml — per-provider, starting from the community baseline
['gmail.com'] max_message_rate = '180/min'

The Lua curve, and the missing interface

The same flexibility that makes KumoMTA powerful is also where the risk of a migration sits. Configuration as code means real programming decisions — how concurrency is handled, how policies are structured, where a hook reaches into a database — and a translation that copies PowerMTA’s settings literally into Lua, without understanding why each one was set, can reproduce old problems in a new syntax or introduce new ones. This is why we translate against how you actually send, not just against the old config file.

Then there is the interface, or the absence of one. KumoMTA ships no web UI on purpose; it exposes metrics and leaves the dashboard to operators. For a team coming from PowerMTA’s analytics that is a genuine gap on day one. Closing it is part of the migration rather than an afterthought: we stand up monitoring through Prometheus and Grafana, and where you want a managed view, an optional control panel, so the move to a more capable engine does not cost you visibility in the process.

Migrations that have already happened

This is not a theoretical path. KumoMTA’s own materials note the PowerMTA-to-KumoMTA route is the migration its users ask about most, and real senders have made it — Postmark moved its sending onto KumoMTA, and other high-volume operators across the ESP and platform world have adopted it for exactly the reasons above: the license cost, the modern architecture, and the freedom from a roadmap they no longer trusted. The point is not that everyone is leaving PowerMTA. It is that the migration is well-worn enough to be done safely, with a method rather than improvisation.

How we run the migration

Five stages, each gated on the one before. Nothing moves to production until the step ahead of it is validated, because the entire promise of the migration is that your reputation and your in-flight mail come through it intact.

1. Discovery & audit. We inventory every VirtualMTA, IP pool, sending domain, DKIM key and traffic-shaping rule in your current estate, so the translation works against the whole thing rather than a sample.
2. Configuration translation. Each PowerMTA construct is mapped to its KumoMTA equivalent in Lua, then reviewed against how you actually send rather than how the config says you do.
3. Reputation & authentication prep. DKIM keys, SPF and DMARC are carried across intact, and IP warmup state is confirmed, so reputation moves with you instead of starting over.
4. Per-pool cutover. Traffic shifts one IP pool at a time while we watch deferrals, bounces and placement — never a single big-bang switch that risks the whole estate at once.
5. Validation & handover. Seed-list inbox placement is measured before and after each cutover. Then we document everything, or stay on and operate KumoMTA for you.

What carries across

The promise of a careful migration is continuity, so it helps to be specific about what we carry from the old estate to the new one rather than rebuild. Your DKIM selectors and private keys move intact, so signed mail stays signed under the same identity providers already trust. Your SPF includes and DMARC policy come across unchanged, so alignment that passes today keeps passing tomorrow. The IP warmup state is preserved — the part that protects reputation most directly, since a warmed IP should arrive at KumoMTA already warmed rather than reset to zero.

Beyond authentication, we carry the things that quietly hold deliverability together. Suppression lists move across in full, because a single send to an address you had already suppressed can undo weeks of reputation work. Bounce categorisation and feedback-loop processing are rebuilt to behave the same way, so complaints and hard bounces keep feeding back into suppression instead of piling up unhandled. And the intent behind your traffic shaping — the per-provider rates and backoff you tuned over years — is translated into KumoMTA’s model rather than discarded, even though the syntax that expresses it changes completely. The aim throughout is that mailbox providers see the same sender behaving the same way, on a new engine they never needed to know about.

Why migrate one IP pool at a time?

The single most important choice in the method is what we refuse to do: switch everything at once. A big-bang cutover puts the entire estate’s reputation on a configuration that has never carried live traffic, and if anything is wrong — a mis-translated policy, a concurrency setting that behaves differently under real load — it is wrong everywhere, on production mail, with no quiet way back.

So we cut over per IP pool. One pool moves to KumoMTA while the rest keeps sending through PowerMTA, and we watch that pool closely against the baseline taken before the move — deferrals, bounce patterns, seed-list placement. If it behaves, the next pool follows. If it does not, we hold or revert that one pool while the rest of the estate carries on untouched, and fix the cause before trying again. The staged approach is slower than flipping a switch, by design. Rollback becomes a routine option rather than a crisis, problems surface on a fraction of your volume instead of all of it, and the providers see a gradual, unremarkable transition rather than a sudden change of behaviour that can itself draw scrutiny. For a multi-tenant platform the same logic runs tenant by tenant, so one customer’s migration can never put another’s mail at risk.

What does a KumoMTA migration really cost?

The headline is easy: KumoMTA’s licence is zero, against PowerMTA’s annual fee from around 8,000 dollars and up. The honest version is that free software is not free to run. The cost moves from a line item you paid a vendor to the people and time it takes to operate the engine well — which, depending on your team, is either a saving or a reason to have us operate it for you. What you do escape is per-message pricing: unlike a managed ESP, a self-hosted engine on dedicated IPs does not charge you more simply for sending more, which is precisely why it pays off at volume.

We model this properly during the audit rather than waving at “it’s open source, so it’s cheaper.” For a sender at the right volume, the combination of no licence, no per-message fee and dedicated IPs you already own usually lands well below the all-in cost of the alternatives. For a sender below that volume, the math can favour staying put, and we would rather tell you that before a migration than after one. One number worth setting expectations on: the migration itself is a project cost, not a recurring one, and it typically pays for itself within the first year purely on the licence saved at the eight-thousand-dollar floor, before the per-message savings at volume are even counted. After that first year, the open-source engine keeps earning while the licence would have kept billing.

The costs people underestimate are the ones that never appear on an invoice. Operating KumoMTA well takes time and a particular skill set, and the monitoring and dashboards PowerMTA bundled now have to be stood up and kept running. A team that migrates to escape a licence fee and then spends more engineering hours operating the engine has not saved money; it has moved the cost somewhere harder to see on a spreadsheet. That is not a reason to avoid migrating — for the right sender the saving is real and large — it is the reason to count the whole cost honestly, and to decide deliberately whether your team runs the result or we do. A migration justified by a number that ignores operating effort is the one most likely to disappoint later.

The mistakes a careful migration avoids

Most migrations that go wrong fail in predictable ways, and naming them is the clearest way to explain what care actually buys. The first is the literal translation: copying every PowerMTA directive into Lua without asking why it was set, which faithfully reproduces old workarounds and dead settings in a new language, and can turn a harmless static directive into an active bug under KumoMTA’s concurrency model. We translate intent, not syntax.

The second is the big-bang cutover — moving everything in one night because it looks faster, and learning the cost only when the whole estate is in trouble at once. The third is dropping the unglamorous data: suppression lists left behind, feedback loops not reconnected, warmup state reset, any of which can quietly poison the reputation the migration was meant to protect. The fourth is treating the missing interface as someone else’s problem — finishing the cutover and leaving a team to run a powerful engine from the command line with no dashboards, which is how a clean migration still ends in a deliverability incident a month later.

None of these is exotic. They are what happens when a migration is treated as a software swap rather than a reputation operation. The method exists so that each one becomes a step that gets checked, instead of a surprise that gets discovered.

Who operates KumoMTA after the migration?

Some teams want the keys back at handover; we document the estate — configuration, runbooks, the monitoring we stood up — and step away. Others would rather not staff a KumoMTA operator at all, and for them we stay on and run it as a managed service, with monitoring, authentication upkeep and incident response. Both are fine, and the migration itself is identical either way. The decision about who operates it afterward is one you can make at handover, not one you have to commit to before we start.