Modernization Instead of Migration

"Migration" is the wrong word for what needs to happen right now. The word "migration" sounds like moving: out with the old code, in with the new. Same furniture, new address. That mindset is exactly the problem. Anyone who translates legacy systems one-to-one into a new language will find themselves tomorrow in the same dead end they’re already in today.

To remain competitive with your IT system landscape by 2026, it’s necessary to translate the code into an architecture that can productively integrate AI systems and be further developed by AI systems in the future.

Traditional migration projects focus on a single goal: functional equivalence. The old COBOL or SAS code is converted one-to-one into a new language. This can be easily verified through testing—and the project is complete. However, functional equivalence is the lowest bar one can set.

The weakness of this approach is that it misses the opportunity to reevaluate architectural decisions made twenty years ago under completely different conditions. Structures that have evolved over time, unclear module boundaries, and hard-coded business logic that no one fully understands anymore are just a few of the problems.
All of this is carried over unchanged into the new environment. This creates a modern system with outdated functionality.

This is particularly disastrous for the use of AI agents. Agent-based systems require clear interfaces, traceable dependencies, and modules that can be understood and modified in isolation. A tool-use agent intended to operate within a convoluted monolith (which was never designed for this purpose) will fail due to the architecture it encounters.

Legacy code can be viewed as a data set for modernization. This is where the real opportunity lies—one that is often overlooked in modernization projects: code that has evolved over decades contains business logic that is not documented anywhere else. Every special rule, every workaround, every seemingly arbitrary condition was once a deliberate decision. The code is therefore often the only remaining source of knowledge that would otherwise be lost to the company.

It is precisely these systems that serve as the most valuable starting point for an AI-ready architecture. Above all, the implicit knowledge (which is hidden in the code) must be made visible, structured, and organized in a way that allows agents and humans to work productively and efficiently.

This 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?
• What dependencies actually exist—not just on paper?
• Where are the risks hidden that would remain invisible in a purely functional translation?

Without reliable answers to these questions, any migration estimate is nothing more than guesswork.

“AI-ready Architecture” means: thinking for agents, not just for compilers

An architecture is only “AI-ready” when it fulfills three characteristics that traditional migration goals usually ignore:

• Modularity with clear responsibilities. Agents work most effectively within limited, well-defined contexts. A system made up of small, understandable building blocks can be further developed by AI tools, whereas an intertwined monolith cannot—no matter how powerful the model is.
• Traceable governance. When agents modify, test, or generate code, decisions must be logged and verifiable. Governance logging is a fundamental prerequisite for being allowed to deploy agents productively in the first place—especially in regulated industries, where requirements such as DORA or Basel IV already mandate traceability.
• Documented Knowledge Instead of Implicit Knowledge. An architecture that documents its business logic, interfaces, and decision-making logic is easier for humans to maintain. Above all, however, it is also a prerequisite for agents to interact reliably with the system without losing context at every step.

These three points cannot be implemented retroactively—or only with great difficulty. They must be part of the target architecture before the first line of code is transformed.

Modernization can be planned if you start with transparency

The reason many companies shy away from modernization projects is uncertainty: How large is the codebase really? What dependencies exist? How high is the risk? How long will the whole process actually take? As long as a company’s own codebase remains largely unknown, every migration decision comes down to a gut feeling.

This is precisely where structured modernization comes in: automated code inventory as a starting point, data-driven risk and effort analysis instead of gut-feel estimates, and a target architecture designed from the outset for the productive use of AI agents. This transforms an unpredictable large-scale project into a manageable modernization program with clear milestones.

HMS guides companies precisely along this path. With Code2X, our platform for agent-based migration, we make modernization planable from the initial idea all the way to the production-ready target architecture.

For more information on our approach, see our Code2X white paper.

Download