What happens to your data if the vendor shuts the product down
How to check, before you sign, whether you could actually get your data back if the provider is acquired, discontinues the product or goes bankrupt. What an export almost never contains and which contract clauses do real work.
Short answer. The contract almost always says the data is yours. You can still only get it out through whatever the vendor built in advance. An export pulled a week before shutdown rarely contains attachments, change history, permission settings or document templates. The check belongs at the buying stage, and it takes a day.
Russian companies went through this on Western systems after 2022 and learned what it costs. The lesson does not need repeating on a domestic service: products get discontinued here too, just more quietly.
”The customer owns the data” and what that gives you
That line is in every contract, and it describes ownership. It does not promise the data will come out in a usable shape. Between “your data” and “here is your data in a format someone can read” sits work that had to be done in advance.
One question makes the gap visible: in what form would you receive the customer directory with its links to orders, documents and correspondence. “We will export it to Excel” means a flat table without relations, which is a list of names. The structure can be rebuilt from it, and that is a project of its own.
Four exit scenarios, and the clocks run differently
| Scenario | Time you usually get | What makes it different |
|---|---|---|
| Planned end of life | 6–12 months | Support is still there and often helps with the export |
| The company is acquired | 3 months and up | The product lives on, pricing and roadmap change |
| Withdrawal from a country | Weeks | Shutdown can arrive before the announcement |
| Bankruptcy | Days | Servers go dark over unpaid bills, nobody to call |
Plan against the bottom row. It is also the rarest, which is exactly why nobody is ready for it.
What to check before you sign
Six questions for the vendor. They should be answered by whoever owns the product technically, not by an account manager.
- Is there an export of all data, or only of reports. A report is a slice built for a purpose. An export is what the database holds.
- What format, and do relations survive it. JSON or CSV with foreign keys works. Excel without keys does not.
- Do files come with it. Attachments, scans and signed documents usually live somewhere else, and they are easy to forget.
- Can you run the export yourself, today. If it takes a support ticket, there will be no export in the bankruptcy scenario.
- Is there a read API. It solves the problem more reliably than any button, because it lets you take a copy on a schedule rather than once.
- How long is data kept after termination. Thirty days is common, and nobody builds a replacement system in thirty days.
Ask for an export on a demo instance and look at it. A day spent on this while choosing costs less than everything else in this article.
What an export almost never includes
| What goes missing | Why it matters |
|---|---|
| Attachments and files | Contracts and scans are often the only original |
| Change history | Who changed a price or a status, and when |
| Roles and permissions | Rebuilt from what employees remember |
| Document templates | Layout, merge fields, printable forms |
| Relations between records | Without them directories become lists |
| Integration keys | Exchanges with other systems stop silently |
The last row is the dangerous one, because it surfaces last. The system is already replaced and the data migrated, and then the warehouse feed stops arriving. You find out a week later, from a stock discrepancy.
Contract clauses that do real work
A scheduled export on your side. The strongest clause is not an obligation on the vendor to hand data over. It is your right to pull it on a schedule. The difference shows up when the other party no longer has the will or the people.
Source code escrow. It works for boxed and on-premise products: the code sits with a third party and is released on agreed events. For a cloud service it buys almost nothing, because without the infrastructure and the data the code does not run on its own.
Retention after termination. Check the number and count backwards from it: within that window you have to choose a system, migrate the data and reconcile it. Thirty days is not a window. Ninety is a conversation.
The right to export while in arrears. Rarely written, and it is the clause that matters in the worst case: access closed over a debt, data inside.
The first two weeks after the announcement
Order matters more than speed.
Copy first, decide second. Take a full export the same day, before any decision about a replacement. Put it somewhere that outlives the contract.
Inventory what is actually used. Going through systems like these, a third of the functionality regularly turns out to be dead: reports nobody opens, modules switched on once. That is covered in more detail in the piece on migration timelines. Dropping what nobody needs shortens the project more than any speed-up in development.
Integrations, separately. List every system that exchanges data with the one going away. This is the list people forget, and it sets the real deadline.
Run in parallel instead of switching. Keep the old system readable for as long as you can. There is nothing to reconcile the new one against once the old one is off.
When building your own removes the question, and when it does not
It removes: the database sits in your perimeter, you take the backups, you own the code, and a vanished contractor means finding another one rather than losing data.
It does not remove: a custom system carries its own risk, and the risk is people. If one contractor wrote it with no documentation and no handover, you swapped vendor dependency for dependency on a particular team. The difference is that this one is visible and can be managed: demand documentation, repository access and the ability to hand the project on.
Choosing between buying and building does not settle the risk by itself. How to weigh it is in the piece on off-the-shelf versus custom.
Questions we get
Is cloud or on-premise safer for the data? On-premise removes the risk of being switched off and adds your responsibility for backups and updates. Cloud removes the operations work and adds dependency on someone else’s decision to keep going. Choose on whether you have people to run it.
Can a database backup replace an export? It can, if the format is open and the schema is documented. A dump of proprietary storage with no description of its structure is an archive with nothing to read it.
The vendor promises to help if they ever close. Is that enough? Promises are kept by people, and when a product closes the people leave first. The clause works when it describes something you do, not something they do.
What does migrating the data into a new system cost? It depends on how many entities there are and how tightly they are linked. For replacements of large systems: audit from 1.5M ₽, migration of the critical core from 5M ₽. The stages are on the system replacement page.
Where this leaves you
The check happens once, while you are still choosing: ask for an export on a demo instance, look at what is in it, and put the right to pull data on a schedule into the contract. It costs less than any scenario above, and it is the only thing that works when the vendor goes bankrupt.
If the choice is already made and the question is different, here is how we run replacements of systems that left.
Facing a similar problem?
Tell us what you are building. We will walk through the architecture and give you a budget range in one call.