Every mainframe modernization plan I've seen pitched dies on the same rock: the business can't tolerate a write freeze, and the engineers can't tolerate live dual-writes against a system they don't fully understand. So the project drags. The cutover date slips a quarter, then a year. The team rotates. The business loses confidence. The mainframe stays.
I spent five years at a US personal-lines carrier replacing a PL/I + IMS-DB rating engine with Ratabase. 100+ rating algorithms moved across without a write freeze. The pattern that made that possible is simple to describe and unobvious in practice, so it's worth writing down.
The constraint nobody names
A rating engine isn't one system. It's two systems glued together at runtime — a rules system (what the actuaries author) and an execution system (what the engineers operate). On a mainframe, those two are usually fused: the rule is a PL/I procedure, the lookup is an IMS-DB segment, the version control is the source control of the program that contains them.
That fusion is the actual reason re-platform projects fail. You can replace an execution system in months. You cannot replace a rules system in months — because the rules are the institutional memory of how the business prices risk, and every line has an actuary whose job depends on it landing the same way after as before.
The wrong framing: lift-and-shift
The naive plan is to lift the whole thing — rules and engine together — onto a new platform. That requires a freeze: while you're copying, no actuary can change a rule, because the change has to land in both systems or neither. So you negotiate a six-week window. Then regulatory filings come in late and you negotiate twelve. Then a new product launches and the freeze is dead. The project quietly switches to "parallel run."
Parallel run is the worst of both worlds: you operate the old system and the new one, you do dual-writes you barely trust, and reconciling differences becomes a full-time job for the team that was supposed to be sunsetting the mainframe.
The right framing: separate the rules
The pattern that actually ships: extract the rules into a platform-neutral representation first, then move the engine underneath. Ratabase, for what it's worth, is one such representation — but the specific tool matters less than the property you're after, which is: the rules can be authored, versioned, tested, and reasoned about independent of where they run.
Once that's true, modernization becomes a different problem. You're not racing a cutover. You're migrating execution runtimes for a corpus of rules that already exists. Today PL/I + IMS-DB runs the rule set. Tomorrow Ratabase runs the same rule set. Both can run it for as long as you want — including against the same live traffic.
What this looks like day to day
For five years, every translated algorithm followed the same choreography. An engineer (me, usually) sat with the actuarial SME who owned the rule. We read the PL/I together. We expressed the same decision tree in Ratabase semantics. We ran both engines side by side on a curated set of policies and reconciled cent-for-cent. When the two agreed across the full reconciliation set, the actuary signed off and the rule was switched — Ratabase became the source of truth for that rule, even though the mainframe kept executing other rules nearby.
At any moment, the rule set was half on each side. That was fine. The contract surface — "given these inputs, the rating engine returns this premium" — didn't change. Only the engine that satisfied it changed, one rule at a time.
Re-rate cycles were the natural correctness check. When a rating error was discovered, the operator would run a re-rate across the relevant state policy book. Individual cycles returned several-hundred-thousand dollars in customer refunds. Those numbers got people's attention, but more importantly they gave us a forcing function: the old-engine and new-engine results had to match, because real customer checks were going out based on them.
The lesson, generalized
If you're staring at a 2030 mainframe sunset and the official plan involves a cutover weekend, push back. Ask: can we externalize the rules first? If the answer is yes, the modernization horizon shifts from "a single risky weekend" to "an incremental migration with built-in correctness checks."
If the answer is no — if the rules really are inseparable from the engine — then your modernization isn't really a modernization, it's a rewrite, and the only question is whether the business knows that's what they're funding.
For most legacy rating engines I've seen, the answer is yes, actually. The rules can be externalized. People assume they can't because nobody has paid for the careful work of separating them. That cost is real and it's usually 12–18 months of one senior engineer pairing with actuaries. Compared to a four-year cutover that misses, it's cheap.