Mainframe-era systems are often the most reliable and the most feared parts of an enterprise estate. They have run revenue-critical processing for decades, but they are increasingly hard to change, hard to staff and hard to integrate with modern channels. Decomposing them is rarely optional in the long run, yet the way it is sequenced matters far more than how fast it is attempted. This piece argues that a deliberate sequence, built around protecting revenue-critical journeys, is the decisive factor in whether a mainframe decomposition succeeds or stalls.
Why sequence beats speed
A mainframe decomposition that prioritises speed tends to attack the parts that look easiest or most exciting, which are rarely the parts that reduce the most risk or unlock the most value. Worse, an aggressive pace tempts teams to cut over critical functionality before the replacement is proven, betting the business on an untested path. When that bet fails, the consequences land directly on revenue and customers, and the programme's credibility collapses with it.
Sequence, by contrast, is about choosing the order that continuously protects the journeys the business cannot afford to interrupt while steadily reducing dependence on the mainframe. A well-sequenced programme may look slower on a chart, but it carries far less risk at every step, delivers value incrementally, and almost always reaches a successful end state, whereas the fast-and-fragile approach frequently does not.
Mapping revenue-critical journeys first
The starting point is to understand which business journeys flow through the mainframe and which of those are revenue-critical or otherwise uninterruptible. This is a business analysis as much as a technical one, tracing how a customer transaction, a payment or a regulatory process actually moves through the system. The output is a clear view of which capabilities carry the most risk if they fail and which can be changed with relatively little exposure.
This mapping shapes the entire sequence. The most critical journeys are not necessarily decomposed last, but they are the ones around which the programme is designed to protect. Knowing exactly which paths must keep working without interruption lets you sequence the work so that those paths are either left intact until a thoroughly proven replacement exists, or migrated with the strongest possible safeguards and fallback.
The strangler pattern in practice
The dominant pattern for this kind of work is to gradually intercept and redirect functionality, building new capabilities around the edges of the mainframe and routing traffic to them piece by piece, until the old system is eventually surrounded and can be retired. This avoids the catastrophic risk of a single big-bang replacement and lets each increment be validated in production before the next begins.
Making this work requires a facade or routing layer that sits in front of the mainframe and decides, request by request, whether to serve from the new system or the old. Behind that facade, capabilities are extracted in a sequence that respects the journey mapping, with the riskiest revenue paths protected by running new and old in parallel and comparing results before fully switching over. The mainframe shrinks incrementally rather than being replaced in one heroic and dangerous event.
Data: the hardest part to sequence
The mainframe is usually the system of record, and its data is often the single hardest aspect of the decomposition. Extracting capabilities while the underlying data still lives on the mainframe creates a period where two systems must agree on the truth, and resolving that consistency is where many programmes struggle. Sequencing must account for this explicitly, deciding which data moves when and how consistency is maintained during the transition.
A common and pragmatic approach is to keep the mainframe as the authoritative source initially, with new components reading from it or from a synchronised copy, and to migrate ownership of data only once the surrounding capability is stable. Attempting to migrate the data and the logic simultaneously multiplies the risk. Separating the two, and sequencing data ownership transfer carefully after capability extraction, keeps each step's risk contained and reversible.
Maintaining the mainframe while you decompose
Decomposition takes years, not months, and during that time the mainframe must keep running reliably. A frequent mistake is to treat the legacy system as already dead, withdrawing investment and skilled people the moment the programme begins. That hollows out the very capability the business still depends on, and when an incident hits a mainframe nobody understands any more, the programme is blamed for an outage in a system it has not yet replaced.
Sustaining the mainframe through the transition means retaining or contracting the skills to operate and fix it, keeping its documentation current, and continuing to apply necessary changes even as capabilities move off it. The investment tapers as the system shrinks, but it cannot be cut to zero on day one. Treating the legacy estate with respect until it is genuinely retired is part of a responsible sequence, not a distraction from it.
What good looks like
A well-sequenced mainframe decomposition has mapped its revenue-critical journeys, surrounds the mainframe with a routing layer, extracts capabilities incrementally with parallel running and comparison on the riskiest paths, and sequences data ownership transfer separately and carefully. The mainframe stays well operated throughout, value is delivered in increments rather than promised at the end, and at no point is a revenue-critical journey exposed to an untested cutover.
- Map which business journeys flow through the mainframe and identify the revenue-critical ones.
- Put a routing or facade layer in front of the mainframe to redirect functionality piece by piece.
- Extract capabilities in a sequence that protects the most critical journeys until replacements are proven.
- Run new and old in parallel and compare results before switching over high-risk paths.
- Sequence data ownership transfer separately from capability extraction to contain risk.
- Keep investing in mainframe skills and operations until the system is genuinely retired.
Common pitfalls
The signature pitfall is optimising for speed over sequence, attacking the wrong parts first and cutting over critical functionality before it is proven. Migrating data and logic simultaneously is another, because it compounds two hard problems into one. Abandoning the mainframe operationally while it still carries the business is a third, and it tends to produce an embarrassing outage in the very system the programme exists to replace.
The programmes that succeed accept that decomposition is a long, incremental campaign and let the sequence be governed by risk to revenue-critical journeys rather than by enthusiasm for the new. They surround the mainframe, extract carefully, handle data separately, and keep the legacy running well until the last capability has moved. Sequenced this way, even the most daunting mainframe can be retired without ever putting the business at risk.
Need support applying this approach? Email sales@halfteck.com.