8 Vendor Lock-In Risks to Check Before Signing a Software Contract

Key Takeaways

• Vendor lock-in is the point where leaving a supplier costs more in money, time or technical pain than staying, even when staying is the worse deal.

• Lock-in is written into the contract long before it shows up in the code. Eight clauses do the damage: source code ownership, credentials, licensing terms, data export, cloud portability, third-party software dependencies, documentation and exit rights.

• From January 12, 2027 the EU Data Act bans cloud switching charges outright, and the UK competition regulator found fewer than 1% of cloud customers switch provider in a year.

• Under Australian copyright law, paying for software does not mean you own it. Without a signed assignment, the developer keeps the copyright.

• Includes a red-flag table and a pre-signature checklist you can take straight into a contract review.

Nobody signs a software contract expecting to be trapped by it. You sign because the demo looked sharp, the quote fit the budget, and the team seemed to understand your business.

The trap tends to show itself later, in year two, when you ask for a copy of your source code and receive a polite explanation about "our proprietary platform." Or at renewal, when the per-seat price jumps 40% and the migration quote from a rival arrives higher than the increase you were trying to escape. Or on the morning your developer stops replying to emails and you discover the AWS account, the domain and the app store listings are all registered in their name.

None of it was a surprise, strictly speaking, since all of it was sitting in the contract. It is just that nobody read page nine.

What Is Vendor Lock-In?

Vendor lock-in is the point at which leaving a software supplier costs more in money, time or technical disruption than staying with them, so a business keeps paying a provider it would otherwise replace.

In a software contract it takes four forms. Technical lock-in ties your product to one provider's proprietary services. Data lock-in holds your records in closed formats or behind extraction fees. Contractual lock-in uses renewal, notice and termination terms to make leaving expensive on paper. And legal lock-in leaves copyright or credentials in the vendor's hands, so the product is not fully yours to take elsewhere.

Below are the eight places those four forms hide in a software agreement, what the wording looks like, and what to ask for instead.

Why Vendor Lock-In Deserves a Harder Look in 2026

Three things are working in buyers' favour right now, and two of them are recent.

Regulators stopped treating lock-in as a grumble and started treating it as a market failure. The UK's Competition and Markets Authority concluded its cloud services market investigation in July 2025, finding that fewer than 1% of customers switch cloud provider in a given year and naming vendor lock-in as an adverse effect on competition, driven by egress fees, technical barriers to interoperability and restrictive software licensing terms.

Then Europe put a date on it. Article 29 of the EU Data Act, Regulation (EU) 2023/2854, is titled "Gradual withdrawal of switching charges" and states that from January 12, 2027 providers of data processing services may not impose any switching charges on a customer for the switching process, egress fees included. The European Commission's Data Act policy page tracks implementation. That obligation reaches any provider serving EU customers, which covers plenty of platforms Australian businesses sign with, and if your contract auto-renews past that date on old terms you may be paying for something the law no longer permits elsewhere.

Australia has its own lever, and it predates both. The unfair contract terms regime under the Australian Consumer Law has carried civil penalties since 9 November 2023 and applies to standard-form contracts with businesses under 100 staff or $10 million in turnover, which is to say most of the companies reading this. So the takeaway for an Australian SME is twofold. Switching costs are becoming negotiable overseas, and some one-sided terms may already be unenforceable here. Either way, the leverage sits with you before you sign rather than after.

Risk 1 - Source Code Ownership That Was Never Assigned to You

Under the Copyright Act 1968 (Cth), a computer program is a literary work, which means the person who writes it owns the copyright until they sign that ownership away. Business Victoria's guidance on intellectual property considerations for software ownership puts it without hedging: contractors own the copyright in your software unless a written agreement assigns it to you, and the assignment has to be signed by the original owner before it does anything at all.

Paying the invoice buys you nothing on its own, and the clause founders usually point to when this comes up, some version of "all deliverables belong to the client," will not save them either, because "deliverables" in a software contract tends to mean the thing that runs rather than the code behind it.

Three bits of wording are worth getting right:

• Present tense, not future. "Vendor assigns" transfers copyright now. "Vendor shall assign" promises a future act that nobody performs once a relationship has soured.

• Everyone who touched it. The assignment must reach the vendor's employees and any subcontractor they brought in, since those people own their contributions by default and nobody can assign what they never held.

• The code that came with them. Pre-existing libraries the vendor reuses across clients stay theirs, which is normal, but you want them listed and licensed to you on terms that survive the relationship ending.

Risk 2 - Accounts and Credentials Registered in Someone Else's Name

A clean assignment on page four is worth less than people assume if you cannot reach the thing running in production, and this is the version of lock-in we meet most often in takeover work. The pattern repeats almost word for word: the client owns the IP on paper, but the Git repository sits inside the agency's organisation, the cloud account bills to the agency's credit card, the domain was registered by a developer who has since left, and the Apple Developer account belongs to a company nobody at the client has heard of.

