Over the years, Stride has helped many tech teams with “code rescue” missions - migrating and modernizing legacy code bases. We’ve worked with companies to modernize legacy applications, migrate to the cloud, and sometimes just to improve the bones of the code. While each situation is unique, most legacy software migrations have a few things in common. 

Here are the four commonalities I’ve found from our many legacy modernization projects, from enterprise to SMB.

There is always a cost of transition

Whether you have 2 lines of code or 2,000,000, there is always a ‘cost of change’. Think of it like this, if you live in an apartment in NYC and decide to move, there’s a cost to that. Whether you are buying a place and the cost is the down payment, or renting a place and the cost is the broker fee, you are paying a cost to ‘change’ where you live. Sure, you might find a no-fee apartment, but even then, you have to pay a cost to move your stuff. 

Transitioning ownership of code from one team to another is a change that comes with a cost. In our experience, this cost equates to 10%-20% of the first month’s work. So, if you have 1 software developer working for 4 weeks, or 20 days, expect about 1–2 days to be ‘transition’ work. Activities that happen that would be considered software transition work include:

• Looking at the legacy code, coming up to speed with code base
• Setting up the new development environment for the application
• Setting up the application, get all the specs running
• Creating accounts and users for all accounts (ex: Git, Heroku, Stripe, etc)
• Team calls and discussion to align on priorities and create workflow

So, before embarking on your legacy code migration initiative, capture the cost of change and determine if the return is worth the investment. 

The biggest mistake I see teams make is migrating the entire code base when in reality only a portion of the code base required migration. 

Problems will not go away overnight

Imagine you are a doctor in the Emergency Room and a patient comes in. It’s an urgent situation and you have to both assess the damages and react at the same time. You have to react immediately. Your first move is to stabilize the heart because it’s core to everything else. You go in to stabilize the heart. As you’re doing this, alarms start beeping and you discover that three other things are wrong. But, you can’t address those alarms until you’ve stabilized the heart. 

Improving legacy code can sometimes feel like technical ER surgery. It’s important to understand that, even if you hire the best ER doc, while she’s stabilizing the heart, other alarms may ring and that’s ok. So long as the ER doc is qualified to know in which order to address problems. 

This is generally our experience with code rescue projects. If you find a capable software development team to address your legacy code rescue, you’ll form a trusted partnership that will guide you through this process.

Assessing the quality of the existing code is a critical first step

It’s tempting to jump in and start coding, adding tests and fixing bugs. The best first step you can take is to really understand the codebase. This will take time, however, it will be time well spent and the ROI will pay dividends. 

There are 2 methods to assess legacy code:

1. The quick “red flag”, “yellow flag”, “green flag” method. This involves a few hours of time, to get an overall gut feel for the overall code quality. We’re not writing code here and we’re not basing any final software migration decisions on it. Rather, it’s an initial first dive into the code so that we can find out what we are dealing with. Following the quick and dirty assessment, a more detailed assessment might make sense. And sometimes, the initial assessment is good enough. It’s very easy to quickly assess code that is really good, and it is equally easy to assess code that is really bad. Code that’s ‘so-so’ takes longer. Also, how much time you spend analyzing the existing code should depend on what you are trying to learn from it. Ask the team what goals they have and what their objectives are, so that you can determine how much time to spend digging into existing code.
2. The “spot check” method. This is a bigger investment yet sometimes needed. Identify key functionality that is critical to the future success of your business and review parts of the code. Here, you ideally want to make a list of high, medium and low priority areas of the code base to migrate.

Once you put out the initial fire, the ‘real problem’ often appears

This is true for many business issues, it’s not a lesson limited to code migration. I’d estimate that 7 out of 10 times, we go into a legacy migration project and fix the ‘fire’, and then find a giant smoldering issue underneath it. Be on the look out for these underlying issues and don’t be surprised when you encounter them. 

My friend Diana Larsen, an Agile thought leader and an authority figure on embracing change, once advised me to say “How fascinating!” when discovering such issues. 

Whether you are undertaking a minor or major legacy code migration, don’t despair. Keep your eye on the goal and create an intelligent migration services plan and you’ll come out ahead. If you are looking for legacy migration services or want to learn how this can benefit your business, contact Stride today.