For many organizations, a legacy migration feels like stepping into the unknown.

They have been running the same language, the same hardware, and the same workflows for decades. Suddenly they are asked to move everything to a new platform. It is natural to wonder: What exactly will happen? What will the team experience? What will happen to the code that has been reliable for so many years?

At Strumenta we have guided many companies through their first migration. For them, it is a journey that feels part adventure, part surgery, and often both at once. In this article we share what really happens during a migration, month by month, so you can know what to expect, and this can make you a little bit less nervous.

Phase 1: Planning the Journey

Every successful migration starts with clarity.

You cannot plan a route without knowing where you are and where you want to go. The planning phase is about understanding both.

This is also what we formalize in our Migration Blueprint service, a structured plan that defines what will be migrated, how, and in what order. It is the moment when we align everyone, from developers to executives, around a shared understanding.

The planning phase has three concrete goals.

1. Understand the current system

What does the legacy system do? How is it organized? What are the hidden dependencies that make it difficult to change?

We analyze the codebase, document the architecture, and clarify the responsibilities of each component. And it is surprising what one uncovers in this phase! Teams rediscover forgotten rules, obscure CL scripts, and implicit behaviors that only a few veterans remembered.

2. Define the target environment

Some organizations already know their destination. They may have chosen Java and Spring or Python and Flask. Others only know they want to leave their current hardware (did anybody say IBM i?).

Together we evaluate options and define clear requirements for the new environment: language, framework, runtime, and deployment strategy. Typically this means identifying a target solution like Python with the Odoo framework, but also picking a Python version and a specific database to support.

3. Define the migration path

How do we get from point A to point B safely? Which modules go first? What are the biggest risks? How can we reduce downtime?

Here we design the roadmap, which will guide the second phase of the project.

At the end of this phase, the team has a shared and detailed plan. Everyone knows what will happen, in what order, and who is responsible for what.

That alignment is what keeps the following stages predictable.

Typical duration: two to four months. Longer if the system is complex or if decisions take time.

Phase 2: Migration

Once planning is complete, it is time for the core work: translating the existing system into a new language and platform.

This is where the bulk of the technical effort happens. While each project is different, most migrations involve different streams of work.

Main Language Translation

This is the heart of every migration. Here we focus on the language in which it is expressed the bulk of the system. It may be EGL, RPG, COBOL, SAS or something else.

We replace each program with equivalent code in the target language through an automated transpilation process. This ensures consistency, traceability, and faster delivery compared to manual rewrites.

The result is code that behaves exactly like the original but can be maintained with modern tools.

Translating other languages

We rarely have just one main language. Often it is supported by scripts, some SQL, or some batch files. We may have to deal with CL scripts, COBOL fragments, SQL queries, and even Query 400 definitions that still play a role in the business logic.

Each of these components must be translated or re-implemented to integrate with the new environment. Leaving any of them behind means leaving parts of the old system behind as well.

Runtime development

Legacy systems rely on idioms that do not exist in modern languages.

To bridge that gap we often build a runtime layer, a set of support libraries that reproduce the behavior of constructs or provide abstractions that make generated code cleaner and easier to maintain.

This layer becomes the connection between legacy semantics and modern architecture.

Database migration

If the migration involves moving from, let’s say, DB2 to another database, we generate:

• DDL scripts for the new schema
• Data migration scripts for transformation and transfer

Data migration is often underestimated. When it is done well it allows business data to continue living in a healthier environment.

During this phase the client’s direct involvement is usually limited. The heavy work is performed by specialized engineers, while periodic reviews and checkpoints ensure transparency.

Typical duration: six to twelve months.

If it takes longer, that usually points to problems in planning, changing requirements, or lack of experience.

Phase 3: Testing

A migration is not complete when the code compiles.

It is complete when the new system behaves exactly like the old one, producing the same results for the same inputs without breaking any business rules.

Testing validates that equivalence. We run both systems in parallel, compare results, and track every difference. In this phase precision matters more than speed.

Testing activities include:

• Automated comparisons between old and new outputs
• Behavioral testing to ensure that logic is preserved
• Performance benchmarking
• Manual acceptance tests carried out by the client’s team

Testing is where collaboration between the migration team and the client’s experts is essential.

No one knows the business logic better than the people who have maintained it for decades.

Typical duration: four to twelve months, depending on complexity and available testing resources.

Team Involvement Over Time

• Planning: High involvement from the client team. Developers, analysts, and IT leaders share domain knowledge.
• Migration: Most of the work is handled by the migration engineers, with occasional reviews by the client.
• Testing: High collaboration again. The client validates behavior and signs off results.

This rhythm keeps migrations sustainable. The client is not under pressure every week, only when their participation really matters.

How Long Does the Whole Process Take?

Every system is unique, but the overall timeline typically looks like this:

Phase	Duration	Client involvement
Planning	2 to 4 months	High
Migration	6 to 12 months	Moderate
Testing	4 to 12 months	High

So the total could go from 12 to 26 months.

A Predictable Journey

For most companies a migration is a once-in-a-lifetime event. It feels risky because it is unfamiliar. In reality, it is a methodical engineering process.

There is no magic, no leap of faith, only structured work, clear phases, and collaboration between people who understand both the legacy world and the modern one.

With careful preparation, solid tools, and open communication, the migration can be demanding but never chaotic.

At the end of it, you will not only have a new system. You will have a stronger and more adaptable foundation for the future.

And if you are interested in translating RPG code, and you want to learn more, take a look at our book Migrating RPG Code to Modern Languages!

Summary

Legacy migrations are structured into three predictable phases:

• Planning (2-4 months, high client involvement to define the scope)
• Migration (6-12 months, technical translation of code and database, moderate involvement)
• Testing (4-12 months, high collaboration for validation).

The entire methodical process typically takes 12 to 26 months, transforming an old system into a modern, maintainable foundation without chaos.