Somewhere inside a large bank, a team of engineers recently finished translating two million lines of COBOL into Java — a migration that took fourteen months, passed every test suite, and went live on schedule, only for the security team to discover within the first week that credit card numbers, Social Security numbers, and account balances were flowing unprotected through API endpoints, a Kafka pipeline, and an analytics data lake that the original mainframe architecture had never exposed.
The modernization succeeded, but the data protection did not, and this scenario plays out far more often than most enterprises would care to admit.
Mainframe modernization spending is accelerating, but the conversation remains overwhelmingly focused on code translation, cloud infrastructure, and cost reduction, while data security — the single factor that determines whether a modernization project creates risk or eliminates it — rarely gets the attention it warrants until something breaks.
The Perimeter Problem That Modernization Creates
Legacy mainframes were never designed to be secure in the modern sense; they were designed to be unreachable. IBM z/OS environments relied on physical isolation, RACF access controls, and the sheer obscurity of their architecture to protect sensitive data, and for decades, the data stayed inside the perimeter because there was nowhere else for it to go.
Modernization fundamentally changes this equation, because the moment an organization replatforms a COBOL application to the cloud or replicates DB2 tables into a data warehouse, sensitive data begins crossing trust boundaries that never existed before, and each new integration point — be it an API call, a data pipeline, or a downstream analytics platform — becomes an attack surface the original security model was never built to protect.
The challenge is compounded by the age of these systems — the COBOL code is tightly coupled to business logic that nobody fully documents, the developers who wrote it are retiring, and virtually every enterprise that runs a mainframe shares the same policy: do not install agents, do not modify production code, do not risk disrupting workloads that process mission-critical transactions.
Why Code Translation Alone Is Not Enough
AI-assisted code translation tools have accelerated the migration process — what once took years can now be accomplished in months — but translating COBOL to Java or Python does not translate the security controls that protected the data while it sat inside the mainframe. In a typical z/OS deployment, encryption is handled at the hardware level through dedicated cryptographic processors, access control is enforced through RACF or ACF2, and data never leaves without passing through tightly controlled batch processes.
When that same data moves to a cloud-native environment, however, the protection model changes entirely: the data is now distributed across multiple services, regions, and providers, and the compliance scope under PCI DSS, HIPAA, and GDPR expands to every system that touches the sensitive data after it leaves z/OS. Without a data protection strategy designed before migration begins, organizations will find that they have not modernized their security so much as they have migrated their risk.
Protecting Data Without Touching the Mainframe
The most practical approaches to securing data during and after modernization operate at the network layer rather than the application layer, and this distinction matters because modifying legacy COBOL applications is rarely viable and installing agents on production mainframes introduces unacceptable operational risk. Agentless data protection solutions intercept data as it flows between the mainframe and downstream systems — tokenizing, masking, or encrypting sensitive fields in real time without changes to mainframe code, database schemas, or existing workflows — and the best mainframe upgrade and modernization solutions now integrate this kind of inline security as a core component rather than an afterthought.
Tokenization, in particular, has emerged as the preferred method for enterprises operating in mainframe environments. Format-preserving tokens maintain the data structure that legacy validation checks expect — such as Luhn verification for credit card numbers — while eliminating the mathematical relationship between the token and the original value, meaning tokens can flow through cloud pipelines, analytics platforms, and third-party integrations without exposing sensitive data or breaking the downstream systems that depend on consistent formats.
What Enterprises Should Evaluate Before Migrating
Organizations planning mainframe modernization programmes should evaluate their data security posture before the first workload moves — specifically, where sensitive data resides across mainframe databases and application data stores, which migration paths will expose that data to new environments, and how protection will persist once the data reaches the cloud. The enterprises that get modernization right treat data security as a design constraint from day one, not as a compliance checkbox applied retroactively, while the ones that get it wrong tend to discover — often too late — that they have built a faster, cheaper, and altogether more vulnerable version of what they already had.
