What is a boundary register?

It is a record of interfaces that names the owner, the contract, and the direction of travel for each part of the estate. It provides evidence that interfaces carry traffic after changes.

Why does code translation often fail?

According to IBM, translation alone often ignores the complexity of the system. Success requires focusing on data architecture, runtime replacement and transaction processing.

Is retaining a mainframe workload a failure?

No, Octopus Deploy states that retaining a workload is a legitimate strategy if modernisation is not justified or risks are too great. It should still be integrated with modern controls.

Mainframe Modernization: What Good Looks Like | Legacy Software Modernisation

Refurbishing a hospital that cannot close is the closest ordinary comparison to mainframe modernisation, because the plant can only be replaced while the wards stay full and the timetable is for the patients, who set its pace. Every decision in the work is shaped by that constraint. A plan that assumes a quiet period in which the old system can be switched off and the new one proved is a plan for a different organisation. The useful question concerns which parts of the estate can be given a limit, a designated lead and a route out, and the way those parts should be taken.

The definition of mainframe modernisation has become elastic enough to hide the work, so a system makes the better starting point. The system is a composite drawn from UK insurance engagements, and its shape will be familiar to users who have run a policy administration back office. A suite on z/OS, in service for longer than most of its current staff had been employed. It posted every transaction correctly. It passed every audit. No one could recall an unplanned outage. What had changed was the margin. The overnight batch cycle that once finished with full hours to spare now landed shortly before the first call centre shift logged on, and every new demand, whether a product variant, a regulatory return or a digital channel, arrived as one more change to the same undivided body of COBOL, JCL and copybooks.

The organisation had a name for this condition. It called the mainframe the problem. That description was wrong, and it was expensive, because it aimed every remedy at the platform while the missing seams in the estate around it went unaddressed.

Two attempts that renewed the surface and left the constraint

The first attempt replaced the customer-facing screens with a modern web front end. Users preferred it. It changed nothing about delivery, because every screen still called straight into the same online transaction programs, so each new release queued behind the same change control and the same narrow set of annual release windows. The presentation layer had been renewed; the change constraint had not been touched.

The next attempt was a data replication project. It copied policy data into a reporting platform and was declared a success at the steering group. Within weeks the reporting platform had quietly become another primary data store for a handful of derived fields, and no one could say which copy was authoritative when a customer disputed a figure. The programme had produced a new source of risk while claiming to reduce one.

IBM's account of this failure mode is blunt. Code translation by itself often misses the complexity that modernisation sets out to solve, and successful projects concentrate on system-level engineering concerns such as data architecture, runtime replacement and transaction processing, with the code treated as one part of that entire system (IBM). The insurer had translated nothing and still reproduced the failure, which is a useful reminder that the pattern carries the greater weight.

Reading the estate as capabilities with owned contracts

The turning point was a decision to stop treating the suite as one application and start treating it as a set of capabilities, each with an interface that could be owned, versioned and, in principle, replaced. That is the service-oriented idea, and it is worth stating plainly because it is so often mistaken for a technology choice. A service is not a protocol, a container or a cloud product. It is a piece of the business with a contract at its limit and a lead accountable for that contract.

Once the estate is read that way, the mainframe ceases to be a monolith and becomes a set of providers. Some of those providers are excellent and should be left alone. Some are cheap to replace behind their contract. Some are load-bearing in ways no one has documented, and the honest answer for those is that they stay until the documentation exists. Octopus Deploy says that maintaining a workload is a legitimate strategy where modernisation is not justified or the risks are too great, and that even a maintained workload benefits from an API gateway, tightened security controls and integration with modern analytics (Octopus Deploy). Retaining on those terms is not a failure to decide. It is a documented decision.

A register for limits carries this. It is not a diagram. This list of interfaces shows who is accountable, the direction of travel, the contract and the evidence that the interface still carries traffic after the last change at either end.

boundary: policy-enquiry
  version:      v2
  owner:        retail-servicing
  provider:     CICS PGMPOL01, read replica only
  consumers:    web, contact centre, partner API
  direction:    cloud reads mainframe; mainframe never calls cloud
  contract:     request(policyRef, asAtDate)
                response(status, coverSummary[], effectiveFrom)
  evidence:     dual-run comparison held open until every delta is explained

