Businesses worry about who owns the code and, less often, about who controls the accounts. Both matter, and we have written about both.
Data is the third leg and it gets the least attention despite deserving the most, because of one asymmetry. Code can be rewritten. Accounts can be recreated, painfully. Ten years of customer records, order history and support conversations cannot be reconstructed at any price if you lose access to them.
Everyone assumes they can get their data out. The assumption is almost never tested, and the week you need it to be true is the worst possible week to find out.
Four ways businesses lose data they thought they had
None of these involves anybody behaving badly, which is why they keep happening.
The account was never yours. A supplier set up the CRM, the analytics and the file storage under their own account, added your staff as users, and did the work well for four years. When the relationship ends, the accounts go with them, because they always belonged to them. This is the single most common version and it is entirely preventable at setup.
The export worked but the data did not. Somebody exported everything on the final day, the files downloaded, everyone moved on. Six weeks later, halfway through loading it into the new system, it emerges that attachments were references rather than files and that nothing links orders to customers. By then the old account is closed and the supplier has no obligation to help.
The person left. Not a supplier problem at all. One employee held the administrator credentials, ran the exports onto their own laptop, and understood how the system was structured. They resign, and the business discovers that its continuity plan was a person.
The bill went unpaid. A card expired, a renewal notice went to somebody who had left, and the account was suspended before anybody noticed. Most vendors restore accounts on payment. Some have already begun deletion, and the recovery window in the terms of service is frequently much shorter than people assume.
The common thread is that in three of the four cases, a recent export sitting in your own storage would have converted a serious problem into a minor one. That is the whole argument for doing this on a schedule rather than at the exit.
Test it now, while nothing is wrong
Not a clause in a contract. Not a demonstration by your supplier. An export that you request, download and open yourself, this week, while nobody is under pressure and the relationship is good.
Then check five things.
Does the record count match what the system reports? A system showing 14,000 contacts should produce roughly 14,000 rows. It is remarkable how often it does not, and the discrepancy is always instructive.
Did the relationships survive? This is the one that matters most and fails most quietly. A customer list and an order list are nearly useless if nothing reliably connects them. The value in operational data sits largely in the joins: which order belongs to which customer, which invoice settled it, which ticket followed. Five clean spreadsheets with no keys between them are five orphaned lists.
Did attachments come out, or only their filenames? A business holding ten years of signed contracts as attachments is holding something irreplaceable, and a filename is not a document.
Is the text readable? Encoding problems are common and they hit Arabic text hardest. Open the file and look at actual records rather than trusting that a file downloaded successfully.
Are the fields you rely on present? Custom fields added after the original setup are a frequent casualty, and they are usually the ones carrying the information specific to how you work.
What an export leaves behind
Even a well-behaved export tends to drop the same categories.
Audit history, meaning who changed what and when. Internal comments and notes attached to records. Anything hierarchical, because flat formats flatten it. Configuration and workflow rules, which are not data exactly but represent real work to recreate. And permissions, which nobody thinks of as data until they are setting up two hundred users again.
None of that is a scandal. Export functions are generally built to move records, not to reproduce a system. It matters because the gap between "we can export" and "we can leave" is made of exactly these items, and you want to know its size in advance.
The limits platforms publish
Vendors document their export constraints, and reading them is quicker than discovering them.
HubSpot's own documentation is a useful example because it is specific. Exports arrive as CSV, XLS or XLSX. A CSV above two megabytes is zipped automatically. XLS files cap at 65,535 rows and 256 columns, while XLSX allows 16,384 columns. Exports split into multiple files beyond a million rows [1].
And one line worth writing down: download links for export files expire after thirty days [1].
That last detail causes real damage. Somebody requests an export as part of an offboarding, gets absorbed by the twenty other tasks involved in switching systems, and returns weeks later to a dead link and a closed account. Download immediately, verify immediately, and store it somewhere durable.
Every platform has its own version of these constraints. Find your systems' documentation and read it before you need it.
Exporting is not the same as restoring
A file you have never loaded into anything is an untested assumption.
Import it somewhere. A spreadsheet, a trial account of a competing product, anything. Confirm the records arrive intact and that the ones you spot-check look right. This exercise reliably surfaces the encoding, attachment and relationship problems that simply looking at a file listing never will.
It also answers a question the export alone cannot: is this usable by anyone other than the supplier who produced it? An export of a hundred files with no schema, or one whose structure only your current supplier understands, is technically compliant and practically worthless. Ask for documentation of the export structure alongside the export itself, because that is what makes the data portable rather than merely retrievable.
Do it on a schedule
Most people think about this only when leaving. That is the narrowest version of the problem.
A recent export also protects you against an account suspended over a billing failure, a supplier dispute that turns unpleasant, a supplier that stops trading, and a mistake by somebody with administrator access. In each of those cases what you already hold is what you have, and none of them announce themselves in advance.
Monthly is reasonable for anything business-critical. Store the result somewhere you control, which means not inside the system you exported from and not on one employee's personal device or personal cloud account. That last pattern is extremely common and quietly recreates the dependency you were trying to remove, except now on a person instead of a supplier.
Keep a sensible history rather than an infinite one, because every retained copy of your customer database is also a liability. The most recent few plus one per year is a reasonable default, deleted deliberately rather than left scattered. And treat exports as sensitive: encrypted storage, restricted access, never an email attachment.
The migration nobody scoped
If the export is the first half of the problem, loading it somewhere else is the second, and it is routinely treated as a formality.
Old data does not fit new rules. Records with fields that were optional in the previous system and are mandatory in the next one. Duplicate customers created before anybody added a check. Dates stored as text in three different formats. Statuses that were retired from the interface years ago but still sit on thousands of historical rows. Every one of those needs a decision: migrate it, correct it, or leave it behind.
Those are business decisions rather than technical ones, and they need somebody from the business to make them. A developer cannot tell you whether a customer record with no trade licence number should be migrated, rejected, or flagged for review. Left to a technical team working to a deadline, they get resolved by whatever is fastest, and the consequence surfaces months later when somebody cannot find a historical order.
Two things help. Profile the data before committing to a plan, meaning count how many records fail the new system's rules and how many are duplicates. That number is usually higher than anybody expects and it always changes the estimate. Then decide explicitly what you are not migrating, because keeping ten years of history purely because nobody wanted to make the call is how a short migration becomes a long one.
If some history has to stay accessible but does not need to be live, that is a much cheaper problem: a read-only archive rather than a migration.
The contract terms that matter
Four points, and most contracts address one of them vaguely.
That the data is yours. That you can export it at any time, without charge and without needing approval. What formats are available and within what timeframe on request. And what happens on termination, specifically how long you retain access to retrieve it and when it is deleted.
Watch for terms that end access on the day the contract ends. Combined with a large dataset, that leaves no window in which to discover the export was incomplete. Thirty days is a minimum and ninety is more realistic for anything substantial.
Watch also for export fees that appear only at the exit. That is a switching cost dressed as a service, and a supplier who will not commit to free export at signing has told you something about how they intend to retain your business.
Ask about all of this during a sales process rather than after. Better still, ask to see an actual export from an existing account rather than a description of one. How readily a supplier shows you the exit is a fair indicator of whether they expect to keep you through quality or through friction.
Custom-built systems, and the two different questions
If your system was built for you, the data sits in a database you should be able to reach, which is a better position than a hosted product. Confirm three things: that you can obtain a full backup, that you know its format, and that somebody other than your current supplier could restore it.
That last point separates two questions people routinely merge. Code ownership is an intellectual property question, covered in our guide on who owns your code. Data access is a credentials and infrastructure question, covered in our guide on the accounts your business must own. A business can genuinely own its code and still be unable to reach its own database, because the hosting account is in somebody else's name.
If the concern is a supplier disappearing entirely, people often reach for software escrow. Our escrow guide explains why that mechanism addresses code rather than live data, which makes it the wrong instrument for this specific worry.
On the legal position
The UAE has a Personal Data Protection Law, Federal Decree-Law No. 45 of 2021, and the official government portal describes rights it gives individuals including requesting correction of inaccurate personal data and restricting or stopping its processing [2].
We are not going to set out the full list of rights, or the status of the executive regulations, because we could not verify either from a primary government source, and every detailed account in circulation comes from commercial advisory sites rather than from the legislation. If your question turns on what the law entitles you to, take it to the UAE Data Office or a qualified adviser.
There is also a distinction worth keeping clear. Data protection law governs individuals' rights over their own personal data. It is not a company's commercial right to extract its business records from a vendor. That second thing is governed by your contract, which is why the terms in the previous section do far more work here than the legislation does.
Make the list first
The tool nobody remembers is invariably the one holding something irreplaceable.
Write down every system holding business data: CRM, accounting, email platform, helpdesk, file storage, payment processor, analytics, project management, HR. Then rank them not by cost but by what could not be reconstructed from anywhere else. Those are different orderings more often than not, and the expensive system is frequently not the irreplaceable one.
Start with the top of that list. For most businesses it is customer records and transaction history, because marketing content can be rewritten and settings can be rebuilt, while a decade of order history cannot.
What it costs
Running one export and opening it costs an hour and nothing else. That is why it is worth doing this week rather than scheduling.
A structured review across your systems, establishing what each holds, whether it genuinely exports, and what your contracts actually say about it, starts from around AED 1,500 with us. Where the work extends to assessing a custom system and how to extract from it, a codebase and dependency review starts from around AED 4,000. Final pricing depends on scope, and these are our own figures rather than a market survey.
Today, though: export from whichever system holds your most irreplaceable data, download it, open it, and check the record count against what the system reports. If the numbers do not match, or you cannot work out how to export at all, you have found something that matters. You have found it on a quiet afternoon, which is the only good time to find it.
References
- HubSpot, export your records
- UAE Government, data protection laws
- UAE Legislation, Federal Decree-Law No. 45 of 2021 on the protection of personal data
- SKIMBOX, who owns your code in the UAE
- SKIMBOX, the accounts your business must own
- SKIMBOX, software escrow in the UAE
- SKIMBOX, PDPL compliance in the UAE
Platform export limits are accurate as of 28 August 2026 and change without notice, so check the vendor's own documentation. This article is not legal advice, and questions about rights under UAE data protection law should go to the UAE Data Office or a qualified adviser.
