COBOL Modernization Should Skip the Relational Trap

For decades, COBOL modernisation followed a cautious two-step choreography. First, move the data from the mainframe into a relational database. Second, refactor the application into modern services. It looks prudent, it feels safe, and it is often structurally misaligned with how the original systems actually work. The relational detour introduces an artificial layer between legacy business logic and cloud-native architecture, and the result is predictable: join-heavy access patterns, fragile performance under concurrency and, in many cases, a second migration that nobody planned or funded. What has changed recently is not better code generation. It is the emergence of AI systems capable of semantic comprehension of a whole estate, and that makes a direct leap from mainframe to document model not only possible but often preferable.

COBOL data was never tabular

One persistent misconception is that COBOL systems are naturally tabular because they are old. They are not. COBOL copybooks encode hierarchical business aggregates: customers with nested policies, accounts with repeating movements, claims with structured subcomponents. In modern architectural language they already look more like aggregates than normalised entities. When those structures are forced into third normal form the system is not being modernised; it is being decomposed. That is where the impedance mismatch begins.

Across banking and public sector programmes the same three pathologies appear. The first is the join tax: a business entity that lived as one contiguous record on the mainframe becomes fragmented across tables, every API call has to reconstruct what used to be co-located, CPU consumption rises, query plans turn fragile and caching becomes mandatory. The second is semantic erosion: in normalisation workshops subtle business meaning gets lost, fields that were contextually grouped are technically separated, and downstream teams have to reverse-engineer intent from a schema instead of inheriting it from structure. The third is the double migration. Organisations that land on an RDBMS later discover that digital channels, event streaming and AI pipelines need flexible semi-structured access, and a second wave of transformation from SQL to NoSQL begins. Budget, timeline and organisational patience all take another hit.

What AI actually unlocks

Much of the market noise is about AI that writes or translates COBOL. That is not the breakthrough that matters. The inflection point is semantic extraction at estate scale: frontier models can parse thousands of copybooks, correlate batch programs with online transactions, identify the true business aggregates, detect dead or batch-only fields and reconstruct domain concepts that were fragmented across programs. Used this way, AI stops being a translator and becomes an architectural discovery engine. Consider a realistic insurance copybook:

01 POLICY-RECORD.
   05 POLICY-ID            PIC X(12).
   05 POLICY-HOLDER        PIC X(40).
   05 COVERAGE-TABLE OCCURS 50 TIMES.
      10 COVERAGE-TYPE     PIC X(10).
      10 COVERAGE-LIMIT    PIC S9(9)V99.

The relational interpretation is predictable: a POLICY table, a COVERAGE table, foreign keys, a join on every policy view and extra indexes to survive production load, with high read amplification for the simplest retrieval. Semantic extraction instead yields the natural aggregate:

{
  "policyId": "PL-884422",
  "policyHolder": "Maria Rossi",
  "coverages": [
    { "type": "FIRE",  "limit": 250000 },
    { "type": "THEFT", "limit": 50000 }
  ]
}

The storage model now matches the access model, and that alignment is the whole architectural advantage. AI adds disproportionate value in a second place too. Many copybooks carry fields used only for end-of-day reconciliation, regulatory extracts or archival reporting, and without semantic analysis teams migrate everything into the operational schema. With AI-assisted classification the operational document stays lean, a customer with an identifier, a name and an array of accounts, while batch-only attributes flow to cold collections, a data lake, a columnar warehouse or a time-series platform. Working sets shrink and document bloat disappears, which is exactly what digital workloads need.

Join cost against a single document read

Mainframe workloads were highly locality-aware, and many relational rewrites destroy that property by accident. Take a common banking API: fetch the customer, fetch the last twenty movements, compute a balance snapshot. On the relational path that is three or more joins, heavy reliance on covering indexes, sensitivity to cardinality changes and CPU that climbs under concurrency spikes:

SELECT c.*, a.*, t.*
FROM CUSTOMER c
JOIN ACCOUNT a ON a.customer_id = c.id
JOIN TRANSACTION t ON t.account_id = a.id
WHERE c.id = ?
ORDER BY t.date DESC
LIMIT 20;

On the document path it is a single read plus a bounded array scan:

db.customers.findOne(
  { customerId: "C123" },
  { accounts: { $slice: -20 } }
)

No joins, predictable latency, a smaller working set and far more stability under bursty traffic. The point is not raw speed. It is operational predictability, which is what a digital channel actually buys.

A public sector case

The pattern shows up in large public sector modernisation programmes. The starting point: mainframe batch plus online, highly hierarchical copybooks, roughly 800 million active records, unpredictable digital peaks. The initial strategy: mainframe to RDBMS to microservices. Within the first year the queries were increasingly join-heavy, database CPU had grown significantly, new digital channels were hard to support and schema evolution had turned rigid. The root cause was not the application code; it was the data model. The course correction was semantic analysis of the copybooks, identification of the business aggregates, document remodelling and a document-native platform. What followed was a large reduction in critical joins, stability under burst workloads, faster time to market for new APIs and a far better fit with AI and analytics pipelines. The real modernisation happened during the second architectural shift, not the first.

Shard-aware from day one

This is where otherwise solid programmes fail. When the dataset reaches hundreds of millions of entities, the document model has to be designed as shard-aware from the start, and four principles carry most of the weight. The shard key must follow access patterns, never the copybook: analyse the dominant queries, the API patterns and the traffic distribution before choosing, for example a hashed customer identifier:

sh.shardCollection(
  "bank.customers",
  { customerId: "hashed" }
)

Avoid temporal hot spots: monotonically increasing identifiers, pure timestamps and sequential keys are high-risk, hashed or well-balanced compound keys are safer, with time bucketing where it is really needed. Separate hot and cold data, with lean operational documents, heavy history in separate collections and tiered storage or TTL policies, so the working set stays memory-resident where it matters. And design for the ecosystem a 2026 modernisation has to serve: change streams, event-driven architectures, feature engineering pipelines, retrieval-augmented AI workloads and near real-time analytics.

When the direct leap is wrong

Architectural credibility requires acknowledging boundaries. The direct document leap may not be optimal when the workload is dominated by ad hoc relational analytics, when strict multi-row ACID across many entities is the norm, when lock-in to a legacy SQL ecosystem is extreme or when the organisation’s skills are purely relational. In those cases a hybrid approach is the pragmatic one. The point is conscious architecture, not ideology.

COBOL was never the real problem; misaligned data models were. For the first time we have AI systems that can read a legacy estate semantically rather than syntactically, and that changes the economics of modernisation. Programmes that still default to relational normalisation in 2026 risk rebuilding yesterday’s bottlenecks on tomorrow’s infrastructure. The path that is winning goes from the mainframe to semantic extraction to a document-native platform to an AI-ready data foundation. Direct, intent-preserving, cloud-aligned.