The most expensive IT illusion: keeping old software because it feels safe

Every renewal project in your IT landscape starts with a decision that weighs far more than the eventual code. The crucial question revolves around what remains standing of the existing software. Nobody starts with a blank canvas. There is an accounting package running, a calendar, an industry-specific system brimming with historical data and, inevitably, an application whose origin has long been forgotten. Whoever avoids the confrontation with that legacy takes a decision implicitly, and usually the wrong one.

The situation compares perfectly with buying an old building: you face the choice between renovating or demolishing. Just as with a building, there is rarely one uniform answer for your IT architecture. Certain walls carry the entire construction. Other walls are there only because nobody ever took the trouble to take them down. This inventory is the phase that produces the fewest lines of code, and at the same time determines the foundation for the years to come.

The myth of the status quo

Keeping existing systems sounds to many decision-makers like the safe route. Seemingly nothing changes, employees do not have to learn new processes and the earlier investment in the package appears safeguarded. Because of that comfort, this decision is invariably taken too lightly.

Keeping an outdated package is a far-reaching decision. Every system that stays requires new integrations with your modern platform. Such an integration is no temporary plug that you casually pull out again later. It demands intensive development, requires structural maintenance and cements the old package into your daily operation. What you decide to keep today still determines your operations five years from now, including all the new dependencies clicked onto it in the meantime. Keeping is a long-term investment, and therefore no postponement of a decision.

Load-bearing walls and indispensable foundations

Peripheral packages that carry an isolated process, such as your accounting, calendar management or email, are the undisputed load-bearing walls. They perform one specific task and they do it conclusively. Rebuilding such standardised systems introduces superfluous complexity. Those foundations are kept.

For the core packages, the software that facilitates the daily, unique workflow of your team, considerably stricter rules apply. Such a system survives the selection only when it passes three tests:

• Does the system support the desired way of working completely, without cumbersome workarounds beside it?
• Does the team demonstrably enjoy working with it, which translates directly into accurate and up-to-date data?
• Would you, with today's knowledge and a blank cheque, choose exactly this package again?

Three affirmative answers legitimise an expensive, complex integration. A single no means anchoring a crooked wall into your new foundation.

The fallacy of habit

In practice two specific kinds of software are exposed immediately, and both are a reason to rebuild.

First the cumbersome package that employees avoid. People create their own shadow processes, so the central data ages until nobody looks at it any more. Then there is the limited package that handles only a fraction of the workflow, so the remaining tasks quietly shift to uncontrolled Excel lists. In both scenarios you finance an integration to a system that no longer supports the actual work. You thereby automate exactly the frustrations and detours your new platform was supposed to eliminate.

The most heard excuse for keeping anyway is habit. Employees simply know the system. That is no argument. Being used to an inefficient detour never justifies cementing that problem in place. Moreover, rebuilding does not require a launch in one go: a system phased out deliberately can be replaced in manageable stages, while the rest of the operation keeps running silently.

Every modern platform demands the courage to demolish what does not carry. You are building the architecture in which your entire organisation must operate and perform in the years to come. Select the walls you leave standing solely as if you had to work between them yourself every day.