Legacy systems exist in almost every enterprise – and sometimes, an upgrade has more ROI than chasing after the “new shiny.”

In some cases, bringing legacy enterprise applications up to date makes more business sense than starting over in the cloud. An effective upgrade process makes all the difference.

Every organization I’ve worked in–be it public education or edge startup–has some part of the enterprise that falls into the “legacy” software category.

• An outdated customer management system hijacked from another founder’s last gig.
• An inherited web back-end that powers “everything,” but is a jumble of Perl, VB.net, and magic voodoo.
• A build tool or process that everyone’s afraid to touch cause it still “works.”
• {Whatever your case may be…}

With the drive away from managed hosting into shared, cloud environments, the C-level leadership, investors, and random water cooler conversations tend to focus on “when can we redesign?” rather than “when is our next iteration?”.

Redesigns are great. Greenfield development is a joy to almost every software developer.

However, when redesigning an existing piece of software, it’s important to consider not just the software, but the entire ecosystem:

1. Is all of the business logic and “magic” properly documented? (pro tip: if you still have “magic,” then no… it’s probably not)
2. What third-party dependencies exist on your software? e.g. Will the old mainframe over at the bank still understand your payroll transactions you change over?
3. Can you replicate and improve the user experience with the redesign and properly account for changes to training, documentation, and usability?
4. Can you document and replicate all connected systems and processes? e.g. Will your redesign affect Bob in the corner office that’s used to the daily emails that only he gets that was hard coded into the system 5 years ago?

And, most importantly: Will a redesign land you EXACTLY back where you are today–but just with a new/different technology stack and +{x} amount of days of development?

If your answer to the last question was “yes,” I urge you to consider the impact on your project and organization–both in development time and financial cost. Throwing away a piece of software, as trivial as it may be, is still throwing away a core asset of your organization.

But traditional ERP software is far from dead. In fact, many enterprises are making a solid business case for upgrading their ERP installations. In some instances, corporate leaders have found that their existing enterprise system actually meets the majority of their current requirements. They’ve likely poured millions of dollars into the applications and cannot justify reinvesting from scratch with a new system. Moreover, the organization may not be prepared to absorb the technology and process changes that switching to new software entails.

When laid out, the cost of a total redesign (unless there’s a systemic, crippling problem) rarely matches the more immediate ROI of an upgrade and overhaul to an existing system. It’s also hard to pitch leadership teams that rewriting a piece of software in a new programming language can improve the overall company standing. It is, however, easy to explain how those same development hours can go into improving user experience, performance, and feature sets for an existing platform.

This is in no means a call that migration to SaaS/IaaS options in the cloud are a waste–far from it.

It is a call to stop and consider the whole costs when faced with your next redevelop vs. upgrade software project.