Inertia (Legacy Gravity)
Established systems keep doing what they're doing unless a force greater than their momentum acts on them.
To an executive
Established systems resist change because years of investment, habits and contracts hold them in place. Change needs sustained effort and sponsorship, not just an announcement.
To an engineer
Map what ties the old system in place, such as integrations, reports and people's skills. Reduce that mass first, then apply steady, deliberate effort to move it.
The idea
Newton's first law says an object stays at rest, or keeps moving in a straight line, unless a force acts on it. Organisations and their systems behave in a similar way. Every integration, report, trained person, contract and habit adds mass, and that mass keeps the system where it is.
Inertia is not irrational. It reflects years of investment, embedded knowledge and real risk. But it means change does not happen by announcement. It needs a deliberate, sustained force, and it is easier if the mass is reduced first.
Why it works
Mass is mostly outside the system. As Cartwright, Horn and Lewis note in their work on legacy displacement, technology is at most half of the legacy problem; organisation, ways of working and leadership matter as much. Replacing the software alone leaves the rest of the mass in place.
Momentum keeps growing while you plan. Each month a legacy system stays central, new integrations and reports are built on it. A replacement programme that does not stop this is chasing a moving target.
Small forces lose to large masses. Side-of-desk modernisation, funded a quarter at a time, is rarely enough to move a system that half the organisation depends on.
Where it applies
- Legacy replacement programmes, especially ones that have stalled before.
- Platform consolidation, where several systems must be retired into one.
- Stakeholder planning, to size the sponsorship and funding a change really needs.
- Strategy, when judging whether a modernisation ambition is realistic.
How to apply
- Measure the mass: count integrations, reports, users, data volumes, contracts and the skills tied to the system.
- Stop adding to it. Freeze new integrations onto the legacy system, or route them through a seam you control.
- Reduce it in slices, moving one capability or consumer at a time rather than aiming for a single cutover.
- Apply a sustained force: an executive sponsor, multi-year funding, a dedicated team and incentives that reward retiring the old system, not just building the new one.
Example scenario
Three attempts to retire a legacy CRM failed. Each programme built a new platform, but during each one, other teams added "just one more" integration to the old CRM, so the list of things to migrate kept growing. Each time, funding ran out before cutover.
The fourth attempt started differently. The CIO froze new integrations onto the old CRM and required them to go through an API layer the programme controlled. A dedicated team was funded for eighteen months, and consumers were moved across one at a time. The old system's mass shrank every month, and it was switched off before the funding ended.
Questions to ask
- What gives this system its momentum — integrations, data, skills, contracts or habits?
- Is our change effort, in funding, sponsorship and people, strong enough to overcome it?
- What can we do to reduce the mass first?
When not to use it
- Systems that are stable, cheap and fit for purpose, where inertia is simply the absence of a good reason to change.
- Small systems with few dependants, where a direct replacement is quicker than any mass-reduction strategy.
How it misleads you
It can make everything legacy look like a problem to be overcome. Inertia also means stability and proven value: the old system works, people know it and its failure modes are understood. Make sure the force you apply is aimed at something that should move, not just something that is old.
In the wild
Further reading
Last reviewed · Suggest an improvement