How to choose the target language for a migration

How to choose the target language for a migration? There are moments in the life of a software system—and in the life of those responsible for it—when you feel trapped.

Trapped by a language that once served you well but now feels like a cage. You have an important application, something your business depends on, but the technology it’s built on is making your life miserable. Every change feels like climbing a mountain and you find yourself thinking, “Why is this so hard?”

You don’t think about migrating just because things are slightly inconvenient. You consider migration when the pain becomes too much and you know something has to change.

So you wait longer than you should and then you start thinking: “What if we move to a different language?”

But this brings you to the first, most critical obstacle: which language? You know migration isn’t a small task. It will take time, effort, and resources. And the last thing you want is to jump out of the frying pan and into the fire.

Maybe you’re not the one who chose the current language. Maybe you inherited this situation. Maybe you’ve spent years patching things up, keeping everything running. But now it’s your decision—and if you pick the wrong target language, you will have to own that mistake.

Luckily, choosing wisely isn’t rocket science. There are a few key principles to guide you, principles that can help you make a choice you won’t regret.

In a previous article, we explored how to choose a target language specifically when migrating from RPG. Many of the same concerns apply here, but in this article, we’re going broader. We’ll explore how to pick the right language for any migration, from any outdated or problematic technology.

And if you are specifically dealing with RPG? Go check out that original article for in-depth advice.

Now, let’s see what really matters when you’re deciding where to go next.

Factor 1 – Why are you considering a migration?

To pick the language that will solve your problems, we first need to figure out what your problems are.

You might be facing one—or several—of these recurring issues:

1. Talent Is Drying Up

Maybe your system was built in a language that no developer under 40 or 50 even recognizes. Your developers are hard to find, harder to keep, and they’re heading for retirement faster than you can replace them.

This is the most common reason we see for migrations.

Even if you’re managing for now, you can feel the walls closing in. Fast-forward a few years, and it won’t just be a problem—it’ll be a crisis.

2. You’re Stuck on Outdated Hardware

Some languages are tied to specific hardware, especially older systems. You’re stuck running on proprietary machines, while the rest of the world has moved on to standard servers or the cloud.

You want freedom:

Freedom to scale.
Freedom to choose your vendors.
Freedom to stop paying a premium for ancient, specialized equipment that no longer provides advantages oer alternatives.

But your language is just not offering you that choice.

3. The Language Itself Is Dying

Sometimes, it’s not just about people or hardware—it’s about the ecosystem.

No updates.
No security patches.
No libraries.
No community.

Even if you can train new developers, you’d still be fighting a losing battle.

4. Performance Is Breaking You

Maybe your system worked great when you started. But now? You’ve grown. You’re a victim of your own success. More users, more data, more demand—and your current tech just can’t keep up.

What’s Driving You?

These are the most typical reasons for migrations. If you’re migrating for something else, I’d love to hear about it—you can find my contacts on the website.

But here’s why this matters: your reason for migrating shapes your decision.

If it’s about finding developers, cloud support, or getting away from a dying platform? The answer is usually simple: pick a popular, well-supported language and move on.
If it’s about performance, or something more specific? You’ll need to weigh other factors.

So start here: why are you migrating? That answer will be one of the most important inputs in choosing your next language.

Factor 2 – What Kind of Organization Are You?

Let’s not overthink this.

If you do not need your language of choice to be your competitive advantage, because software is just an enabler for your main activities, then just pick something safe, stable, and boring. You don’t need clever. You need solid.
Are you a tech-first company? Are you looking for a differentiator that could give you an edge? Do you see yourself in Beating the Averages? Then the right choice for you could be getting less mainstream language: it may have been Ruby a few years ago. Today could be Elixir, Rust, or Clojure.

Factor 3 – What Is the Domain of Your Application?

Some domains naturally gravitate towards specific languages. This means that you can find talent familiar with your domain if you pick one of these languages. Also, in that ecosystem, there will be libraries and know-how that serve your domain particularly well.

Finance, Banking, Insurance? → Java or C#
Why: Stability, performance, tons of enterprise-grade libraries, and strong typing help prevent critical mistakes.
Data Science, Machine Learning, Automation? → Python
Why: Huge ecosystem (Pandas, NumPy, TensorFlow), easy to write, fast for prototyping.

Enterprise Applications (ERP, CRM, HR Systems)? → Java, C#, or Python
Why: Mature ecosystems, cloud-ready, long-term support, proven scalability.
DevOps, Infrastructure, Tooling? → Go, Python, or Ruby
Why: Go is fast and great for CLI tools; Python and Ruby are scriptable and flexible.

Media Processing (Video, Audio, Image)? → C++, Rust, or Python (with C/C++ backends).

Why: Performance critical, often hardware-bound.

Telecommunications / Distributed Systems? → Erlang, Elixir, or Go

Why: Built for concurrency, fault tolerance, message passing.

Factor 4 – What Is the Expected Lifetime of the Application?

Ok, predicting the future is always a gamble.

But just because we can’t know for sure doesn’t mean we can’t use common sense to make reasonable decisions.

There’s a huge difference between building something you’ll use for 2 years and something you plan to keep alive for 20 years.

If it is something you expect to need for the short-Term (5 years or less), then you’ve got more flexibility, you can maybe even a bit opportunistic:

