It’s a classic story. A company starts out with a clean software slate. The early years are based on guts and trial by fire. With luck, determination, and hard work, the company thrives. A few years in, things get more complicated. Maybe the team decides to invest in writing custom software; maybe they decide to buy off the shelf solutions. Either way, things are integrated, APIs are talking to each other. Things are happy.

Then it happens—you wake up one day and realize you’ve got yourself a legacy code base. Maybe you’ve been part of the company all along and just realized the software is outdated. Maybe you’ve known it’s outdated for many years, but it hasn’t been a top priority to update it. Maybe you’re coming in from the outside and inherited this glorious situation.

Regardless, it’s yours now, and it’s up to you to deal with it. You’ve got the business side breathing down your neck about new, client-facing features. These new and shiny features will impact your next product release, maybe your next round of funding. Why would you take the time to update your legacy code base? It’s survived this long; what’s another few months or years?

Legacy software is like a tooth. It’s fine until it gets a cavity, and then you have a window of time in which to fix the cavity. But if you miss this window, you’ve got to pull the whole tooth out, and that sucks.

So the question is, how do you know when it’s time to rewrite or update your legacy code base?

Use this checklist to determine whether it’s time to update your legacy software:

• Are you afraid to make changes to the software, for fear you’ll break the whole thing?
• Do you fear deploying new releases because there’s a decent chance you’ll have to revert the changes at 4 a.m.?
• Are new features impossible to add into the existing code base without breaking another area of code?
• Do you currently have broken features that aren’t being addressed, simply because fixing them is too complicated?
• Do you find that every time you fix one thing, you break two others?
• Do you believe that you’re not coding true enhancements, but instead you are constantly coding workarounds?

If reading this list is giving you the cold sweats, it’s time to take action.

There are two basic approaches: rewrite or update.

Updating legacy software

The rule of thumb is, first try to update. It’s often sufficient and more cost-effective than throwing your entire code base out and starting over. Always start by looking for opportunities to update instead of rewriting completely. Yes, we know that throwing the whole damn thing out and rebuilding is more fun for developers, because they get to write shiny new code from scratch. But this is often not the right thing for the business.

To see whether an update is going to fly, start by identifying the business goal. What is the business aiming to accomplish with the update or rewrite? Bring folks together, whiteboard the discussion, and align understanding and goals.

Next, figure out why the legacy software is holding you back. Is it too brittle to change things, or are there capabilities that aren’t possible because of the current technology platform? Identify these things explicitly by getting them down on paper and ensuring that the team agrees with them.

Then, see if you can creatively come up with strategies to solve these business needs by building on top of the legacy code base, doing so in such a way that anything new that’s built is clean and modern technology. This way, you can slowly get rid of the legacy code over time.

This being said, in some cases, a full rewrite is the better choice.

Rewriting legacy software

Three good arguments for rewriting a legacy code base are as follows:

1. The code base is smaller than the volume of changes you want to make.

The size of the effort is important here. Sometimes it’s better to start fresh and do a full rewrite if the existing legacy code base is small relative to the amount of new functionality that needs to be added.

2. The technology is too old.

If the legacy code base is built on technology that’s so outdated that there is virtually no support and no high-quality developers who can maintain it, this is another truly valid reason to rewrite.

3. The existing technology won’t scale

If the legacy code isn’t web enabled or can’t scale, this is another truly valid reason to completely rewrite.

At the end of the day, modernizing your legacy code base will yield dividends in morale, top line, bottom line, and more. It’s worth the effort up front to determine whether an update or a rewrite is the best approach.

Want to talk with Stride about updating your legacy code base? Contact us for a free consultation now.