My last post was about Pick Programming, which is definitely a legacy-type of skill. In IT, “Legacy” refers to old technology. Today, most legacy systems I stumble upon are old applications running on new(ish) servers. You’d be surprised how many old enterprise applications (Pick, COBOL, RPG) are still running mission-critical business processes.
It seems to be my lot in life to work with companies that have legacy systems in place. I’m not complaining – most legacy systems still feel comfortable to me (like an old, favorite blanket). But as IT leaders, eventually we need to answer the question “Should we replace this legacy system?”.
If the system in question is sitting in a corner dedicated to a single user, then replacing it is simply a matter of finding a suitable NEW application for that single user. However, most legacy systems I encounter are mission-critical systems that have been customized over many decades — often with tentacles that reach into every department (perhaps also business partners). And what’s the chance all of the integration points are documented? Slim to nil.
Honestly, if you’ve never plumbed the depths of legacy environments, it’s hard to appreciate the extent of their reach. The replacement question is always difficult. If it was easy, we wouldn’t need to have this conversation.
In the article When Companies Become Prisoners of Legacy Systems, Deloitte’s Adam Schneider says a legacy system should be considered for replacement in these circumstances:
- If the legacy technology is causing the company to lose ground in the marketplace (perhaps because the technology is not global, does not allow the company to serve customers effectively, or is unreliable);
- If the cost structure for the technology is way out of alignment; or
- If the company cannot find trained staff to maintain it.
Let’s look at these three circumstances in more detail.
Losing Ground in the Marketplace
In this category, the legacy technology is lacking some key functionality that negatively affects the company’s ability to compete. For example, the legacy system may be incompatible with future environments, it may not allow multiple currencies, it may not provide the level of security your organization requires, or it may be subject to frequent customer-facing failures.
One specific limitation I’ve seen multiple times is this…
Many legacy systems lack a service oriented architecture (SOA), which makes them ill-prepared for our API and app-happy world.
If your legacy system prevents your company from rolling out new solutions to address business challenges, then it may be time for replacement. Another option to this challenge is to build functionality to address your limitations. For example: build an API infrastructure within the legacy system (I’ve done this more times than I’d like to admit). This may be a viable option if your costs are reasonable and you have no legacy staffing problems.
Out-of-Whack Cost Structure
I once worked with a company that charged a customer $16,000 to customize an existing order import into a legacy system. The cost to create a new order import into Epicor ERP (non-legacy system) was only $3,000. Note that the tweak to the existing (legacy) code was over 5 times the cost of writing new code in a current (non-legacy) system. This is an example of costs that are way out of alignment.
If your project costs look like this, you should consider legacy system replacement.
Cannot Find Staff to Maintain System
As Pick, COBOL, and RPG programmers retire, we have a far smaller pool of skilled workers to keep the systems running and optimized. Additionally, many legacy programmers are not skilled in modern technology, such as IT infrastructure, networking, and modern web concepts. This makes it harder to incorporate legacy staff into large projects, where it’s typical to call 3rd-party APIs or incorporate legacy data into more modern web and mobile apps. Even when you are able to find a legacy programmer, your project management and support costs may rise.
Personally, the staffing issue has hit me VERY often. Schools no longer teach the legacy languages and young CompSci students want to develop web and mobile apps rather than perform legacy maintenance programming, so this problem continues to get worse.
What’s an IT leader to do? If you have a legacy system and suspect it should be replaced, you need to build a case for legacy system replacement.
- First, evaluate your environment against the three circumstances above. Understand your biggest risk areas and understand your costs.
- Gather preliminary pricing from 2-4 vendors — just as a preview of the estimated costs. Double the costs if implementation isn’t included. Then talk to your peers, CEO and/or CFO, present the rough numbers, and get their opinion of the project. If the company has NO desire to replace the legacy system at this time, then there is no reason to spend more time on it (at this time).
- Gather more facts so you can make a complete business case. Put numbers around your facts. For example, if you lose a piece of business because your systems were unable to perform a necessary function, estimate the lost business. Add any out-of-whack costs and recruitment efforts for staffing.
- When the time is right, you should be able to justify your decision with specific examples and estimated costs. When presented correctly, the rest of the company will agree and your project will get the support it needs to move forward. Legacy system replacement is hard work. You will need everyone in agreement for the best chance of success.
When the entire company agrees that this project is worthwhile, the REAL work begins. The last 2 posts in my “5 steps to IT excellence” series apply to portions of this process: Project Definition and Implementation.