Imagine a hotel that never really cleans its rooms between guests. Fresh sheets, new towels, trash taken out, sure. But whatever the last person left under the mattress or in the back of the closet just stays there. Regular guests start to notice that if they check under the bed, they often find something. Maybe it’s cash, maybe it’s snacks, maybe it’s a forgotten charger. The hotel never promised this, it just turned into a quiet tradition people got used to.

One day the hotel moves into a new building with strict cleaning rules. Every room is scrubbed from top to bottom. Nothing is left behind. Management is happy, the place is spotless. Then the regulars arrive, lift the mattress, and find nothing. From the hotel’s side, they improved the experience. From the guests’ side, something that “always worked” suddenly stopped working for no obvious reason.

That’s very close to what happens when old COBOL systems are moved to modern platforms without thinking about all the hidden habits those systems picked up over decades.

How legacy COBOL quietly “remembers”

In a COBOL/mainframe world, programs almost never operate in isolation:

• Many programs share the same data layouts, like everyone using the same form in an office. Change one field and you silently affect dozens of workflows.
• Online programs often pass data through a shared “scratchpad” in memory. Program A writes something, program B later reads it, assuming it will be there - like guests sharing a notepad in the same hotel room.
• Nightly batch jobs run in a specific order, and business rules quietly attach themselves to that sequence: “this only works if that finished first.”
• The mainframe itself provides strict timing and data guarantees that developers grow to rely on without writing them down.

Individually, none of these look dramatic. Together, they create a web of unwritten agreements about how the system behaves.

What breaks when you move

When you migrate to modern, cleaner architectures, you usually:

• Give each request a “fresh room” - no leftovers in memory.
• Enforce cleaner, more explicit data models.
• Change the order, timing, or location of jobs (some on mainframe, some in the cloud).
• Lose some of the strict, built-in guarantees the mainframe provided.

Suddenly:

• A program that used to rely on a value left by a previous step finds nothing - the mattress is clean, the cash is gone.
• A “minor” change to a shared data layout quietly alters calculations in a different part of the business.
• A report that always ran after certain jobs now runs too early, and its numbers no longer match what people expect.

From the business view, the migration “broke” trusted behavior. In reality, it exposed hidden dependencies that were there all along.

Migration reveals hidden dependencies in system architectures.

The real lesson for non-technical stakeholders

COBOL migration is not just translating code from an old language to a new one. It’s closer to moving from an old hotel full of habits and shortcuts into a new building where every rule has to be written down.

To do it safely, you have to treat shared data and state as business contracts, not technical details, spend time discovering how the system actually behaves today rather than how it was supposed to behave on paper, and expect that some of what customers and staff rely on are “unwritten rules” baked into the old environment. Otherwise, you don’t just upgrade the hotel - you accidentally take away the very quirks and shortcuts that made it feel like home, and you only find out after your best guests start complaining.