Ask how you get your data out before you put any in

Every piece of software you buy ties you to someone, and mostly that’s a fair deal. A good vendor gives you a product, support and a head start you’d never get building it yourself, so depending on them isn’t the problem. The problem is lock-in: the specific point where leaving costs so much, or breaks so much, that you stop treating it as an option. You’re not choosing to stay anymore. You just can’t afford to go, so you keep paying whatever they ask.

The thing about lock-in is that it’s cheapest to prevent at the exact moment you least want to think about it, which is while you’re excited about a new tool. The questions that protect you are awkward to raise during the honeymoon, and obvious to raise on the way out, when it’s too late. So raise them first.

The renewal where the lock-in gets cashed in

Here’s how it plays out in practice. The operations manager at a plumbing business, thirty staff across southern Queensland, gets the renewal notice for the job-management platform the whole company runs on. The price is up 38 per cent. No new features to speak of; the email calls it “aligning with market value”. Annoyed, she prices the alternatives, and a competitor quotes half the money for a product that looks at least as capable.

Then she scopes the move. Seven years of job history. Forty thousand site photos attached to jobs. Customer notes that tell the crews which gate to use and which dog bites. The Xero connection, the automated SMS reminders, and sixty field staff who know the current app blind. The export gives her a spreadsheet of jobs and a folder of unlabelled images with the links between them gone. Rebuilding all of that lands somewhere in the tens of thousands, plus weeks of disruption in her busiest season.

So she renews. Not because the product won the comparison, but because leaving lost it. The vendor understands this arithmetic better than she does. The price rise was calibrated to sit just under the pain of exit, and every year she stays, the exit gets dearer, which means next year’s rise can be bigger. That’s lock-in doing exactly what it’s designed to do.

The questions to ask while you’re still a prospect

Before you sign, ask how you get your data out, and make the vendor show you, not just say yes. Which formats. Does the export include the attachments and the history, or only the tidy core records. Is there an API for ongoing access, or just a manual download button. And does that API cost extra, or sit behind the plan one tier above the one you’re about to buy.

A vendor confident in their product answers these plainly, because they keep you by being good, not by being hard to leave. A vendor who gets vague, or who treats “how do I get my data out” as a strange question to be asking so early, has told you something useful. Ask it early precisely because the answer is most honest before they’ve got your money and your data.

Keep the logic that’s actually yours outside their tool

When every scrap of your process logic, reporting and workflow lives inside one vendor’s product, swapping that product later is brutal, because you’re not just moving data, you’re rebuilding how the business runs. One way to soften that is to keep the parts that are yours in a layer you control.

A separate integration layer can hold your business rules, your reporting and the workflow that stitches tools together, so those don’t belong to any single vendor. Use the vendor’s features where they’re good. Just be deliberate about what you’re handing them ownership of, because ownership is the thing that’s expensive to take back. The more of your core logic that lives in a place you control, the less any one vendor’s product is load-bearing, and the more a future switch is an inconvenience rather than a rebuild.

AI platforms invent new ways to trap you

AI tools have added fresh flavours of lock-in that are easy to miss. Prompts stored in the vendor’s own format. Document indexes embedded in their system. A fine-tuned model you can’t actually extract. Workflow builders. Evaluation history and usage logs you can’t lift out cleanly. Each one quietly deepens the moat.

For any AI system that matters to the business, keep the things you’d need to rebuild elsewhere in a place you own: the source documents, the evaluation sets you use to check quality, the prompts, the business rules, the logs. If the vendor doubled their price or disappeared tomorrow, those are the assets that let you move instead of start over. The model is replaceable. The material you spent a year assembling around it is the part you can’t afford to leave behind.

A CSV dump is not portability

Here’s the trap that catches people who thought they were being careful. The vendor offers an export, you tick the box, and you feel covered. Then you actually open the export and find it’s a flat dump that lost the relationships between records, dropped the attached files, stripped the metadata, and left out the audit history. Technically you have your data. Practically you have a flat dump you can’t reassemble into a working system.

So if the tool is important, run the export now, while you’re still happily a customer, and look hard at what came across. And check what it does at your scale, not the demo’s. A download button that behaves at 500 records can time out at 50,000, and plenty of vendor APIs are rate-limited hard enough that a full extract takes days of polite, throttled requests. Some vendors will do a full extract for you as a paid service; find out what that costs and how long it takes while the question is hypothetical. For anything with real structure to it, portability means live API access and a data model you planned for, not a download button you’ll trust in an emergency you’ve never tested. Test the escape hatch before you need it, the same way you’d test a backup you’ve never restored.

Price the exit before you need it

Once a year, for each tool the business would struggle to run without, spend an hour pretending you’re leaving in twelve months and write down what would have to move. The data, including attachments and history. Every integration and automation pointing at the tool. The templates and documents stored inside it. The reporting people depend on. The retraining for the staff who live in it daily. Put a rough dollar figure and a rough number of weeks next to each line.

The total is your exit cost, and it’s worth knowing for two reasons. It tells you how exposed you are if the vendor lifts the price, gets acquired, or sunsets the product. And it changes the renewal conversation, because a customer with a live, costed exit plan negotiates differently from a hostage, and vendors can tell the difference. You may never use the plan. Having it is the point.

The same drill works in reverse when you’re choosing. Two products look similar on the feature grid, but one has a documented API, exports that include attachments and history, and no objection to your workflow logic living outside their walls. The other has a download button and a sales rep who changes the subject. Priced over five years with an exit in mind, they’re not the same product at all.

Write down how it all hangs together

Lock-in gets dramatically worse when the only person who understood the setup has left and nobody else can explain how the pieces connect. So write it down: the systems, the integrations, where the API keys live, how data flows between tools, who owns what, and what breaks if any one piece fails. It always feels like busywork, and it’s the cheapest insurance against being trapped by your own architecture.

Some lock-in is a fair trade you made with your eyes open because the product’s worth it, and that’s fine. The dangerous kind is the lock-in nobody chose, the sort that accumulates over years of small shortcuts until one day leaving is simply off the table. You don’t need freedom from every vendor. You need enough control, and enough of your own data and logic in your own hands, to change direction when the tool you’re on stops fitting the work. And if you’re already deep inside a system you can’t leave, that’s an engineering problem with a known shape, not a life sentence; modernising your way out of legacy software is a project we scope all the time. If you want a read on how trapped you actually are, tell us your stack and we’ll map where the exits are.