Nobody decides to fall three releases behind. It happens one entirely reasonable postponement at a time.
The upgrade window collides with a project go-live. Then with year-end change freeze. Then the person who knew the customisations leaves. Each deferral is defensible in isolation. The aggregate is an instance that cannot be upgraded without a project, which guarantees the next deferral too.
The compounding you cannot see
Deferring an upgrade feels like holding a position. It is not. Two things get worse while you wait.
The remediation surface grows. Every release changes something under your customisations. Skip one and you carry that delta. Skip three and you are not testing one set of changes, you are testing the interaction of three — and interactions are where the expensive surprises live.
The knowledge decays. The people who built the customisations move on. Six months after go-live someone can tell you why that Business Rule exists. Three years later, nobody can, so it cannot safely be removed — only carefully tested around, forever.
This is why the effort curve is not linear. The organisation that upgrades twice a year finds it routine. The one that upgrades every three years finds it a project with a budget code, which makes it competitive with other projects, which is how it loses again.
The real reason it gets deferred
Ask why and you will hear "no capacity". That is usually the symptom.
The actual blocker is nearly always unknown regression risk. Nobody can say with confidence what will break, so nobody can size the work, so it cannot be planned — only feared. An unsized risk always loses to a sized deliverable when capacity is allocated.
Which means the problem to solve is not capacity. It is confidence.
How to break the cycle
Find out how bad it actually is. Run the upgrade on a clone and read the skipped-updates list. This is uncomfortable and almost always better than feared. Most organisations discover a large fraction of their conflicts sit in areas nobody uses any more. You cannot plan against a fear; you can plan against a list.
Delete before you test. The cheapest customisation to upgrade is one you remove first. Before testing every conflict, ask which of them anyone still needs. Retired processes, abandoned integrations, a UI policy for a field that no longer exists — each deletion removes work from every future upgrade, not just this one.
Automate the regression baseline. Manual regression testing is the reason upgrades need a project. Automated Test Framework suites covering your critical paths — incident create-to-close, the top ten catalog items, your major integrations — turn a three-week manual effort into an overnight run. This is the highest-leverage investment available, because it pays out at every future upgrade and makes the work sizeable, which makes it schedulable.
Book the window before you need it. Organisations that upgrade reliably treat it as a standing commitment with dates in the calendar at the start of the year, not a thing to fit in when quiet. There is never a quiet moment. Waiting for one is how three years pass.
Separate the upgrade from the adoption. Two distinct activities get conflated: moving to the new release safely, and adopting its new features. Bundling them makes the upgrade look like a project with business scope, and it acquires stakeholders, debate and delay. Upgrade first, on a technical basis, with adoption as a separate conversation afterwards.
What good looks like
An organisation on a healthy cadence is not doing anything heroic. It has:
- A known customisation footprint, each item explicable by someone still employed
- Automated regression coverage of critical paths
- Upgrade windows scheduled a year ahead
- A habit of removing what is unused before testing it
- Upgrades treated as maintenance, not as projects
None of this is difficult. All of it is much harder to start once you are three releases behind — which is the argument for starting now rather than after the next deferral.
If you are already behind
Do not attempt to close the whole gap at once. Get to the next release, not the newest one, with a deliberately reduced scope: no feature adoption, no parallel projects, remediation only. The goal of the first upgrade is not to be current. It is to prove the upgrade is survivable — because once an organisation has done one without incident, the fear that drove the deferrals loses its grip, and the second is markedly easier to schedule than the first.
Upgrade readiness — distance from the current release, the remediation likely required and how to de-risk it — is one of the eight areas in our Platform Health Check.