Nothing about that is necessarily sinister. It starts as convenience during a build and then never gets unwound, which is why it needs a date attached rather than goodwill. Every account should be registered and billed to your business entity, with you holding owner permissions and the vendor added as a collaborator you can remove: repository, cloud, DNS, app stores, analytics, payment gateway, error monitoring. Name that list in the contract as a dated deliverable, because a handshake on this one evaporates at exactly the moment you need it honoured.

Risk 3 - Software Licensing Terms That Move After You Sign

Software licensing terms are where the cost of staying gets ratchetted up quietly, one renewal at a time, and the clauses that do it are rarely the ones anyone negotiates hard at signing.

Five are worth circling with a pen. Unilateral amendment rights let the vendor change terms later with notice rather than agreement. Renewal pricing set at "then-current list price" is an uncapped increase wearing a neutral phrase. Per-user definitions sometimes count dormant accounts, so the bill grows while your team shrinks. Audit rights allow the vendor to inspect your usage and invoice retroactively. And auto-renewal windows demanding cancellation 90 days out convert a missed calendar reminder into another full year.

Two of those five may not even be enforceable against you. Since 9 November 2023, the unfair contract terms regime under the Australian Consumer Law has carried civil penalties, and it covers standard-form contracts with businesses employing fewer than 100 people or turning over less than $10 million, which takes in most Australian SMEs. The ACCC specifically flags terms that let one party vary the deal unilaterally without giving the customer a matching right to exit. If your vendor's agreement is a take-it-or-leave-it template rather than something you negotiated clause by clause, that is a standard-form contract, and a unilateral amendment right sitting in it without a corresponding exit right is worth raising on exactly those grounds.

That audit clause deserves more attention than it gets. Industry surveys through 2025 and into 2026 report licence audits climbing in both frequency and settlement size, with the resulting true-up bills landing on finance teams that held no reserve against them.

Counter all five in one pass: cap the annual uplift to CPI or a fixed percentage, pull cancellation notice back to 30 days, freeze the definition of a "user" in the agreement so it cannot be reinterpreted, and limit audits to one a year with the vendor carrying the cost if you come up compliant.

Risk 4 - Data You Cannot Get Out in a Usable Form

Picture the day you decide to move. You cite the clause granting you full ownership of your data, and three weeks later a link arrives containing 400 PDF invoices. Every file is, in the strictest sense, yours. None of it loads into the new system without someone rekeying it by hand.

Ownership is the easy half of this problem. The half that hurts is format, completeness, and cost. A database dump with the relational structure stripped out fails in much the same way, as does a CSV that quietly omits every attachment and audit log, and on a data-heavy product the extraction bill can run past a year of subscription fees, which is a switching cost in all but name.

Write the specifics in rather than the principle. You want a complete export, in named open machine-readable formats, carrying attachments, logs and relational structure, available on demand without a support ticket and without a charge. Require the vendor to keep it retrievable for 60 days after termination, then delete it on written confirmation. Where the system holds personal information, pin down the hosting location too, since Privacy Act obligations are far easier to meet when you know which jurisdiction the records sit in.

‍

‍

Risk 5 - Cloud Portability Written Out of the Architecture

There is one question that sorts vendors faster than any clause you could draft, and it is worth asking out loud in the room: which proprietary cloud services will this build depend on, and what would it take to run it somewhere else?

A team that has thought about cloud portability answers in a page. A team that has not reaches for reassurance instead of specifics, and the reassurance is itself the answer. These decisions get made around day three of a build and become expensive to reverse by day three hundred, which is why the question belongs in procurement rather than in a retrospective two years later.

What you are listening for is whether the application leans on one provider's managed services for authentication, queuing, search, functions and storage all at once. That is not really a cloud application; it is an application that exists on precisely one cloud, and moving it later is a rewrite wearing the costume of a migration. Egress fees compound it, since the cost of leaving scales with whatever data you have accumulated by then, and smaller customers feel that most sharply.

Containerised deployment, infrastructure defined as code and handed to you, and provider-specific calls kept behind an abstraction layer are the practical answers, which we worked through in our guide to preventing lock-in when building custom software.

Risk 6 - Third-Party Software Dependencies You Inherit Blind

Your contract covers the code your vendor writes, which would be reassuring if modern applications were mostly made of code the vendor wrote. They are not.

Black Duck's 2026 Open Source Security and Risk Analysis report audited 947 commercial codebases and found open source in 98% of them, with licence conflicts in 68%, the highest rate across the report's eleven-year run and a sharp jump from 56% the year before. One codebase carried 2,675 separate conflicts. A good share of that increase, the researchers suggest, traces back to AI coding assistants reproducing snippets from copyleft projects without carrying the original licence terms across with them.

