Migration is the wrong word for what needs to happen right now. The word "migration" sounds like moving house: code out, code in. Same furniture, new address. That exact mindset is the problem. Anyone who translates legacy systems one-to-one into a new language is building tomorrow's dead end into the system they're sitting in today.
To stay competitive with your IT systems landscape around 2026, it's necessary to translate the code into an architecture that can productively integrate AI systems and can be further developed by AI systems in the future.
Classic migration projects optimize for one goal: functional equivalence. The old COBOL or SAS code gets translated one-to-one into a new language. Easy to verify with tests, project done. Except: functional equivalence is the lowest bar you could possibly set.
The weakness of this approach is that it misses the chance to question architectural decisions that were made twenty years ago under completely different conditions. Historically grown structures, unclear module boundaries, and hardcoded business logic that nobody fully understands anymore are just a few of the problems. All of that migrates unchanged into the new environment. The result: a modern system with outdated functionality.
For the use of AI agents, this is especially fatal. Agent-based systems need clear interfaces, traceable dependencies, and modules that can be understood and changed in isolation. A tool-use agent operating in a confusing monolith (one that was never designed for this purpose) fails because of the architecture it encounters.
Legacy code can be seen as a dataset for modernization. This is where the real opportunity lies — one that's often overlooked in modernization projects: decades of grown code contain business logic that's documented nowhere else. Every special rule, every workaround, every seemingly arbitrary condition was once a deliberate decision. The code is often the only remaining source of knowledge that would otherwise be lost within the company.
These very systems are therefore the most valuable starting point for an AI-capable architecture. Above all, the implicit knowledge hidden in the code must be made visible, structured, and brought into a form that agents and humans can work with productively and efficiently.
That fundamentally changes the sequence of a modernization project.
In our migration and modernization projects, we therefore ask ourselves the following questions:
What is our starting point?
Which dependencies actually exist, not just on paper?
Where are risks hiding that would remain invisible in a pure functional translation?
Without solid answers to these questions, every migration estimate is just reading tea leaves.
An architecture only becomes "AI-ready" once it fulfills three properties that classic migration goals usually ignore:
Modularity with clear responsibilities. Agents work most effectively within bounded, well-defined contexts. A system made of small, understandable building blocks can be further developed by AI tools — a tangled monolith cannot, no matter how powerful the model.
Traceable governance. When agents change, test, or generate code, decisions must be logged and reviewable. Governance logging is a basic prerequisite for being allowed to use agents productively at all — especially in regulated industries, where requirements like DORA or Basel IV demand traceability anyway.
Documented knowledge instead of implicit knowledge. An architecture that documents its business logic, its interfaces, and its decision logic alongside the code is easier for humans to maintain. But above all, it's the prerequisite for agents to be able to reliably interact with the system without losing context at every step.
These three points can't be bolted on afterward, or only with great difficulty. They have to be part of the target architecture before the first line of code is transformed.
The reason many companies shy away from modernization projects is uncertainty: how big is the codebase really, what dependencies exist, how high is the risk, how long will this actually take? As long as your own inventory remains largely unknown, every migration decision stays a gut feeling.
This is exactly where structured modernization comes in: automated code inventory as the starting point, data-driven risk and effort analysis instead of gut-feeling estimates, and a target architecture designed from the outset for the productive use of AI agents. That turns an incalculable mega-project into a manageable modernization program with clear milestones.
HMS supports companies exactly on this path — with Code2X, our platform for agent-based migration, to make modernization plannable from the first idea all the way to a productive target architecture.
For more on our approach, see our Code2X whitepaper.