The register earns its place because it makes the awkward questions unavoidable. Who owns this interface? Which side is allowed to call which? What happens to the consumers when the provider changes? A programme that cannot answer those questions has not yet found its seams.

Five patterns that move work away from the transactional core

The first pattern is a contract at the seam, with shared copybooks stored inside the mainframe. The mainframe keeps its record layouts for the platform and its performance, while the interface translates between those layouts and a versioned request and response that consumers can rely on. Nothing outside the estate reads a copybook again.

Another step is moving the read path off the transactional core. Reporting, digital channels and analytics read from a replica that stays current, so the online region carries only the work that genuinely must be transactional. This change most reliably buys back headroom, but it is also the change most often attempted without an accountable lead, which leads to the emergence of a duplicate system of record.

The third is an anti-corruption layer between new services and old record structures. New code speaks a domain model. The layer maps it. Without the layer, every new service inherits the old naming and the old assumptions, and the estate grows another monolith in a modern language.

The fourth is strangling by capability, which puts the logic and its related data behind a contract. A screen-shaped cut moves the presentation and keeps the logic behind. A capability-shaped cut moves the logic and the associated data behind a contract, and can be proved by comparing behaviour before and after.

The fifth is evidence. Google Cloud's Dual Run captures and replays live production traffic from the mainframe onto the modernised application and compares the outputs side by side, so that correctness, completeness and performance are established before go-live, with any argument settled by the comparison itself (Google Cloud). For a risk-averse programme this is the difference between a test plan and a proof.

The routes themselves differ in what they preserve and what they put at risk. Replatforming keeps the language and the logic and changes the infrastructure and operating model beneath them; AWS says it preserves COBOL and PL/I while modernising infrastructure and processes, with refactoring moving the same business logic into Java-based services (AWS). Retaining keeps everything and still requires the interface work, so that the retained system can be reached without being opened. Replacement keeps nothing but the business outcome and carries the largest change to process, data and training. The choice follows from what the business needs to keep and what it can afford to change.

Sequencing the work so each step produces a proof

Work is sequenced by the evidence it produces. The first step is an assessment that produces an inventory of software, data stores, schedulers and interfaces, with an account manager assigned to each entry. Ensono's Application Migration Methodology follows this principle, identifying and solving conversion issues in advance of converting any code, with a data map that records the blueprint for the conversion (Ensono). The next step is to draw the target contract at each interface that has been selected for change, and to prove the contract with a dual-run comparison before any consumer is moved. The third step is to move one capability at a time, starting with a read-only or low-risk capability such as enquiry, and to keep the old path available until the comparison has held for a full business cycle. The fourth step is to retire the old path only after the limit log shows that no traffic has crossed it for a defined period. CGI uses a phased approach that ensures minimal disruption while maximising long-term value (CGI).

Proof that the interface remains stable after both sides change

A dated log of traffic and a comparison of outputs prove that a limit exists. Google Cloud's Dual Run captures production traffic from the mainframe, replays it against the modernised application, and compares the outputs side by side, which is how correctness and completeness are established before go-live (Google Cloud). The limit log contains the date of the last comparison and the name of the user who authorised it. The UK market for mainframe modernisation was valued at $376.3 million in 2025 and is projected to reach $583.42 million by 2030, a compound annual growth rate of 9.2%, according to MarketsandMarkets, which shows a mainstream programme across financial services and the public sector (MarketsandMarkets). The evidence requirement does not change with the size of the programme.

Keeping the decision reversible through governance

A software application that keeps its decisions reversible gives each interface a specific lead, a written direction of travel, and a contract reference. The contract holder can authorise a change to the contract, and the register logs the change with a date. The project does not need a single cutover date for all the systems. It needs a series of cutovers, each proved by a comparison and each small enough that a failure can be reversed by pointing consumers back to the old path. IBM says that successful modernisation concentrates on system-level engineering concerns such as data architecture, runtime replacement and transaction processing, and that the approach should make mission-critical systems competitive while retaining the transactional, security and resilience advantages of the mainframe platform (IBM). That is the shape of what good looks like: a mainframe that has not been abandoned, a set of new services that do not inherit the old assumptions, and a register that proves the limit is holding.

Sources

Code translation on its own often fails to address the complexity that modernisation sets out to solve

IBM

Mainframe Modernization: What Good Looks Like