I've migrated more enterprise systems than I care to count. Oracle to Oracle, AS400 to Oracle, monolith to distributed — every variety. And the pattern I keep seeing isn't that legacy systems are too old. It's that organizations routinely underestimate what the old system actually does, and routinely overestimate what the new one will.
What "Legacy" Usually Means in Practice
When an executive calls something a "legacy system," they typically mean one of three things:
- It runs on technology the current team doesn't know
- It was built by people who've since left
- It doesn't have a modern UI
None of these are actually arguments for replacement. They're arguments for documentation, knowledge transfer, and possibly a better frontend. Replacing the system to solve a knowledge gap is like rebuilding a house because you lost the keys.
The dangerous version of legacy isn't old technology — it's undocumented behavior. Fifteen years of business rules accumulated in stored procedures. Edge-case handling that exists because of a specific regulatory requirement from 2011 that nobody remembers. The calculation logic that "just works" and has passed every audit, that nobody alive fully understands.
When you migrate that system, you're not migrating technology. You're migrating behavior. And if you don't know what the behavior actually is, you will miss something. In financial services, what you miss surfaces in an audit, or a regulatory submission, or a fund reconciliation.
The Modernization Trap
The pattern I've seen repeated across organizations: a "modernization" initiative gets approved, a new platform gets selected, and the migration project begins. Eighteen months later, the new system is live. Two years later, people are working around the new system's limitations with — you guessed it — a growing layer of undocumented workarounds and patches.
The wheel turns. The "modern" system becomes the legacy system nobody understands. The cycle repeats.
This isn't an argument against ever migrating. It's an argument for migrating deliberately — with investment in understanding the current system's actual behavior before touching it, and with a clear-eyed view of what problem you're actually solving.
What Modernization Should Actually Look Like
When I approach a migration or modernization initiative, the first phase is always archaeology. What does this system actually do? Not what the documentation says it does — what does it actually do? That means reading the code, running the edge cases, talking to the people who've operated it longest.
This phase is never popular. It doesn't produce visible output. It's not in any vendor's statement of work. But it's the work that determines whether the migration succeeds or produces a new set of problems with better marketing.
The second thing I look for: is the new architecture better for the domain, or just more fashionable? Microservices are not always better than a well-structured monolith. Cloud-native is not always better than on-premise for regulated financial data. The right answer depends on the specific regulatory environment, the operational capability of the team, and the actual scale requirements — not on what was announced at the last conference.
The Talent Angle
From a hiring perspective, I specifically look for people who've survived a migration. Not led one from a management presentation — actually been in the weeds, discovered undocumented behavior mid-project, and figured out how to handle it. That experience is irreplaceable.
The engineers who've only built greenfield systems have a blind spot. They don't have the instinct to ask "what does this system do that nobody's written down?" before they touch anything.
Institutional knowledge embedded in production systems is one of the most undervalued assets an organization has. Treat every migration as an archaeology project first. The technology will eventually be replaced anyway — the knowledge of why it does what it does is what you can't afford to lose.