Avoiding Excessive Dependence on Your Software Vendor: What to Agree On

Dependence on a software vendor goes unnoticed as long as the relationship works. It surfaces the day something needs to change — the vendor, the subscription, or the person who was following the project — and no one in the company can say where the data is, whose name the services are registered under, or what it would take to run them elsewhere. This isn't a matter of trust: it's a matter of inventory, and it's done today, with a vendor you trust.

The goal isn't to be able to switch vendors tomorrow. It's for staying to be a choice, not the only road available.

The Inventory: What Exists, and Whose Name It's Under

The first exercise is a list. It's done once, updated whenever something changes, and it's there to uncover the points where the company doesn't actually own what it uses every day.

Data: Exporting It Isn't Enough, You Need the Relationships

A customer export into a spreadsheet is a list of names, not your archive. An archive is made of links, and links are the part that gets lost first.

• Identifiers: if customers have an internal code, it needs to appear in order exports too, or reconnecting them becomes manual work.
• History: previous statuses, modification dates, who did what. Often only the latest status gets exported.
• Attachments: contracts, photos, signed documents. These are files, not rows, and need to be exported along with an indication of what they were linked to.
• Calculated fields: totals, due dates, scores. If they aren't preserved, they have to be reconstructed by knowing the formula, which therefore needs to be written down somewhere.
• The format: open and readable without the program that generated it. An archive exported in a proprietary format is still dependent on the same tool.

Support, Maintenance, and Enhancement Are Three Different Things

They need three different names, or you discover, right when you need it, that what you needed wasn't included in the fee.

• Support: resolving a malfunction. It needs to be defined what counts as a malfunction, how it's reported, and what the response times are.
• Maintenance: updating components, security, adjustments when something changes around the system. It needs to be defined who decides to do it and whether it's included.
• Enhancement: changes and new features. It needs to be defined how they're estimated and who authorizes them.
• Handover: what gets delivered, in how long, and in what form if the relationship ends. This is the point almost no one puts in writing at the start, which is exactly when it's easy to discuss without tension.

The Test: A Real Export, at Least Once

A list of untested guarantees isn't worth much. The check costs half a day and should be done when everything's going well, not when it's actually needed.

1. Ask for a complete export of the data, not a sample chosen by someone else.
2. Open it on a company computer, without using tools lent to you by the vendor.
3. Take three real, complex cases — a customer with many orders, a file with attachments, a matter with a long history — and reconstruct them from the files. If you can't, the export is incomplete.
4. Try restoring a backup in a separate environment. A backup that's never been restored is a backup you know nothing about.
5. Write down what's missing and what can't be reconstructed: that list is the real result of the test.

A Sample Handover Package

Illustrative, to be adapted to the size of the project. This is the list of what should exist within the company and stay up to date, regardless of who maintains it.

• A list of accesses, with the company owner indicated for each one.
• The address of the code repository, when handover is provided for in the agreement, with instructions on how to start it.
• A description of the architecture in a few pages: which pieces exist and how they talk to each other.
• A list of third-party components and their usage terms.
• Backup procedure: where they're kept, how often, how long they're retained, and how to restore them.
• A sample data export with an explanation of the fields.
• Operational contacts and what to do in case of a blockage.

What This Guide Doesn't Cover

This guide covers technical continuity: access, data, documentation, testing. Code ownership, usage rights, contract clauses, and termination terms sit on a different plane and need to be checked against the contract and with a legal advisor, because what's described here as available depends first and foremost on what was written into the agreement. The choice between a standard system and custom software, and the checks on permissions and backups, have their own dedicated guides.