You might choose a language that’s quick to develop in.
One that has plenty of available developers right now, possibly at lower rates.
You can focus on short-term costs and speed, rather than worrying about what the tech world will look like in a decade.

Basically, for short-lived projects, you optimize for the now, not the distant future.

But if you expect to keep the application long-Term (10 or more years), then stability is non-negotiable.

Now you need to think about:

Will I still find developers for this language in 10 years?
Will the tools, libraries, and frameworks I’m using still be supported?
Will the language itself still be evolving, or at least maintained?

This is where it pays to play it safe.

Here’s a simple rule: don’t pick a language that isn’t already one of the top 5 most popular.

Why? Because popularity today doesn’t guarantee survival tomorrow—but it does give you odds in your favor.

Popular languages have huge communities.
They have momentum behind them—companies, developers, educators all invested in keeping them alive.
If a language is thriving now, it’s far more likely to have strong support and active development for years to come.

Languages like Java, Python, C#, JavaScript, and even Go have reached a critical mass. There’s infrastructure, training, and a market built around them. That doesn’t make them future-proof, but it makes them a sensible bet. Which is the best we can do: if you and me could predict the future we would not be in this line of business.

Factor 5 – How difficult is to migrate to that language

Some migrations are just harder than others, so if time and money to get your migration done are something to keep in mind, you need to consider this factor.

Not all target languages are created equal when it comes to migration difficulty.

The bigger the gap between your current language and your new language in terms of execution model, the harder it will be to migrate.

Procedural → Object-Oriented?

Tough, but doable. This is your RPG or COBOL to Java, Python, or C# kind of move. It takes some effort to rethink things, but there are established patterns to help.
Procedural → Functional?

That’s a whole different beast. Moving from something like RPG or COBOL to Elixir, Haskell, or Clojure? Now there is a mismatch making the translation much more challenging.

It’s not impossible, but it’s harder, riskier, and more expensive.

Factor 6 – What Skills Do You Have In-House?

Sometimes, you’re not starting from scratch. Sure, one application might be stuck in an old, painful language—but what about the rest of your system?

Do you have other modules or services written in something modern?
Do you have teams already working with Python, Java, or C# on other parts of your stack?
Have you built any internal tools, even small ones, that rely on newer tech?

If so, let’s leverage that.

If your team already runs other services in, say, Python, then moving the legacy system into Python means:

You’ve got people in-house who can help.
You’ve already solved deployment issues for that stack.
You might even have libraries, utilities, or processes built around it.

This is especially critical for small organizations, where you can’t afford to spread yourselves thin. You just don’t have the luxury of hiring teams for every language.

If you’ve already got something working in a modern language, lean into that.

For small teams, having too many languages is a recipe for: Higher costs, Slower development and Hiring nightmares.

Sometimes, unfortunately, you’re stuck: The only language your team knows is the one you want to leave behind. So, well, that means you can pick whatever language you want, because anyway you will have to retrain your team (or hire a new one).

So what?

Alright, we’ve gone through six different factors. You’ve seen arguments pulling you in one direction, and others pulling you the opposite way.

Factor	Key Considerations	Impact on Language Choice
1. Why Are You Migrating?	Talent scarcity, outdated hardware, dying ecosystem, poor performance.	Drives whether you need a popular, well-supported, or high-performance language.
2. Type of Organization	Are you tech-first or using software as a tool?	Tech-first may consider niche languages for advantage; others should pick safe, stable, mainstream options.
3. Domain of Application	Certain industries favor specific languages (e.g., Java in Finance, Python in Data Science).	Picking a language aligned with your domain offers better talent, tools, and community support.
4. Expected Lifetime of Application	Short-term (<5 years) or long-term (10+ years).	Short-term allows flexibility; long-term demands stable, popular, and future-proof languages.
5. Difficulty of Migration	Procedural to OOP is easier; Procedural to Functional is harder.	Choose a language closer to your current paradigm if time, cost, and risk are major concerns.
6. In-House Skills	Existing team experience, current technologies used elsewhere in the system.	Leveraging existing skills reduces training costs and simplifies deployment, especially for small organizations.

So what now? What decision should you actually take?

I’m not going to pretend I can give you some magical thumb rule that works for everyone. That would be arrogant—and frankly, misleading. The truth is, you need to weigh these factors for your specific situation. Only you know your team, your problems, your goals.

If you’ve read all this, reflected, and you’re still stuck, here’s my advice:

Pick one of the most popular languages.
Popular means safe. Popular means you’ll find developers. Popular means tools, libraries, support.
If in doubt, just go with Java.
It’s not sexy, but it’s reliable, scalable, and everywhere.

But if you are not yet convinced you can always hire a consultant. Sure, you should be ready to spend some time and money. And in the end they’ll probably say: “Go with Java.”

When asking around consider that every developer has a personal bias. I personally love static typing. If it were up to me, everything would be written in Kotlin but I know that’s not the best choice for every company, every team, or every project that’s why you didn’t hear me push it much in this article (it took some will to refrain from doing so).

Hopefully this article was useful to you. Maybe you already had a gut feeling when you started reading and this article helped you cross the line and make that decision.

If it helped—great. That was the point.

If not, and you’re still thinking about it, or want to tell me what I should’ve covered instead?

Feel free to reach out. My contact info is on the website.

You can share your thoughts—or, if you really hated this, just send me a friendly insult.

Thanks for reading. Now go make the right call for you.