For a buyer, this is not an abstract governance concern. A copyleft component sitting inside your billing module can carry obligations affecting how you are permitted to distribute your own product, and it tends to surface during investor due diligence, when your negotiating position is at its most delicate.

Four things in the schedule cover most of it: a software bill of materials delivered with the code and refreshed at every release, a warranty that no component carries licence terms incompatible with your commercial use, an IP indemnity with teeth, and a plain description of how the vendor reviews AI-generated code before merging it. That last item would have been an odd request two years ago, and it is now the one most likely to surprise you.

Risk 7 - Documentation That Exists Only in Your Vendor's Head

Undocumented software achieves lock-in without needing a clause to do it. When the only person who understands your deployment pipeline is the one you are trying to part ways with, the switching cost becomes whatever they decide it is, and any replacement team will quote you for discovery before they can quote you for the work itself.

The fix is unglamorous: make documentation a contractual deliverable with acceptance criteria, rather than the line item quietly dropped when the timeline tightens in month four. Architecture overview, environment setup, deployment runbook, API references, data model, third-party accounts and dependencies, known issues. Our breakdown of what a complete handover pack should contain works as the schedule itself if you would rather not draft one.

Before you sign, try this. Ask the vendor to walk you through a new developer's first week on the project. Teams who have written things down give a detailed, slightly boring answer about where the setup guide lives and how long the environment takes to stand up. Teams who have not will tell you how quickly their people get up to speed, which is a different answer to a different question.

Risk 8 - Exit Terms That Assume You Will Never Leave

Most software contracts spend nine pages on how the relationship begins and one sentence on how it ends, and the imbalance is not accidental. Everything you want on the way out has to be agreed while the vendor still wants your signature, because afterwards you are asking a favour rather than enforcing a term.

Without defined exit obligations, your vendor owes you no help in leaving, faces no deadline for handing anything across, and has every commercial reason to take its time. Termination for convenience may be absent altogether, or present but priced at the full remaining term, which comes to the same thing. The handover itself, the part deciding whether your new team starts in week one or week seven, sits entirely at the outgoing vendor's discretion.

Pin it down in advance: a transition assistance clause that expressly survives termination, an assistance period between 30 and 90 days, a named list of what gets handed over, and a rate card for that work agreed now rather than quoted later under pressure. Termination for convenience with proportionate notice belongs there too, and if the vendor hosts anything you could not rebuild yourself, source code escrow is cheap insurance.

How a vendor reacts to this conversation tells you most of what you need to know. The ones who work through it calmly are confident you will stay because the work is good; the ones who resist have handed you a free and very useful piece of information.

Vendor Lock-In Risk Table: Red Flags and Fixes

Your Pre-Signature Checklist

Print this. Take it to the contract review. Anything you cannot tick is a conversation to have before signing, not after.

☐ Is copyright in new code assigned to my entity in the present tense, in writing?  

☐ Does the assignment cover subcontractors and freelancers the vendor engages?  

☐ Are pre-existing vendor components listed, with the licence terms I am getting?  

☐ Will every account (repo, cloud, domain, app stores, payments) be in my business name?  

☐ Is the renewal uplift capped, and is the cancellation notice period 30 days or less?  

☐ Can I export all my data, in open formats, on demand, at no charge?  

☐ Do I know which proprietary cloud services this build depends on?  

☐ Will I receive a software bill of materials, updated at each release?  

☐ Is documentation a deliverable with acceptance criteria and a date?  

☐ Does a transition assistance clause survive termination, with agreed rates?  

☐ If this vendor disappeared on Monday, could another team take over by Friday?

Ten yeses and a plausible answer to the last one puts you in better shape than most businesses signing software contracts this year.

Already Signed? You Have More Options Than You Think

Lock-in runs on a spectrum, and almost nobody sits at the far end of it.

Start by finding out what you hold today, as opposed to what you assumed you held. A code audit tells you who owns what, which dependencies carry obligations, where the credentials live, and how deep the proprietary coupling goes. That picture usually looks better than the worry does, and it gives you something concrete to put on the table at renewal. It also surfaces the maintenance bill you have been quietly accruing, which we unpacked in the seven ways technical debt drains a development budget.

From there it is sequencing: decouple the highest-risk dependency first, keep the product running, work down the list. Teams who inherit a tangled build and need it stabilised before anything else can happen come to us for codebase recovery and takeover work. If what you need is a new build that stays portable from the first commit, that is what our cross-platform app engineering is built to deliver.

The contract you sign this quarter sets the terms of every negotiation you will have with that vendor for years. Spend an afternoon on page nine.

‍

‍