What Actually Happens to Your Data When You Switch DMS Providers

Most conversations about switching DMS provider focus on features: what the new system can do that the old one could not. Far fewer focus on what actually happens to the years of customer records, vehicle history, invoices and stock data sitting inside the system you are leaving. That is a mistake, because the data question is usually the one that decides whether the switch goes well or badly, not the feature list.

This is a plain description of what actually happens, the parts that go smoothly, the parts that commonly do not, and what that means for a dealer or garage thinking about moving.

Your data is legally yours, but that is not the same as having it

Under UK GDPR, personal data you hold as a data controller, your customers' contact details and service history, is yours to hold and yours to move. Most software contracts also state, in some form, that your business data belongs to you, not the provider.

The legal position and the practical position are two different things. Owning the right to your data does not automatically mean you can get it out in a usable format, on a reasonable timescale, without cost. That gap between legal ownership and practical access is where most of the difficulty in switching actually lives.

What an export request actually triggers

When you ask a provider for your data, one of three things typically happens.

A straightforward export: you get a set of files, usually CSV, covering the main tables (customers, vehicles, jobs, invoices), within a few days and at no extra cost. This is the outcome a well-run provider aims for.
A gatekept export: the data exists and can be extracted, but it takes weeks, requires a support ticket and follow-up calls, and sometimes comes with a fee attached to the exit clause in your contract. Nothing about this is illegal, it is just designed to add friction to leaving.
A partial export: you get some tables but not others. Attachments, scanned documents, historical pricing, staff permission structures and audit trails are the categories most often left out, either because they were never designed to be exportable or because nobody at the provider was ever asked to build that feature.

The practical difference between the first and third outcome is enormous, and you generally cannot tell which one you are going to get until you actually ask, which is why asking before you sign a contract, not after, is the only reliable way to find out.

What commonly gets lost

Even in a reasonably well-run migration, certain categories of data are more likely to fall through the gap than others.

Attachments and documents

Scanned MOT certificates, signed authorisation forms, photos taken during a health check, these are frequently stored separately from the main database, sometimes on a different system entirely, and are often simply not included in a standard export.

Historical financial detail

Summary invoice totals usually migrate fine. The underlying detail, exactly which parts and labour lines made up an invoice from two years ago, is a much less common export field, and matters if you are ever asked to justify a historical charge.

Staff and permission structures

Who could see what, who approved what, and what each person's role actually was rarely transfers at all. Almost every migration involves rebuilding staff accounts and permissions from scratch in the new system.

Anything mid-process at the moment of cutover

A job that is half-quoted, half-booked, or partially invoiced at the exact moment of migration is the single most common source of genuinely lost information, not because export is impossible, but because "in progress" records do not map cleanly between two different systems' definitions of a job.

What actually happens on the receiving end

Getting data out of the old system is one half of the problem. What happens when it arrives at the new one is the other half, and it is less automatic than most people expect.

Mapping: your old system's idea of a "customer record" and the new system's idea of one are rarely identical. Someone, either you or the new provider, has to map old fields to new ones before anything is imported.
Cleaning: duplicate customer records, vehicles logged under the wrong owner, and inconsistent formatting (phone numbers, postcodes) are near-universal in data that has built up over several years. A straight import copies these problems into the new system rather than fixing them.
Verification: someone needs to actually check a sample of migrated records against the old system before you rely on the new one, not after.

A provider that imports your historical data for you as part of onboarding, doing the mapping and cleaning rather than handing you a raw file and a login, removes almost all of the practical risk in this list. A provider that hands you the export and leaves the rest to you has handed the risk to you as well.

What to ask before you sign, not after

Can I get a full export of my data at any time, and in what format?
Does the export include attachments and documents, not just database records?
Is there a cost or contractual condition attached to exporting my data if I leave?
Will you import my historical data from my current system as part of onboarding, and who does the mapping and cleaning?
What happens to jobs and bookings that are in progress at the moment of cutover?

A provider that can answer all five clearly, before you have committed to anything, is telling you something real about how they think about your data. A provider that is vague on any of them is telling you something too.

Where Torque DMS stands on this

We do not charge to export your data. Not a reduced rate, not a fee buried in an exit clause, nothing. If you want a full export of your customer records, vehicle history, stock, invoices and documents, you get it, at any time, at no cost, whether you are leaving or not.

That is a deliberate position, not an oversight. We believe a business should stay with a DMS because it is the best option available to them, not because leaving has been made expensive or difficult. A provider that has to trap customers to keep them has already told you something about the product. We would rather compete on being worth staying with.

The underlying point

Software should be judged partly on what it can do for you, and partly on how easily you could leave if it stopped being right for you. A system that makes leaving difficult is relying on that difficulty to keep you, rather than on being worth staying with. The data question is how you find out which one you are dealing with.