Backups, Exports and Exit Plans: Protecting Your Data in Someone Else's Cloud

The email arrives on a Thursday afternoon. Your no-code platform has been acquired, the product is being “sunset” in 90 days, and customers are “encouraged to explore” the new owner’s offering at roughly double the price. Your entire order process lives in it.

Whether that email is a mild annoyance or a crisis depends almost entirely on what you did before it arrived.

The risks are ordinary, not exotic

When you move a process into someone else’s cloud, you’re trusting them with it. Usually that trust is well placed. But a handful of fairly routine events can still hurt you:

• Price rises. Per-seat pricing doubles, or a feature you rely on moves to a higher tier.
• Acquisition. The new owner changes direction, merges products or retires yours.
• Shutdown. Smaller vendors fail. Some give months of notice, some give weeks.
• Account problems. A failed payment, a suspended account, or an admin who leaves with the only login.
• Your own mistakes. Someone bulk-deletes 3,000 records, and the platform’s undo only goes back a day.

None of these is likely in any given month. Over five years, at least one is quite likely. Planning for them is cheap; scrambling isn’t.

Know what “your data” actually includes

People assume a backup means “the rows”. For a working process, the rows are only part of it. A useful export covers:

• Records: every table, with all fields, including archived and closed items.
• Relationships: which order belongs to which customer. An export that flattens these into text loses the structure you built (the subject of From Rows to Records: How to Think About Your Data Like an Application).
• Attachments: contracts, photos, receipts. These are often excluded from standard exports.
• History: audit logs and change history, if you need them for compliance.
• Logic: workflows, automations, permissions and form designs.

That last category is where people get caught. You can usually get the data out. Getting out the hundred small rules about who approves what is much harder, because they exist only in the tool’s configuration unless you wrote them down.

Set up regular exports

Don’t rely on the vendor’s backups alone. Their backups protect them from their disasters, not you from yours.

Set up a scheduled export, ideally automated, to storage your company controls. Many platforms offer this through a scheduled export feature or their API (a way for other software to read the data directly). If not, an automation platform can often do the job.

A sensible starting rhythm for a process that changes daily:

Use open formats. CSV is a plain-text table that almost anything can read; JSON is a structured text format that preserves nesting and relationships better. A proprietary backup file that only the vendor’s product can open isn’t an exit plan.

Make one named person responsible for checking that exports are actually running. Automated jobs fail quietly.

Test that you could actually leave

An untested backup is a hope. Once a year, run an exit drill.

Take your latest export and try to answer real questions from it without the platform. Could you find all open orders for a particular customer? Could you rebuild the core table in another tool within a day? Are the attachments there, and named sensibly?

Say an operations team runs this drill and discovers their export contains customer IDs but not customer names, because names live in a linked table that wasn’t included. That’s a ten-minute fix during a drill and a very bad week during a real shutdown.

Write the exit plan down

An exit plan is a one-page document you hope never to use. It should include:

1. Where exports are stored and who can access them.
2. The data model: main tables, key fields and how they relate.
3. The business rules and automations, written in plain English.
4. Which categories of tool could replace this one (see Buy, Configure, or Build? A Decision Framework for Internal Tooling).
5. The contract terms: notice periods, data retention after cancellation, and export rights.

Check the contract terms before you sign, not after. The questions in Choosing an Internal Tool Platform: The Questions Vendors Won’t Answer for You cover exactly this ground. If you want maximum control, Self-Hosting Your Internal Tools: When It Makes Sense and What It Really Costs walks through the trade-offs, though self-hosting moves the backup responsibility onto you rather than removing it.

Watch for early warning signs

Vendors rarely disappear without signals. Keep an eye out for:

• Long gaps between product updates.
• Support response times creeping from hours to days.
• Sudden pricing changes or new restrictions on exports.
• An acquisition announcement, however reassuring the wording.

None of these means you must leave. They mean it’s time to run the exit drill early and refresh the plan.

Where to start this week

• Run a full export of your main operational tool today and open it. Check that relationships and attachments are actually there.
• Schedule a recurring export to storage your company owns, and name the person who checks it.
• Find your contract and note the notice period and data retention terms.
• Spend an hour writing down your key automations and approval rules in plain English.