There is a version of legacy modernization that most consultants sell, and there is the version that actually happens when you are responsible for a system that processes $40 million in transactions overnight and cannot be down for more than four minutes.

The difference between those two versions is where most modernization programs break apart.

I have spent 27 years looking at what enterprise codebases actually mean, not what the documentation says they mean, but what the code itself reveals about the decisions that went into building it. When organizations modernize critical transactional systems, the failure mode I see most consistently is not technical. It is sequencing. They start in the wrong place, with the wrong assumptions, and then wonder why the effort stalls 14 months in with a parallel system they cannot fully trust and a legacy they cannot safely turn off.

This piece is about what the right sequence actually looks like, and why the first step has almost nothing to do with architecture selection.

The Systems That Cannot Tolerate a Rearchitecture Conversation First

COBOL runs an estimated 220 billion lines of active production code today. It processes 95% of ATM transactions globally, powers the core systems of 70% of major banks, and underpins significant government payment infrastructure. These are not historical footnotes. These are systems running this morning.

When we talk about modernizing critical transactional systems, we are talking about systems that have been optimized over decades for one thing: correctness under load. The irony is that the same reliability that makes them essential is what makes their replacement so difficult to plan. You cannot afford to be wrong about what they do.

The standard framing in modernization projects is to begin with architecture selection. Strangler fig or big bang. Replatform or refactor. Cloud-native or hybrid. These are real decisions, and they matter, but they are second-order decisions. They depend on something that most organizations do not have before they start: an accurate picture of what the current system actually does, at the logic level, under conditions that are not in any runbook.

Gartner has estimated that nearly 70% of data migration projects fail to meet their objectives. The most commonly cited causes are underestimated complexity and insufficient validation. Both of those are documentation failures, not architecture failures. You underestimate complexity when you do not know what is in the system. You fail validation when you do not know what correct behavior looks like.

What You Are Actually Dealing With Inside a Transactional Codebase

A transactional system is not a codebase in the way most modern developers think about codebases. It is a sedimentary record of business decisions.

A status field with 12 possible values, 5 of which no longer correspond to active business processes, is not a bug. It is a 2009 product retirement that nobody ever cleaned up, because cleaning it up would have required someone to know which downstream batch jobs were still referencing those values. Nobody wanted to find out the hard way.

A nightly JCL sequence where module B must run after module A because module A writes an intermediate file that module B reads is not in any architecture document. It is in the execution pattern of the job stream, which is readable if you know what to look for, and completely invisible if you do not.

A field called ACCT-TYPE with hardcoded processing logic buried in a nested EVALUATE statement is a business rule. It was probably documented somewhere in 1998. That documentation is almost certainly gone.

This is what 42% of critical business logic at risk looks like in practice. It is not that the code does not contain the logic. The code contains all of it. The problem is that the logic and the reasoning behind it are not the same thing, and you need both before you can modernize safely.

The Sequencing That Actually Works

The correct sequence for modernizing a critical transactional system has three phases before any architectural work begins.

Phase one: codebase archaeology. This is not a code review. It is not a documentation pass. It is a systematic reconstruction of what the system does, at the field level, at the job dependency level, and at the logic branch level, using the code itself as the primary source. Every hardcoded value gets catalogued and classified as either a constant or an undocumented business rule. Every conditional branch gets examined for the assumption it encodes. Every batch job dependency gets mapped. This work is slow and unglamorous. It is also the only way to know what you are actually modernizing.

Phase two: data lineage and integrity mapping. Before a single record moves, you need to know where it came from, what has happened to it, what depends on it downstream, and what the referential integrity rules are, including the ones that are enforced by application logic rather than database constraints. In COBOL environments, referential integrity is often maintained by the programs, not the database. If you migrate the data without understanding the program-level integrity rules, you will produce a technically successful migration with semantically broken data. The symptoms may not surface until six months later when a specific transaction type hits a code path that no one tested.

Phase three: impact analysis before any cutover. Every component that touches the system needs to be identified and evaluated before the modernization scope is finalized. This includes reporting systems, downstream batch consumers, integration layers, and anything that reads data from or writes data to the system, regardless of how indirect that relationship is. The enterprise IT asset disposition and data modernization considerations that arise during this phase are significant: virtual assets such as ETL jobs, scheduled processes, and derived datasets persist across execution layers and must be accounted for before any decommissioning sequence is planned. Removing a component without mapping its downstream impact is how you get silent failures that appear weeks after cutover.

