Most software lock-in doesn’t start as a trap. It starts as a sensible decision. An organisation buys a platform to solve a real problem, it does the job, and over the next few years the business grows around it – integrations, customisations, reports, training, habits. Each of those is reasonable on its own. Added together, they quietly turn “we could move if we needed to” into “we couldn’t move without a project none of us wants to fund”. By then, the recurring licence, the per-seat subscription, or the dependency on one vendor’s roadmap isn’t really a line item any more. It’s a liability that grows every year you stay.
That question – how hard is it to leave – has become more pressing lately, not less. AI tooling and subscription software are being repriced across the market, and buyers are discovering that a bill they thought was fixed can move sharply, and that switching away is harder than the sales conversation suggested. It’s a good moment to ask a question that applies well beyond AI: if you needed to walk away from a system, how much would it actually cost you?
At Biz Hub, we’ve taken a clear position on this for a long time. Exit is one of the principles the Skyve platform is built on – the platform we use to deliver our clients’ solutions – and the manifesto puts it plainly: if you’re not free to leave, you’re probably being taken for a ride. Designing for exit isn’t something we bolt on at the end of a project. It shapes how we build from day one.
In practice, it means a few concrete things. You own the solution we build for you, with a clear line between your intellectual property and the platform underneath it. Skyve is open-source, so there are no per-user licence fees stacking up as your team grows. The technology under the hood is standard – Java, SQL Server, and the like – so another provider, or your own team, can pick it up without learning a closed, proprietary system. Data export is built in, not sold as an add-on. And you can host the solution in our private cloud or on your own infrastructure, whichever suits you best. None of that stops you from working with us for many years, as almost all of our clients still do. It just means you stay because the work is good, not because leaving is impossible.
The clearest example is our work with Green Industries SA. They were running on a legacy Oracle system called Zeus, and had already engaged us to move grants and contract management onto a modern, browser-based platform. The last thing keeping Zeus alive – and keeping its licence, infrastructure and support costs on the books – was a time-series module holding fifteen years of waste-management data. We migrated eighteen legacy Oracle tables, roughly 350,000 rows spanning 2008 to 2023, into a purpose-built Skyve module on SQL Server, moving every attachment across with the records. Zeus was switched off at the end of 2023. That retired the Oracle licensing fees entirely and freed up server capacity.
Just as importantly, we built the replacement so it wouldn’t become the next system nobody could change. New programs, measures and validation rules are configured by administrators, not coded by developers, and analysts can load, validate and explore new data sets themselves – with any bad import rolled back in a single action. The goal wasn’t only to get Green Industries off Oracle. It was to make sure the thing that replaced it stayed flexible. We took a similar path with PIRSA’s rural finance system, replacing an Oracle-based platform managing more than $430 million, with migrated interest calculations reconciled to within one cent.
Designing for exit also tends to produce a better system, even when a client never leaves. The same choices that make a solution easy to walk away from – owned IP, open technology, configuration instead of hard-coded behaviour, clean structure, documented data – are the choices that make it cheaper to maintain and easier to change as the business evolves. Freedom to leave and quality of ownership turn out to be the same discipline viewed from two angles. When the Australian Research Council’s tangled mix of legacy systems became a single solution defined largely in plain business terms across around 140 source files, the point wasn’t just tidiness. It was far less surface area to get wrong, and far less to be trapped by.
So when you’re weighing up a platform – an AI tool, a SaaS subscription, or a system you’re about to have built – it’s worth pricing the exit at the same time you price the entry. Ask who owns what you’re paying to create, how your data comes out, and what leaving would actually take. If the honest answer is “we’re not sure”, that’s worth knowing before you commit, not after.
If you’re stuck on a system you can’t easily leave, or you’re making a platform decision and want to think it through with someone who designs for this deliberately, we’re always happy to talk.