Why rip-and-replace projects do more harm than good in legacy system replacement

We’ve all been there. Your business is growing, stakeholders are happy and everything’s going well … on the surface. But you know your core system is lagging behind. All that vital data is hidden somewhere behind an impenetrable object model. Your yesterday-was-too-late requirements are taking forever to implement. And the technical debt that’s been building up is only going in one direction.

You’re now seriously considering replacing the whole legacy system and starting from scratch. Sound familiar? You’re not on your own. Every CEO, CIO, CTO or CxO out there reaches this critical juncture many times in their careers. Now please don’t get me wrong. Sometimes replacing a legacy or mainframe system is the only viable option. But it doesn’t have to be that way. The thing is there’s a lot of confusion as to what a rip-and-replace project will deliver.

1. Legacy system replacement will involve less work.

Change doesn’t happen overnight. When you buy an off-the-shelf product, integrating it as part of your ecosystem is going to take months if not years. It’ll also cost you a lot of money. You’ll need to face a whole new set of business challenges and risks. And we haven’t even got to changing your entire application landscape. There are a couple of key questions you need to answer honestly before you take the plunge:

• Will the new system meet your business requirements? If so, that’s great. But the reality for most companies, whether you’re a start-up or industry leader, is you’ll have limited to zero competencies in operating your new system. Remember you’ll have to manage and delegate all of the new day-to-day processes the system offers. For well-established companies, this never works out well. The fact is your existing work culture – the way a company does business and interacts with its customers – will have to change radically. All because of one new system, with its unfamiliar workflows and the need for employee training, etc. You’re going to have to significantly tailor your business needs to fit the new system; not the other way around. Not only that, off-the-shelf products usually offer way more functionality than your business is actually going to need. So you’ll end up not using a lot of the package.
• How will it integrate with your existing way of doing business? You’ll definitely need the proper tooling in place, at the very least a functional ESB or REST APIs. If not, there’s no chance of integration. Another thing you need to be aware of is that when you ditch the new system, the interoperability you’ve grown to rely on will be broken. Do you have a proper replacement to bridge those gaps? If you’re unsure on any of the above, you need to go back to the drawing board.
• What effect will the move have on data migration? Data is the most valuable asset you have. When replacing a system, data has to be typically migrated to the new solution. If that doesn’t run smoothly, it’ll impact on data quality and, more importantly, the compatibility between the old and new models. The reality is they rarely match. As a result, you’ll need to conduct a comprehensive analysis just to be able to move the data from system A to system B. History shows no mercy. These projects usually fail.

2. Now our new system is in place, we’ll be able to use it straight away.

Wrong. Your new system is going to take months, maybe even years to start running seamlessly. Honestly, if it took you 18 months to get to that stage you’d be doing well. Can you wait till then? And remember the market will have shifted as well during that time. Will your “new” system be scalable for the next trending tools? And what about the next batch of security requirements from regulators, the next GDPR headache? To make things even harder, the transition between the old and new system needs to dovetail simultaneously. If it doesn’t, what disruption will that have on your user experience? Will you have trouble with customer retention? This is the level of complexity you’re going to face compared to the flexibility of a “switch-off/switch-on” strategy.

3. Now we’ve modernised, we don’t need to invest for a while.

Think again. You’re about to make a considerable investment in this new version. But how much have you already invested in the old system? Now let’s go one step further. Imagine investing the same amount of money allocated for the new version just on maintenance 3-5 years down the line. Because, make no mistake, that’s what will happen. The fact is modernisation is continuous and so are the costs. If you focus solely on bug fixing or priority requirements instead of regular upgrades, your system will inevitably degrade over time.

Unfortunately, off-the-shelf vendors can’t see into the future. But you can do your homework and find out if the solution will be able to integrate new features or implement future customisations? And if so, how fast and at what cost? The irony here is that these questions are all asked from the get-go with custom development.

So is it worth replacing your old system?

You’re probably reading this article because your legacy system is already in pretty bad shape. But here’s the thing, it probably still offers a lot of functionality. After all, it’s still doing a job – serving as your core system. Just think of all those features you’ve got accustomed to over the years. Imagine re-implementing those within a new system. Navigating features no one can specify yet or has any experience with. To get your teams up to speed, you’ll definitely need to upskill.

Fortunately, there is a way of retaining your legacy system while making it better. In other words, you can still save the day. To do that, you need to realise that modernisation never stops. A legacy systems takeover strategy rooted in sound engineering practices is a great place to start.