Top 4 Lessons Learned — What To Expect with Legacy Code Migrations

At Stride, we take on a lot of “code rescue” missions. Meaning, we inherit many legacy code bases and implement various migration solutions with and for our clients.

Sometimes we go into a legacy code base and take the code from a place of failure to a place of success. Other times, we take a legacy code base from good to great. Other times, we migrate the entire system to a different tech stack for various reasons.

Each situation is unique. However most legacy migration and code rescue missions do have many things in common.

Interested in our top five lessons learned when it comes to legacy code migrations? Read on…

Lesson 1: There is a cost of transition

Whether you have 2 lines of code or 2,000,000, there is 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 downpayment, 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 some 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 developer working for 4 weeks, or 20 days, expect about 1–2 days to be ‘transition’ work. Activities that happen that would be considered transition work include:

• Looking at the code, coming up to speed with code base
• Setting up the new development environment for 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

Lesson 2: Problems will not go away overnight

Imagine you are a doctor in the Emergency Room. 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 3 other things are wrong. But, you can’t address them until you stabilize 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.

So it goes with code rescue. If you find a capable development team to address your legacy code rescue, you’ll form a trusted partnership that will guide you through this process.

Lesson 3: Assessing the quality of the existing code is a critical first step

It’s tempting to jump in and start coding, adding tests, fixing bugs. But, it’s not the best first step. Instead, taking the time to understand the code is paramount. Just like Lesson 1, this takes time. However, the ROI will pay dividends.

There are 2 levels of code assessment. The quick and dirty “red flag”, “yellow flag”, “green flag” method. This involves literally maybe an hour 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 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. Sometimes, the initial assessment is good enough. I find that code that’s really good or really bad is easy to assess quickly. 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.

Lesson 4: 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. I’d estimate that 7 out of 10 times, we go into a legacy code migration project and fix the ‘fire’, and then find a giant smouldering 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 you eye on the goal and take an intelligent approach and you’ll come out ahead.