Why the Strangler Fig Pattern Is the Right Architecture Choice, and What It Requires

Once the archaeology work is complete, the strangler fig pattern is the right architectural choice for most critical transactional systems. It is not the right choice because it sounds sophisticated. It is the right choice because it is the only pattern that allows you to fail small.

The pattern works by routing traffic through a proxy layer that can direct requests to either the legacy system or new components depending on which module has been migrated. New microservices or services are built alongside the legacy, functionality is migrated incrementally, and the legacy is retired in pieces rather than all at once. If something fails, traffic routes back. The fallback is always the system you already know works.

What is not often said clearly enough is that the strangler fig pattern requires more preparation than a big bang migration, not less. The proxy layer has to be built before any migration begins. Change Data Capture tooling has to be in place and validated before the first module is strangled. Observability across both the legacy and new execution paths has to be instrumented from day one, not added later. You need to be able to monitor latency, error rates, and business-level metrics on both paths simultaneously, because the moment you cannot see what both systems are doing, you have lost the ability to make safe routing decisions.

A Tier-1 European bank that used this approach to migrate off a mainframe COBOL ledger started by migrating read operations first. Using Change Data Capture to stream mainframe transactions to a cloud-native database, they offloaded 80% of the mainframe's MIPS consumption before attempting to migrate complex write logic. The write path is where the business rules live. You earn the right to touch it by proving correctness on the read path first.

The Hidden Risk That Kills Modernization Programs Midway

There is a failure mode specific to critical transactional systems that does not get discussed enough. It is not the big bang failure, where everything breaks at cutover. It is the slow accumulation failure, where nothing obviously breaks but the parallel systems begin to diverge in ways that are not immediately detectable.

This happens because data in a transactional system is not just records. It is state. The state accumulated in a legacy system over 20 years reflects thousands of business events that shaped it incrementally. When you build a parallel system alongside it, the new system starts accumulating state from the migration cutover point. If the business logic that governs how state changes is not perfectly equivalent between the two systems, the databases will drift. The drift is usually not visible in individual records. It shows up in aggregate reports, in reconciliation exceptions, in the batch job that runs at month end and produces totals that are off by an amount nobody can explain.

The way to manage this is to define equivalence tests before migration begins, not after. For every module being migrated, there should be a defined set of business-level outcomes that the new module must produce identically to the legacy. Not functionally similar. Identical. The comparison runs in parallel for long enough that every significant transaction type has been exercised. The module does not go live until equivalence is confirmed. This is slower than most project plans allow for. It is also the only way to avoid spending three months post-cutover explaining why the numbers do not match.

What the Workforce Situation Means for Timing

By 2027, the majority of remaining COBOL-era developers will have retired. That is not a projection. That is a demographic fact about a population of developers who were already senior when the systems they built went into production. Sixty percent of COBOL-dependent organizations already identify finding skilled developers as their single biggest operational challenge.

The knowledge these developers carry is not in the documentation. For the most part, there is no documentation. The knowledge is in their heads, and it is about decisions that are not visible in the code, only inferable. Why does this program skip records with a status of 7 in this context but process them in a different context? The developer who built it knows. The code does not explain itself.

This is the actual urgency. Not regulatory pressure, not cloud economics, not competitive positioning. The urgency is that the people who understand what these systems actually do are leaving, and when they leave, the only record of that understanding is the codebase itself, which is readable with the right tools and the right analytical approach, but only if someone reads it before the knowledge embedded in it becomes completely orphaned.

Where to Start

If you are responsible for a critical transactional system and the modernization conversation has already started, the first question to ask is not what the target architecture should be. The first question is whether anyone has done the archaeology.

That means: do you have a complete map of field-level business logic across the system? Do you have a dependency graph of every batch process and every downstream consumer? Do you know which parts of the codebase encode active business rules and which encode retired ones? Do you have equivalence tests defined for the modules you plan to migrate first?

If the answer to those questions is no, the architecture conversation is premature. Not because architecture does not matter, but because without that foundation, every architectural decision is based on assumptions about what the system does that may not survive contact with the actual code.

The systems that cannot fail are the ones that require the most preparation before any code moves. That preparation is not glamorous. It does not show up on a roadmap as a milestone. But it is what separates modernization programs that deliver from the ones that stall halfway through with two systems running in parallel, neither of which anyone fully trusts.