Your seasoned developers are retiring, and finding new developers willing (or able) to maintain decades‑old RPG or COBOL code is getting harder every year.

This leads many IT leaders to consider making a drastic change to modernize. Code migration or refactoring seem necessary.

But these are costly and potentially disruptive changes. Before committing, let’s explore your real options.

Migrate or refactor? The pros and cons

In many discussions, migration and refactoring are used interchangeably, but they are fundamentally different approaches:

• Code Migration: moving your applications to a new platform (which often requires moving to a new language or architecture).
• Refactoring: transforming and modernizing your existing code base while remaining on the same platform.

Code Migration is often the first thing IT leaders think of when they decide it’s time for a change. But it is a big move.

Pros and cons of migration:

✅ Eliminate dependence on legacy hardware
✅ May offer modern interfaces “out of the box”
❌ Very high risk and cost (new platform, new specialists, heavy testing)
❌ Loss of deep knowledge of your current system
❌ Big‑bang approach, often disruptive

Like any large project, code migration carries large risks and costs. One significant consideration is your team expertise. You will likely need to hire new specialists who are experts on the new platform you’ve chosen. Companies sometimes end up with a split IT team where your current staff understands your application deeply but is not yet skilled at the new platform, and your new specialists understand the new platform but do not yet have a deep understanding of your application nor your very specific business processes.

Refactoring is a lower-cost and lower-risk option that can be rolled out gradually. Since you stay on the same platform, your existing team can likely handle the refactoring themselves. But don’t worry: modern RPG and new IBM i tools will feel familiar to younger developers who have trained on Java and Python, which will help resolve hiring challenges even if you stay on IBM i.

Pros and cons of refactoring:

✅ Lower cost and risk because the platform stays stable
✅ Modern languages like Free‑Form RPG feel familiar to today’s younger developers, making hiring easier
✅ Can be done incrementally, aligned with DevOps practices, without disrupting business activity
✅ Prepares you for API integrations, modern UI, and advanced features like SQL databases
❌ Requires careful planning and expert guidance

Refactoring is often overlooked, but in many cases it’s the right choice. It allows you to modernize what already works rather than starting over.

As Luc Du Moulin, R2i expert, explains: “If what you’ve got brings you profit and lets you innovate, and all you need is to make sure your code can be read and maintained by younger generations, then you should refactor.”

Of course, the migrate vs refactor discussion is not black and white. In some situations it may be best to do both. Refactoring before you migrate can make code migrations faster and less risky.

Where is your technological debt?

The key to deciding how to modernize your code lies in understanding where your technical debt lives:

• If your debt is in the code (hard to maintain, old syntax, no reusable routines),
  
• If your debt is in the infrastructure (hardware is unsupported, platform is at end‑of‑life),
  
• If your debt is in the application itself (the business logic no longer meets your needs), you may need to rebuild from scratch or get a brand new one.

How to execute your code migration or refactoring project

Once you’ve identified your technical debt, map out your approach:

1. Assess your current system. Audit your code base, infrastructure, and applications to see where the debt lies.
2. Plan your roadmap. Decide which method you’ll use to modernize and when you’ll do it.
3. Leverage tools and automation. Modern refactoring tools can extract repetitive routines, integrate SQL, and support DevOps pipelines. IBM i offers many useful tools for refactoring and migration.
4. Test continuously. Non‑regression testing ensures changes don’t break existing functionality. Testing is especially important if you are doing a code migration.
5. Get expert help. These are high‑impact projects with significant risk. Hiring professionals who know IBM i deeply and have done this many times before—like the R2i team—can de‑risk the process and help you modernize confidently.

Your unique business, your unique choice

Choosing between migration, refactoring, or even a rebuild is one of the most important IT decisions you can make. Every business has unique systems, constraints, and goals, so there is no one‑size‑fits‑all answer.

Take the time to evaluate where your technical debt lies, consider the long‑term impact on your team and budget, and plan carefully. With the right guidance, you can reduce costs, optimize your IBM i systems, and set your business up for decades of innovation.