Mastering a programming language is one undertaking; collaborating with others to build a product with code is another thing entirely. And sometimes, the language in which you chose to build your product just doesn’t cut the mustard. It can be daunting to leave behind the familiar—especially if that means migrating your entire product over to a different language. So how do you know when it’s the right time to do it, and what does it entail?
This process, called language migration, is—unsurprisingly—difficult, and it isn’t a uniform practice. Migrating could mean starting new parts of the project in a different language and bridging one codebase to another. But it could also mean replicating your project’s entire code stack in a new language, a blank slate. It sounds onerous—but in certain situations, such a drastic course of action can pay serious dividends.
So, when is the right time to migrate? Rewriting your codebase in a new language could conceivably help if you want to avoid dealing with technical debt your project has accumulated. Or perhaps another language has more tools or a more supportive and involved community that would better serve your project. To make a truly informed decision, you’ll need to think about your product holistically.
“It’s the frameworks and the development environments that have some features that people really want; that, in my experience, is the main driver for switching from one language to another,” said Cristina Lopes, professor at the University of California, Irvine’s Donald Bren School of Information and Computer Sciences.
But companies, especially startups, sometimes choose to migrate to a different language for other, perhaps less advisable reasons. Ben Schippers, co-founder and partner at the Brooklyn-based web and mobile app development firm HappyFunCorp, has seen companies large and small choose to migrate. At times, the goal is to shift to a language that’s become popular in order to attract workers who want to use something flashy and new. There can be some value in that, Schippers said, but he’s wary of switching to hyped-up languages when the largest motivator is simply the charm of a new language that seems “cool” or interesting. (Schippers noted that in his experience, this rationale tends to be more prevalent among startups.)
Given the ever-evolving landscape of programming languages, it’s important for programmers to keep abreast of trends and tinker with the new stuff on the block—and for leadership to keep an open mind. But learning a new language is no small feat, and migrating a product or project from one language to another can be a massive undertaking that entails a lot of risk. What makes the challenges of the transition worth it?
Migrating for fun and features
If a company is willing to migrate to a new language, they’re naturally looking to gain something from the transition. Often the motivation is not simply to transition to a language that seems more suited to the project. For many, there’s added incentive to switch to a new language in order to benefit from the tools that people have built in it, UC Irvine’s Lopes said.
“People don’t go to the extra effort of switching [their] whole software to a new language just because of the sheer properties of the language itself. I think it’s more because there are new libraries of frameworks that have been developed [in the language],” Lopes said. “It’s those new functionalities that people really want.”
Sometimes, companies are motivated to migrate to wipe away technical debt; it can be increasingly expensive over time for companies to maintain a bloated or rickety codebase. And sometimes they have no choice but to migrate to a new language. Many startups code preliminary products that are more proof-of-concept than substantial baseline, and they iterate them into shape. The first effort mocks up what the final product will look like, but is often programmed in whatever language the founders or their first developers are familiar with. In the early stages, maintainability and interoperability are far less important than swiftly putting together something that works. Once funded, the startup sets out to build a real version, and to re-implement in a language that better suits the product. To do that, they’ll start hiring.
When companies expand their workforce to build or improve their product, the new programmers bring their influences and biases with them. Some will lobby to build in one language over another; in smaller companies, incoming developers may have a large impact on these decisions, especially at the outset. Schippers noted that it’s common for startups to take as much as two years to settle on a language for good. It’s certainly easier to explore when the codebase is small, but it’s a big time expenditure, nevertheless. Sometimes companies make the switch because there’s allure in starting anew. It lets them tell a story, make a clean break from “all that crap that [was] a mess and terrible before,” said HappyFunCorp cofounder Will Schenk. By doing away with the old, companies can reimagine their product and tout their transformation: “a new, utopian world where things are better, [where] this new language is going to be more productive, [with] fewer bugs.”
For some, a real motivator might be the coding community a company can tap into by adopting a new language, Schenk said. This strategy can work: Companies can attract developers by working in the hot new language, signaling that they’re cool or forward-looking or otherwise hold similar values. Even within companies running projects in multiple languages, prospective employees may gravitate toward the newer, sexier one (or not!).
Language migration: The process
If you want to migrate your codebase to another language, you can do it yourself. Or you can pay a shop like HappyFunCorp to do it for you. The cost varies according to the codebase size and other factors, Schippers said: A five-person startup with a starter-size codebase could cost between $150,000 and $200,000, while the codebase for a somewhat larger company—maybe grown to 25 or 30 employees—could cost double that. (Larger or more established companies will likely have enough dedicated engineers to perform migrations themselves.) Some balk at the cost, but around 30 percent of inquiring companies do end up rebuilding their system, he said, because they know, long term, and among other things, they’re going to be able to keep attracting talent through the system’s lifetime.
If a company is switching between two compatible languages—those that operate over the same virtual machine—the migration can be gradual, UC Irvine’s Lopes said. Switching from Java to Scala, for example, might be an option for some, because the languages are compatible at the bytecode level, and making something new that’s compatible with an existing stack is easier. The same logic would theoretically apply to migrating between .NET languages like C# and F#.
Transitioning to a language outside the family is a different beast entirely, and may require rewriting the entire stack in bulk. Fortunately, modern languages often have compatibility features: Java, for example, can integrate components written in C through the native Java interface, Lopes noted.
The scope of the migration matters, too. For a big company, migrating a large codebase can be a huge undertaking, and the effort alone might be justification enough to scrap the idea, despite the potential benefits. Cost and time lost in the transition are significant obstacles—and so is retraining the workforce. If engineers aren’t already proficient in the new language, they may face a steep learning curve as they get up to speed. It can help to incrementally switch components to the new language while still using the old, Lopes noted. The alternative—rewriting the codebase entirely and flipping a switch from one implementation to another—is the more error-prone and precarious path.
“That’s really costly and risky. Some companies did it; I remember in the ‘90s when there was a push for Java—when Java was the language of choice of enterprise applications—a lot of the older enterprise applications were written in old languages like COBOL and FORTRAN, some C and stuff like that, and … they just completely re-implemented [core pieces of software] in the new language [all at once],” Lopes said.
HappyFunCorp’s Schenk agreed that in the vast majority of situations, incrementally migrating is a better way to go. But when the scope of the project is more hassle than, perhaps, it’s worth, there’s always the alternative: Skip the migration, build another product, and “just stick it to the side of whatever already existed,” Schenk said.
The recap: Was migrating worth it?
When companies do successfully migrate to a new language, it’s not always immediately clear whether the decision worked in their favor. “It’s rare that you look back at this five-year journey and say, ‘Wow, that was the right choice.’ Everyone’s always like, ‘We thought it was going to be a year [to transition], but it was more like two years,’” Schenk said.
It can take even longer than that to properly reflect on the total cost—and impact—of a migration. It could take two years, or three years, or even six, to see the impact, because of complications that arose along the way. Schenk compared the process to buying a car and reckoning with the costs that accrue once you’ve driven it for a decade. When things start to break, are they harder to fix, or do things break more often? While you’re initially focused on the upfront cost of the car, it’s the operational and maintenance costs down the road that may have a greater impact on whether the expense was ultimately worth it.
But companies shouldn’t scrimp on keeping up their system lest they undercut its effectiveness and longevity. Years after you’ve migrated, you may have a new problem: The people who designed and built your system could be long gone, leaving new hires to keep the setup alive. Without the right investment, it might end up neglected—and the current team will have to consider whether to learn how to repair the legacy code and restore functionality, or try a new setup written in a new language. “And that’s how you talk yourself into [another] language rewrite,” Schenk said.
Greg Shackles, principal engineer at Olo, a platform for mobile and online food ordering systems for restaurants, agreed that companies should be wary of migrating. As a Microsoft shop, Olo’s backend works primarily in C#, but mixes in F# when necessary. After 13 years in business, the company has needed to update its legacy code from time to time, and when they can, they choose to inject code from more modern languages instead of completely rewriting. Olo has pulled off two “from-the-ground-up rewrites” that paid off in retrospect; in general, though, the consensus is that rewrites can take a long time, and can open you up to new issues that the old code had solved long ago, Shackles said.
“Depending on how complex the software is, it could take you a year or two before you rewrite exactly what you have now,” he said. “But you might introduce new problems along the way, so you need to really weigh that in with what you’re doing.”
It’s important to stay in tune with the industry, and Shackles said he tinkers with new languages and frameworks to discern what might be useful at Olo. “You’ll hear a lot of people talk about languages like Rust or Go for good low-level performance. [But] now you’re starting to see more managed worlds of the Microsoft stack, and the CLR stack, reaching similar performance levels on the languages that you’re already using if you’re on those platforms,” he said. Because he’s seen the features and functionality in Microsoft’s programming family start catching up to those in newer languages over the last few years, he’s had little reason to recommend Olo perform further migrations.
For at least one of the two full rewrites Shackles and his team performed at Olo, they knew that they’d made the right call even as they were building the new project—the old language had held them back that much. “It was pretty easy to see as we were starting to build out the platform that it was already paying dividends in terms of productivity gains and stability and flexibility,” Shackles said. A feature he’d written six months earlier took him just a day or two to rewrite.
Their other rewrite was for Olo’s web platform, which had a legacy mobile website that had been around for the better part of a decade. This wasn’t a transition to a whole new language; instead, Shackles and his team built an entirely new product using a modern JavaScript framework on top of their existing system. “As a business, we knew that it was worth investing in and [that it] definitely was the right decision to make, but replicating a decade of features and platform flexibility and all sorts of stuff like that, especially in a white-label way, just took a really long time,” Shackles said. His experience underscores that sometimes the time cost of a migration is simply inevitable, even when the expense is well worth it.
Tomorrow’s trends
There’s certainly a relationship between language popularity, adoption, and project/product migration. But it also has to do with industry trends. When there was a push for big data, people harnessed Hadoop and wrote Java programs on top of it, Lopes noted. Eventually, better frameworks were developed elsewhere, and people moved to SPARK, which meant moving to Scala. In essence, the demand for processing big data brought new frameworks to the fore, and those, in turn, popularized the languages in which they were written. Today, the industry is buzzing about machine learning and AI, and a lot of the more powerful frameworks for those are written in Python—ergo, that’s where the trend has led us today.
While there isn’t much data on the frequency of migration nor which languages companies tend to switch to or from, there are a pair of notable (but informal) studies done online. They both track back to the turn of the millennium, gathering data on over 15 years of projects in various languages to reflect the changes in the programming language landscape during that time frame. But it would be wrong to infer that language migration has only really occurred since the era post-dotcom bubble.
“This is not new. Even in the ‘50s and ‘60s, people were moving to [the] new languages, just more slowly,” Lopes said. “There was migration for business processing for COBOL, then there was a big push for C in the ‘70s.”
With the spread of Java came the distinction between virtual machines and the language on top, which gave rise to the concept of a basic intermediate language with many programming languages on top. That makes it easier to migrate between them. If you’re straight-up rewriting code, it’s easier today than it has been historically because modern languages often require a smaller amount of code to be written, Schenk said. Teams don’t have to be as large, because so much functionality comes out of the box. He used the laborious method of processing credit card transactions 20 years ago as an example—a process that now “you can get down to one line of JavaScript.”
The language landscape has changed, Lopes noted, but the philosophy behind migration hasn’t changed much—and there’s still plenty of work to do before it gets easier. Some teams have successfully developed tools that migrate at scale, but these cases are still the exception, not the rule. “People are looking into issues of translating automatically from one language to another,” Lopes noted. “Of course, that’s still [mostly] wishful thinking. Progress is slow.”
Language migration remains something of an onerous process—if companies are considering it, they should weigh the costs and benefits carefully.
To migrate or not to migrate: These are the questions
Ultimately, migrating is a labor-intensive and costly ordeal, even if you’re just re-creating features from your old codebase in a different language with better tools. There are no universal criteria that spell out when a migration would be the best choice. A company’s mission, the particulars of their codebase, team skills, language landscapes, and market conditions all affect the equation.
But you can view the urge to migrate as an opportunity to reflect on your operations status. What crisis could be averted by migrating to a new language? What new business opportunities could you take advantage of? How would it change your company for the better? Migrating could fix these issues—but what alternatives could address them without exposing your company to the risk and expense? Perhaps investing in a microservice and bridging it to your existing codebase, for instance, would enable your team to build out a new feature without having to majorly adjust your existing code—or your team’s skills.
It is, in essence, a balancing act. Migrating to a new language could be exhilarating—both a challenge and an opportunity—but are you already using a language that is technically best for what you want to do? What are the current skill sets of your team, and what’s the cognitive overhead of learning a new language? Think about it from a DevOps perspective, Shackles suggested: What does it take to run your current system every day, and how would that change with your projected new system in a new language? What happens if something goes wrong? “A lot of the cost is external to the language itself. It’s all sort of side effects” he said.
Many companies will, at some point, consider whether a language migration is their best next step. But it’s far better to stick with an old, patched-up codebase in a less cool language if it means staying in business. Once you’re sure that the leap is worth it—that the tools or language community would better support your project, and that a freshly written codebase with less technical debt is worth the expense—migrating to a new language can open up a world of opportunities. Proceed with due diligence.