The 5 mainframe modernization risks, and how to de-risk migration at the data layer: discover, tokenize, and protect sensitive data with zero code changes.
Mainframe modernization risks fall into five categories:
The most dangerous is the one team's plan for last: when you move workloads off the mainframe, the protection model that worked in an isolated environment does not carry over.
Without a data-centric plan, you do not modernize your security; you migrate your risk.
This guide breaks down all five categories of mainframe modernization risks, then gives you the de-risking playbook that the modernization-vendor content space leaves out:
The goal is not to talk you out of modernizing, but rather, it is to help you modernize without exposing the regulated data your business runs on.
Mainframe modernization is the process of restructuring how business logic runs, where data lives, and how mainframe systems connect to the rest of the enterprise.
It can mean rehosting workloads on cloud infrastructure, rewriting Common Business-Oriented Language (COBOL) into modern languages, wrapping existing systems in application programming interface layers, or retiring applications outright.
Most enterprises pursue some blend, applied on a workload-by-workload basis.
Modernization is the restructuring effort; mainframe migration is the act of moving a workload or its data, which is one modernization tactic; and mainframe security is the discipline of protecting the data that resides on the mainframe.
The last one is that dimension modernization projects are routinely underplanned, which is why securing mainframe data belongs in the migration plan from day one, not after cutover.
According to IBM's Institute for Business Value, 71% of Fortune 500 companies still run their most critical workloads on mainframes.
An estimated 220 billion lines of COBOL code remain in production worldwide, much of it processing financial and personal records that make legacy systems a primary target for breaches.
Lift-and-shift alone is technical debt relocation, not modernization, because moving a workload to a cloud virtual machine does not reduce COBOL dependency or make the data accessible to modern applications. It does, however, change where your sensitive data travels and who can access it, which is why risk, not cost, should drive the decision.
The risks of mainframe modernization cluster into five categories.
The first three are technical:
The other two decide the business outcome:
Failed modernization projects routinely run well over budget and timeline, and the most common root cause is incomplete business-logic mapping before work begins.
The same is true of data: teams that do not know exactly what sensitive data they hold before they move it inherit every downstream consequence of that blind spot.
So is mainframe migration safe? It is when the regulated data is discovered, classified, and neutralized before it moves. The sections below walk through each risk category and then show how a data-centric approach eliminates the most expensive one.
Mainframe data is stored in legacy formats that predate modern databases and standard data-protection methods.
Converting Extended Binary Coded Decimal Interchange Code (EBCDIC) text and packed-decimal (COMP-3) numeric fields into relational formats can introduce rounding and translation errors that corrupt financial and customer records. A single conversion defect becomes a financial misstatement, not a bug you patch next sprint.
When EBCDIC and COMP-3 fields are decoded into readable values and staged for migration, sensitive data such as account numbers and personal identifiers sits in clear text across pipelines, test environments, and cloud landing zones.
Integrity and exposure are the same problem viewed from two angles, and both are solved by protecting the data element itself rather than the perimeter around it.
Mainframe systems frequently run decades-old COBOL, Assembler, or PL/I with minimal documentation. The engineers who wrote it are often retired, and the edge cases and regulatory workarounds live in their memory rather than a specification. Reverse-engineering that logic is the most common reason modernization timelines blow up.
Tightly coupled dependencies make it worse because changing one component can trigger unpredictable breakage across interconnected systems.
Generative AI tools now assist with translating COBOL into Java or C#, but they can introduce logic errors and hallucinate dependencies, which is why AI-assisted COBOL conversion demands human review and automated test harnesses. Automated conversion typically requires substantial manual remediation before the output is production-ready.
Mainframe applications are architecturally tuned for ultra-low-latency input and output. Moving those components to a distributed or hybrid cloud environment can inflate transaction times and cause batch processing windows to miss their deadlines.
For banking and healthcare, an hour of unresponsiveness translates directly into lost revenue and regulatory penalties, which is why secure, controlled data pipelines matter as much as raw performance.
The cutover is the highest-risk moment. The 2018 TSB Bank migration is the case every team should study: the data migrated, but the new platform immediately failed and left a significant share of its 5.2 million customers locked out of their accounts for weeks, with disruption and remediation costs running into the hundreds of millions of pounds (Financial Conduct Authority).
TSB did not fail on technology choice, but due to inadequate planning and testing of what its existing system did, the same gap that produces unprotected data exposure during a move.
Mainframes traditionally ran in isolated, batch-oriented environments. Transitioning those workloads to open, web-accessible cloud environments expands the attack surface and exposes applications to access paths they were never designed to defend. The protection model has to change the moment data leaves that controlled environment.
Compliance scope expands with it. When data moves to a cloud-native environment, the compliance obligations under the Payment Card Industry Data Security Standard (PCI DSS), the General Data Protection Regulation (GDPR), and the Health Insurance Portability and Accountability Act (HIPAA) extend to every downstream system that touches that data after it leaves the mainframe. Most security teams are not positioned for this.
According to NetSPI's 2025 mainframe assessment, Chief Information Security Officer organizations frequently have limited visibility into mainframe security posture because of long-standing organizational silos.
Cost overruns come from underestimating the manual effort to refactor or rewrite millions of lines of custom code. Mainframe licensing compounds the pressure, with software charges tied to millions of instructions per second (MIPS), which climb year over year, turning every delay into a larger bill. The economics push teams toward speed, which is precisely when data protection gets deferred.
The talent squeeze is structural. Legacy programmers do not know cloud-native architecture, modern developers cannot read the original mainframe languages, and the people who understand both are scarce and expensive. That gap makes agentless approaches that require no specialized mainframe coding far more attractive than tools that demand it.
Every mainframe modernization strategy falls into one of four approaches, and each carries a different risk profile. Rehosting moves code to cloud infrastructure unchanged; replatforming swaps the runtime while preserving code; refactoring decomposes the monolith into services; and retiring decommissions workloads no one uses.
The right mix is decided workload by workload, but the data-exposure risk is highest whenever data straddles two environments at once, which describes most hybrid migrations.
That hybrid reality is now the default rather than the exception as the forcing function today is no longer cost but rather, artificial-intelligence readiness, as boards push to make mainframe data accessible to analytics and AI pipelines, a shift documented in Gartner's mainframe analysis.
Feeding that data into modern systems multiplies the number of places where sensitive data comes to rest, which raises the protection bar while also raising the integration ambition.
A mainframe modernization that succeeds on every technical measure can still increase your data risk because the controls that protected data on z/OS, IBM's mainframe operating system, do not carry over into the cloud.
Once records are replicated to a cloud data lake, mainframe-native access controls become operationally irrelevant, and protection has to be bound to the data itself.
As PKWARE noted heading into 2026, there are no longer data-at-rest exceptions for the mainframe; the platform is expected to meet the same obligations as any cloud or software-as-a-service system, with new United States data-transfer and federal classification rules now directly applying to mainframe data.
The Digital Operational Resilience Act (DORA) and the Sarbanes-Oxley Act (SOX) add further pressure for regulated industries.
This is where pervasive encryption falls short; pervasive encryption protects data at rest, but the data is still live and accessible to any compromised privileged credentials, and it remains in regulatory scope. Data-centric protection takes a different path: it neutralizes the data element so that even if access controls fail, the data is useless to an attacker.
According to IBM's Cost of a Data Breach research, mainframe blind spots contribute materially to breach costs, which is the bill that arrives when protection is treated as a post-migration afterthought.
Deloitte's guidance on migration is blunt on the fix: organizations that integrate compliance and risk from the planning stage reduce post-migration incidents.
The corollary is that protection designed before the move is cheaper and safer than protection bolted on after it.
The mainframe modernization mitigation framework that competitors omit has three steps, and they run in order. Find the sensitive data, neutralize it with tokenization, and do both in-line without touching the mainframe code.
This is the practical answer to the deal-breaker question every team asks: how do you migrate without exposing the regulated data your business depends on?
You cannot protect what you have not found, so data discovery is the essential first step before any migration.
Discovery and classification are distinct: discovery finds where data lives, including the unknown and shadow information technology repositories that your configuration management database (CMDB) missed, while classification categorizes what that data is by sensitivity and regulation.
DataStealth's discovery engine points an agentless scanner at a segment and auto-discovers every database, file share, and connection across structured and unstructured sources.
It classifies beyond simple pattern matching, combining contextual analysis and named-entity recognition (NER) with multi-step validation such as Luhn checks for card numbers and Soundex for names, each finding carrying a tunable confidence score. There is no sampling, which matters when a missed field becomes a breached field.
In one production telecommunications environment, the DataStealth engine scanned 12 billion rows and 78 thousand tables to deliver a complete inventory of personal data for governance and remediation.
For a migration, that inventory is the map that tells you exactly which records that carry personally identifiable information (PII), primary account numbers (PAN), and protected health information (PHI) are about to move before a single record leaves the mainframe.
Once you know where the regulated data is, tokenization removes its value. Tokenization replaces a sensitive value with an irreversible token that bears no mathematical relationship to the original value, and the real value is isolated in a separate vault.
This is the line that separates it from encryption, which is reversible with a key and keeps the data in compliance scope; vaulted tokenization severs that mathematical link entirely, so a breached database yields only worthless tokens.
A tokenized card number can be generated to pass a Luhn algorithm check, so mainframe and downstream applications accept it, and business processes continue without disruption, which is critical when many systems run in parallel during cutover. The token appears to be real data to every application that handles it, yet it is useless to anyone who steals it.
For the hybrid state of a migration, re-tokenization holds the line between environments. Data can be detokenized from the mainframe vault and immediately re-tokenized into a separate vault tied to the target system, so tokens from one environment are useless in another, with dynamic data masking governing legacy 3270 terminal sessions (TN3270) by identity.
The compliance payoff is direct: removing live card numbers from the environment reduces PCI DSS audit scope, turning a migration exposure into a scope-reduction win. Tokenization is also quantum-resistant, where standard encryption is not.
The third pillar is architectural, and it removes the operational danger that the other risk categories warn about.
DataStealth operates in the network traffic flow using native mainframe and standard database protocols, intercepting data in-flight and protecting it before it reaches the mainframe in a sensitive state or before it leaves for the cloud. The protection sits between systems, not inside them.
Because the approach is agentless, you make zero changes to COBOL or mainframe code, install no agents on z/OS, consume no additional MIPS, and avoid destabilizing the brittle legacy applications you are trying to preserve.
This is a dissimilar, architecturally separate control, which is the core principle of defence-in-depth: it neutralizes data independent of the mainframe's own controls, moving protection ahead of any breach rather than reacting to one.
Protection then follows the data wherever modernization takes it. Because the data is tokenized before it leaves the mainframe, it remains protected across the hybrid estate regardless of which cloud or analytics platform consumes it, making it a practical enabler of a Zero Trust model for data.
One large financial-services firm used exactly this approach to secure its legacy mainframe data and bridge to modern analytics without rewriting COBOL or altering database schemas.
None of this argues against mainframe modernization.
The cost of standing still rises every year as MIPS pricing climbs, and the inability to feed mainframe data to AI is now a competitive liability, not a technical footnote. The right move is to pursue mainframe modernization in a way that does not trade one risk for another.
The evidence favors incremental, discovery-first execution.
According to McKinsey, companies that modernize incrementally recover their investment far faster than those attempting full rewrites. Pair that incremental discipline with data-centric protection, and the migration delivers the agility and AI-readiness leadership wants without expanding the breach surface.
Mainframe modernization risks are real, but the most expensive one is also the most preventable. DataStealth helps you de-risk the migration at the data layer:
DataStealth is a data security platform (DSP) that allows organizations to discover, classify, and protect their most sensitive data and documents, ensuring that sensitive data and documents are secure and meet applicable regulatory requirements.
