KumoMTA & Migration
Momentum reached end of maintenance. KumoMTA is where it goes next.
A Momentum to KumoMTA migration moves a sender off the end-of-life Momentum (Ecelerity) engine onto open-source KumoMTA — translating ecelerity.conf and its policy into Lua, preserving IP reputation and authentication, and cutting over one pool at a time. It is the most clear-cut migration in email infrastructure right now, because the engine you are leaving has already reached end of maintenance.
A Momentum to KumoMTA migration moves a sender off the end-of-life Momentum (Ecelerity) engine onto open-source KumoMTA, translating ecelerity.conf and its policy hooks into Lua, preserving IP reputation, DKIM and SPF, and cutting over one IP pool at a time. Momentum 4 reached end of maintenance on 1 March 2026 and support ends on 1 March 2027, so the move is a planned migration on your own timeline rather than an emergency after a break.
In short
- → Momentum 4 reached end of maintenance on 1 March 2026; support ends 1 March 2027 — the engine keeps running but stops getting fixes, then help.
- → KumoMTA was founded by former Message Systems people, including the architect of Ecelerity, so the destination was designed by the people who built the source.
- → ecelerity.conf, pathways, policy hooks and throttles are translated to KumoMTA Lua by intent, not copied line for line, so dead settings do not carry across.
- → Reputation lives on your IPs and domains, so DKIM keys and warm-up state carry across intact and providers see continuity, not a sudden engine change.
- → Cutover is one IP pool at a time with both engines running in parallel, so rollback is routine and problems surface on a fraction of the volume.
Most migration decisions involve weighing a stable engine against a better one. This one does not, because the source engine is already out of time. Momentum, the on-premise MTA that began life as Ecelerity and powered a large share of the world’s enterprise email for two decades, has reached the end of its supported life. The case for moving is not that KumoMTA is preferable, though it is; it is that staying means running production sending infrastructure that no longer receives fixes, on a clock that is already past one deadline and counting down to the next.
The good news for Momentum operators is that the natural destination is unusually well-suited, and not by coincidence. The open-source engine that has emerged as Momentum’s successor was built, in part, by the people who built Momentum itself. So this is less a leap into something foreign than a move to what the same minds designed once they were free of the commercial constraints that shaped the original. The migration is real work, but the destination was made by people who knew exactly where the source came from.
How urgent is the Momentum end-of-life, really?
The dates are not vague. According to Message Systems’ own end-of-life policy, maintenance for all versions of Momentum 4 ended on 1 March 2026, and support for all versions ends on 1 March 2027. Maintenance ending means no more defect fixes; support ending means no one to call when something goes wrong. For a piece of software sitting in a drawer that would be an abstraction. For the engine that carries your sending reputation, it is a real and growing exposure.
What end-of-life actually costs you accrues quietly. An unsupported MTA does not break the day support ends; it simply stops keeping pace. Deliverability requirements keep moving \u2014 new authentication enforcement, new provider expectations \u2014 and an engine that no longer ships updates falls steadily further behind them. Security fixes stop arriving for software that is exposed to the internet by design. And the day a genuine problem does hit, the vendor relationship that used to resolve it is gone. None of this forces your hand this week, which is precisely why it is dangerous: the absence of an immediate crisis makes it easy to keep running an engine whose support window is closing, until the migration you could have done calmly becomes one you have to do under pressure.
The Momentum estate you are leaving
It is worth naming what a Momentum deployment actually is, because the migration has to account for all of it. A typical estate is more than the engine: it is ecelerity.conf and the policy it references, often split across many included files accreted over years; a manager-and-node topology where configuration is bootstrapped out to multiple MTAs; spool directories holding in-flight mail; an SNMP agent feeding whatever monitoring you built around the MTA-MIB; and a body of policy written in Momentum’s own model — pathways governing inbound behaviour, hooks firing at points in the message lifecycle, throttles tuned per destination over years of operation.
All of that encodes real operational knowledge, and all of it is what end-of-life slowly strands. The config keeps working but stops evolving; the platform underneath it — the operating systems Momentum supports, the dependencies it assumes — ages out from under it; and the institutional knowledge of how to run it thins as the people who knew Momentum move on and no new ones learn an end-of-life engine. A Momentum migration carries everything that estate represents onto a platform that will keep moving forward; the software swap is the smallest part of the job. The first job is to read the whole of it, including the corners of ecelerity.conf no one has looked at in years but that are quietly shaping how your mail is sent.
Is KumoMTA really the successor to Momentum?
KumoMTA is not a third party’s guess at what a Momentum replacement should look like. It was founded by veterans of the same company — Mike Hillyer, who spent twelve years selling and supporting Ecelerity and Momentum from its OmniTI and Message Systems days, Tom Mairs, and Wez Furlong, who designed Ecelerity, the engine that became Momentum. The people who created the commercial product built the open-source one, with two decades of knowing exactly what worked and what they would do differently given a clean start.
That lineage matters for a migration in a concrete way, beyond the reassurance of it. The concepts a Momentum operator knows \u2014 pathways, policy hooks, traffic shaping, the whole mental model of treating mail flow as programmable policy \u2014 were carried forward deliberately into KumoMTA rather than reinvented from scratch, because the same people valued them. The result is that a Momentum administrator finds KumoMTA’s way of thinking familiar even where the syntax is entirely new. The destination was designed, in part, to be the place Momentum operators would eventually need to go.
Why Momentum operators were already leaving
End-of-life formalised a departure that had been underway for years, for reasons the engine’s own former staff have described openly. The commercial terms moved steadily against large senders \u2014 from perpetual licences, to a one-time fee per volume tier, to annual volume-based pricing — so the cost of running the same engine kept climbing. At the same time the company’s focus shifted from on-premise software to a cloud service, SparkPost, which many of its on-prem customers viewed as a direct competitor, and which made it harder to sustain investment in the on-prem product they actually ran. Squeezed on price and watching the return on a forced investment dwindle, large senders started looking for the exit well before the EOL dates made it official.
KumoMTA’s Apache-2.0 licensing answers exactly those grievances, which is unsurprising given who felt them first. There is no annual fee that rises with your volume, no vendor who can go under or raise prices or redirect your licence money into a service that competes with you, and no risk that the software stops working if you stop paying. Both Momentum and PowerMTA now sit under the same owner, Bird, on the same stalled trajectory \u2014 two legacy commercial engines maintained more than advanced. The open alternative removes the structural problem rather than swapping one vendor’s version of it for another’s.
What do you actually gain by moving to KumoMTA?
Leaving an end-of-life engine is reason enough to migrate, but it undersells the destination to frame the move purely as an escape. KumoMTA is not just a supported Momentum; it is a generation newer, and the gains are concrete. It is written in Rust, a memory-safe language that the US Office of the National Cyber Director and an NSA report have both recommended over the C and C++ that older MTAs are built on — a real security advantage for internet-facing infrastructure. Its configuration lives as code in version control, so changes are reviewed and tested rather than set live with an online command and hoped over.
The operational gains compound from there. KumoMTA is cloud-native, built to run in containers and scale horizontally across Docker or Kubernetes, where Momentum’s model predates that world. Its Traffic Shaping Automation reacts to provider responses in real time, adjusting throttles as mailbox providers change behaviour rather than holding to static limits that are wrong the moment a provider moves. Its telemetry runs through Prometheus and Grafana, richer and more standard than SNMP. And it integrates openly — webhooks, Kafka, direct database access through Lua hooks — so the MTA becomes a participant in your data pipeline rather than an island. None of these is a reason on its own to abandon a working engine; together, and on top of the end-of-life reality, they make the move a step forward rather than merely a sideways escape from a closing door. You are not migrating to stand still on supported software; you are migrating to a platform built for the decade you are actually sending in.
What changes technically, from ecelerity.conf to Lua?
The heart of a Momentum migration is translating ecelerity.conf and its policy into KumoMTA’s Lua. The two are closer in spirit than Momentum and a static config would be, because both treat sending behaviour as logic rather than as a flat list of settings — Momentum through its policy hooks and pathways, KumoMTA through configuration as code. That shared philosophy is what makes this translation, in places, cleaner than a PowerMTA migration. Most Momentum constructs have a direct KumoMTA equivalent.
| Momentum (Ecelerity) | KumoMTA equivalent |
|---|---|
| ecelerity.conf (C-style comments, include / readonly_include) | Lua "configuration as code" (init.lua + helper modules) |
| Pathways (inbound configuration grouping) | Listener and ingress policy expressed in Lua |
| outbound_throttle_connections / outbound_throttle_messages | Egress traffic shaping, with TSA reacting in real time |
| opendkim_sign | Native DKIM signing helper, selector per stream |
| Policy hooks (msg_gen_data_spool, inbound_session_count, …) | Lua event hooks, reading directly from your data sources |
| SNMP agent (MTA-MIB, RFC 2789) | Prometheus /metrics endpoint with Grafana dashboards |
| config set / config unset (online changes) | Version-controlled Lua, reviewed and reloaded |
| ec_dump_config (validate before start) | Configuration tested in staging before it touches production |
// Momentum: a binding with its throttles (ecelerity.conf, C-style syntax)
binding "pool-a-1"
source_ip = "198.51.100.10"
outbound_throttle_connections = "10/per_domain"
outbound_throttle_messages = "180/min/per_domain"
# KumoMTA: the same intent as an egress source + shaping (Lua + TOML)
egress_sources = {
['pool-a-1'] = { source_address = '198.51.100.10' },
}
# shaping.toml — throttles become per-provider shaping, TSA reacts live
['default'] connection_limit = 10 max_message_rate = '180/min'The one genuine shift to plan for is observability. Momentum exposes metrics over SNMP through the MTA-MIB; KumoMTA exposes them over a Prometheus endpoint with Grafana on top. The data is richer and the tooling more modern, but it is a different model, so part of the migration is rebuilding the monitoring rather than assuming an SNMP poller will simply point at the new engine. Done as part of the move, you come out more observable than you went in.
The method is the same, the source is just older
Migrating from Momentum follows the same disciplined path as any reputation-preserving MTA migration, and Momentum operators tend to appreciate that it is handled at their level rather than dumbed down. We inventory the whole estate first \u2014 pathways, bindings, pools, keys, hooks, throttles \u2014 because a Momentum configuration that has accreted over a decade hides decisions in corners, and a translation that misses them carries the gaps forward. Then we translate intent rather than syntax, map reputation and authentication across intact, cut over one IP pool at a time with both engines running in parallel, and validate placement against seed lists before and after each step.
The per-pool approach matters as much here as anywhere. It means the migration is never a single irreversible switch; it means a pool that behaves unexpectedly on KumoMTA can be held while Momentum keeps carrying the rest; and it means mailbox providers see a gradual, unremarkable transition rather than a sudden change of sending engine. For the large, sophisticated senders who tend to run Momentum, that staged caution is not bureaucracy \u2014 it is the only responsible way to move volume that a business depends on.
A path others have already walked
This is not an experimental route. The KumoMTA project itself documents the Momentum-to-KumoMTA migration, notes that it has helped several organisations make exactly this move, and publishes a primer on the process. The path is trodden, the equivalences are understood, and the destination engine was built by people who knew the source. We perform the migration independently and with the same rigour, because our value is in doing it carefully for your specific estate rather than in being the only ones who know it can be done.
When should you schedule a Momentum migration?
Because the migration is staged rather than instant, when you start matters as much as that you start. A per-pool cutover unfolds over weeks, and each pool’s move wants a stretch of stable, observable sending around it rather than the noise of a peak period. So the sensible sequencing is to begin well clear of your busiest windows — not in the run-up to a major campaign season, a holiday peak, or whatever your equivalent of crunch is — so that if a pool needs a pause or a second look, it happens against a calm baseline rather than your highest-volume days.
This is the practical reason the timing advice and the end-of-life dates point the same way. Support ending in 2027 sets the outer bound; your own sending calendar sets the rhythm within it. The combination argues for planning the migration now, into a quiet window you choose, rather than deferring it toward the deadline where the only slots left may overlap exactly the periods you would never want to touch your sending engine. We sequence the pool order and the schedule around your traffic, so the move threads between your peaks instead of colliding with them.
What we need to begin
Starting a Momentum migration is mostly a matter of access and inventory. The essential inputs are your current ecelerity.conf and its included policy files, a picture of your IP and pool layout, your DKIM keys and authentication setup, and an understanding of your sending streams and volumes. With those we can map the translation and scope the work accurately rather than estimating blind.
From there the engagement is the staged method already described, run at whatever pace your support window and sending calendar allow. You do not need to upgrade Momentum first, resolve its accumulated configuration debt yourself, or prepare the destination — untangling the old setup and standing up the new engine is the work, and it is ours. What you bring is the estate as it stands today; what you get back is that estate, faithfully carried onto a platform with a future.
Should you migrate before or after support ends?
The single decision worth making deliberately is when. Maintenance has already ended; support ends in 2027; and the gap between now and then is the window in which a Momentum migration is a calm, planned project rather than an emergency. Migrating while support still exists means there is a fallback if something unexpected arises mid-move, and it means the work happens on your schedule, sequenced around your sending calendar rather than forced by a failure.
The alternative is the trap that catches operators of every end-of-life system: because nothing breaks immediately, the migration slips quarter after quarter, until the engine finally hits a problem that an unsupported product cannot solve and the move that should have taken weeks of careful staging has to happen in days under real pressure. The reputation you spent years building is too valuable to gamble on an engine that has run out of road. The point of moving now is not that Momentum will fail tomorrow; it is that choosing your own timing is the last advantage an end-of-life engine still leaves you, and it is worth using before it is gone. There is also a quieter cost to waiting that operators underestimate: the institutional knowledge of how a particular Momentum estate was configured tends to leave with the people who built it, so the longer a migration is deferred, the more the decade of decisions encoded in ecelerity.conf has to be reverse-engineered rather than simply read and translated by the team that still remembers why each throttle is there.
FAQ
Momentum migration questions
Momentum is end-of-life — how urgent is this really?
Urgent enough to plan now, not urgent enough to panic. Maintenance for all Momentum 4 versions ended on 1 March 2026 and support ends on 1 March 2027, per Message Systems’ own end-of-life policy. The engine keeps running after those dates, but it stops getting fixes and then stops getting help, on a platform that handles your sending reputation. The right response is a deliberate migration on your timeline while support still exists, rather than an emergency one after something breaks and there is no one left to call.
What happens to our ecelerity.conf policy and scripts?
They are translated, not discarded. Years of Momentum policy — pathways, hooks, throttles, DKIM signing — encode real decisions about how you send, and we map that intent into KumoMTA’s Lua rather than copying it line for line. Momentum’s policy model and KumoMTA’s configuration-as-code are actually a natural fit, since both treat sending behaviour as logic rather than static settings, which makes the translation cleaner than a PowerMTA migration in some respects.
Will our sending reputation survive the move?
Yes, handled correctly. Reputation lives on your IPs and domains, not in Momentum, so it stays with you when the migration preserves DKIM keys and warmup state and moves traffic gradually. We cut over one pool at a time so mailbox providers see continuity rather than a sudden change of engine, which they never need to know happened at all.
Can we run Momentum and KumoMTA side by side during the cutover?
Yes, and that is exactly how we do it. A per-pool cutover means both engines run in parallel for the duration: KumoMTA takes one pool while Momentum keeps the rest, and the balance shifts as each pool is validated. That parallel period is what makes rollback a routine option rather than a crisis — a pool that misbehaves on KumoMTA can be held while the others carry on.
We rely on Momentum’s SNMP monitoring. What replaces it?
KumoMTA exposes its telemetry through a Prometheus metrics endpoint rather than SNMP, with ready-made Grafana dashboards on top — over a hundred metrics covering queues, delivery, bounces and system health. It is a more modern observability path than the MTA-MIB SNMP model, and part of the migration is standing it up so you are not less observable after the move than before it.
Is KumoMTA genuinely the successor to Momentum?
As directly as software lineage gets. KumoMTA was founded by former Message Systems people — including Wez Furlong, who designed Ecelerity, which became Momentum. The team that built the commercial engine you are running built the open-source one you are moving to, with the benefit of knowing exactly what they wanted to do differently. That does not make the migration automatic, but it does mean the destination was designed by people who understood the source intimately.
We are still on Momentum 3, not 4. Does that change anything?
It makes the case stronger, not weaker. Older Momentum releases are further past their support horizon and further from modern deliverability requirements, so the risk of staying is higher. The migration method is the same regardless of version — inventory, translate, preserve reputation, cut over per pool — and we handle the specifics of whichever release you are on rather than requiring you to upgrade Momentum first just to leave it.
Start with the audit.
Twenty-five points across authentication, reputation, infrastructure and compliance — a written assessment, no charge and no obligation. It tells both of us exactly what we are working with.