How to Know When It's Time to Upgrade Your Legacy Application

Debbie Madden
Jun 24, 2014

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 you 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 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 take the time to update your legacy code base.

It’s survived this long, what’s another few months, few years? Legacy software is like a tooth. It’s fine, until it gets a cavity, and then you have a window of time 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 if it’s time to update your legacy software:

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

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

There are 2 basic approaches: Rewrite or Update.


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, cause they get to write shiny new code from scratch. But, this is often not the right thing for the business.

To see if 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 it, 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 due to the current technology platform? Identify these things explicitly by getting them down on paper and ensuring 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, by 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.

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 as a relative measure to the amount of new functionality that needs to be added.

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

And third, if the legacy code isn’t web enabled and/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 if 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.

You May Also Like

These Stories on Technology

Subscribe by Email

No Comments Yet

Let us know what you think