What is version lock exactly? It’s when software is restricted to a specific version, limiting upgrades and exposing your business to security and compliance risks.
Version lock is the situation where a business cannot upgrade its software without a project, so it stops upgrading, and the gap between what it runs and what is current widens every year until the eventual catch up is a replacement rather than an upgrade.
It is not a theoretical risk. It is the ordinary end state of on premise enterprise software that has been customised, and a meaningful number of Australian businesses are living in it right now without describing it that way.
This article covers how version lock happens, what it actually costs, why cloud platforms mostly avoid it, and how to prevent it recurring in an environment where upgrades are automatic.
Nobody decides to stop upgrading. It happens through a sequence of individually reasonable decisions.
A business implements a system and customises it, because standard functionality did not quite fit a process that mattered.
A version arrives. Upgrading means testing every customisation, fixing what broke, and doing it in a window that does not disrupt operations. That is a project, so it gets scheduled for next quarter.
Next quarter is busy. The version after that arrives, and now the upgrade is two versions rather than one, which is more than twice the work because the changes compound.
Repeat this three or four times and the upgrade is no longer an upgrade. It is a reimplementation, priced accordingly, and the business is genuinely stuck.
The costs of version lock are real, ongoing, and mostly invisible on any budget line.
Security exposure is the most serious. Vendors stop issuing patches for old versions, which means known vulnerabilities remain open indefinitely and your exposure grows with every disclosed issue.
Compliance risk follows. Regulatory requirements change, and where the current version supports a new requirement and yours does not, the gap is filled by manual work or by a customisation that deepens the lock.
Capability stagnation is the largest cumulative cost. Every release contains functionality you are not getting, and after several years the gap between what you run and what is available is substantial.
And integration becomes harder, since newer applications are built against current versions and connecting to an old one requires increasingly awkward workarounds.
Beyond the direct effects, version lock produces second order costs that are harder to see and frequently larger.
Manual work accumulates around the gaps. Each thing the system cannot do gets a workaround, and each workaround is somebody's time every period, permanently.
Talent becomes harder to attract and retain. Capable people do not want to spend their careers on obsolete technology, and the ones who stay are the ones whose skills are increasingly specific to your environment.
Specialist support costs rise, since fewer people know the old version and those who do can charge accordingly.
And strategic options close. A business that cannot change its systems quickly cannot pursue an opportunity that requires a systems change, and that constraint never appears as a cost because the opportunity was never attempted.
Version lock is almost always caused by customisation rather than by the software itself, and understanding why matters for preventing it.
A standard system upgrades cleanly, because the vendor tested the upgrade path against standard functionality.
Every customisation is something the vendor did not test, which means it has to be tested by you, against every version, forever.
The cost of that testing scales with the number of customisations, and the probability that at least one breaks approaches certainty as the count rises.
Which means the decision that creates version lock is not the decision to skip an upgrade. It is the decision, made years earlier, to build forty customisations without a plan for maintaining them.
Understanding why businesses stay locked once they recognise the problem is as useful as understanding how they got there.
The cost of fixing it is concentrated and visible, while the cost of staying is diffuse and invisible, which means the comparison always looks unfavourable in any single budget cycle.
There is usually no trigger. Nothing breaks on a particular day, so the decision has no natural forcing point and gets deferred indefinitely.
The people who understand the exposure are frequently not the people who control the budget, and the argument does not translate well across that gap.
And there is a sunk cost effect, since the customisations represent real past investment and retiring them feels like an admission that the money was wasted, even where keeping them is plainly more expensive.
Software as a service platforms address version lock structurally rather than by being easier to upgrade.
Upgrades happen on the vendor's schedule and everybody moves together, which removes the option of deferring and therefore removes the accumulation.
NetSuite releases twice a year, and every customer is on a current version. There is no supported old version to stay on.
The customisation framework is designed with upgrades in mind, so configuration, workflow and properly built scripts are expected to survive, and the vendor tests the platform against that expectation.
And there is a release preview environment, which gives you the next version in advance specifically so that you can test your customisations before it arrives.
Automatic upgrades solve the accumulation problem and they do not remove your responsibility, which is a distinction many businesses miss.
Your customisations are still yours to maintain. If a script depends on undocumented behaviour that changes, it will break, and the release will happen regardless.
Your integrations are still yours to maintain, and the other side of an integration may itself be an old system with its own constraints.
And functionality still arrives that you are not using, which is a softer version of the same capability gap that version lock produces.
So the failure mode changes rather than disappearing. Instead of falling behind a version, businesses fall behind on what the current version can do.
Staying current on a cloud platform requires a modest recurring effort rather than a project, and it is the part most businesses skip.
Read the release notes for the areas you use, twice a year, and identify what changed and what is new.
Test your customisations and integrations in the release preview environment before the release arrives, rather than discovering a problem in production.
Decide deliberately whether to adopt relevant new functionality, since the value of being on a current version is only realised where you use what it contains.
And assign this to somebody as a defined responsibility. Where it is nobody's job, it does not happen, and the gap opens again in a different form.
The single most effective protection against any form of version lock is keeping the customisation count low and the register current.
Keep a record of everything built, what it does, why, who asked for it and what it depends on. Most businesses cannot produce this after two years, which is itself the problem.
Review it annually against two questions. Is this still needed, since business processes change and some customisations outlive their purpose. And has standard functionality caught up, since it frequently has.
Retire what fails either test, because removing a customisation is one of the few actions that reduces ongoing cost permanently.
And apply the order of preference on every new request. Configuration first, then workflow, then a natively built application, and only then code.
Integrations create a version dependency that is easy to overlook because it involves somebody else's software.
Where your platform upgrades and the system at the other end does not, the connection between them becomes the constraint.
That is a form of version lock even where your own platform is current, and it is increasingly common as businesses connect more applications.
The mitigations are to prefer documented interfaces over undocumented ones, to keep a register of every connection with a named owner, and to include the other side's upgrade posture in your evaluation when selecting an application.
And to periodically ask whether each integration is still necessary, since some exist to support a system the platform could now replace.
A short assessment tells you where you stand, and it is worth doing honestly rather than assuming.
What version of each significant system are you running, and how far behind current is it.
When did you last upgrade each one, and what did it involve.
How many customisations does each carry, and can anybody explain what they all do.
What would an upgrade cost today, and what would it cost in two years if nothing changes.
And which systems are still receiving security updates, since that is the question with the most immediate consequence.
Businesses that are genuinely stuck have a narrower set of options and it is worth being clear about them.
Upgrading through the accumulated versions is possible where the gap is small, and the cost rises sharply with each version skipped.
Replacing the system is frequently cheaper than a multi version upgrade once the gap is large, which is an uncomfortable conclusion and often the correct one.
Moving to a cloud platform addresses the recurrence as well as the current position, which is why many businesses in this situation move rather than upgrade.
Whichever route, the customisations are the decision point. A replacement is an opportunity to not rebuild the forty customisations, and businesses that rebuild them all have simply purchased their next version lock.
The difficulty with version lock is that it is a slowly accumulating cost with no single trigger, which makes it hard to fund fixing.
Quantify the manual work created by the capability gap, since that is countable and it is usually larger than people expect.
Name the security exposure specifically, including whether the version is still supported, because that is the argument a board understands fastest.
Model the cost of upgrading now against the cost in two years, since the trend is what makes the case rather than the current number.
And identify a strategic initiative the current system blocks, because the opportunity cost is the largest component and the one nobody has attributed.
Where the decision is to move rather than to upgrade, it is worth being realistic about what that means, because businesses in this position have usually not run a systems project for a long time.
The data is older and messier than it would be in a business that had upgraded regularly, which means the cleansing effort is larger and it is business work rather than partner work.
The processes have adapted around the old system's limitations over many years, and a substantial part of the project is deciding which of those adaptations were necessary and which can now be dropped.
The institutional knowledge is thin, since the people who configured the original system have frequently moved on, which makes discovery slower and more archaeological.
None of that makes the move a bad idea. It makes the timeline longer than a comparable project in a business with a current system, and knowing that in advance prevents the disappointment that comes from an estimate built on the wrong assumption.
Version lock is largely determined at selection, which is worth knowing while you still have the choice.
Ask how upgrades work, whether they are optional, and what happens to customisations.
Ask what the customisation framework is designed to survive, and what the vendor tests against.
Ask whether there is a preview environment and how far in advance it is available.
And evaluate the platform against where your business intends to be in five years rather than where it is now, since a platform that fits today and constrains you at scale produces the same trapped feeling by a different route.
Version lock is a maintenance problem that presents as a technology problem, and the discipline that prevents it is small, recurring and almost always skipped.
If you are on a cloud platform, the highest value habit is working the release cycle properly twice a year, which is a couple of days of effort and prevents the gap from opening.
If you are on an on premise system several versions behind, the honest assessment is worth doing now rather than when the vendor announces end of support, because the options narrow considerably at that point.
Our pieces on the hidden costs of legacy ERP and tackling legacy migration challenges cover the practical route out, and continuous software improvement covers staying current.
If you would like an assessment of your own exposure, get in touch.
