.png)
How to Move From One DMS to Another Without Losing Your Data
What has to survive a DMS migration, what to check in a provider's process before you commit, and what to verify yourself before switching off the old system.
Every dealer who has sat through a DMS demo has asked some version of the same question underneath the sales pitch, usually near the end, sometimes not out loud at all: what happens to everything if this doesn't work out, or if we just want to leave in three years? It's a fair question, and it's the real reason plenty of independents stay on a system they've long since outgrown rather than risk switching DMS providers and losing data they can't get back. The hesitation isn't about learning new software. It's the gap between deciding to switch and being certain nothing important got left behind on the way.
That fear deserves to be taken seriously rather than argued out of you. A DMS holds more than a stock list. It holds the pre-sale checks and disclosed faults that make a sales file defensible, the invoice history HMRC would want to see in a VAT enquiry, and the customer record a finance provider might ask you to produce for a deal that completed two years ago. None of that is the kind of thing you notice missing until the exact moment you need it, which is usually the worst possible moment to discover a gap.
This isn't an argument that migration is risk-free, because it isn't, and treating it that way would be a worse disservice than admitting the friction up front. What follows is a practical way to run it: what data actually has to survive the move, what to interrogate in a new provider's migration process before you sign anything, and what you should check with your own eyes before the old system gets switched off for good. If you're weighing whether to move off a spreadsheet in the first place rather than between two DMS platforms, that's a different decision with a different risk profile, and our piece on when a spreadsheet setup stops being enough covers that version of the question.
What actually has to survive the move
Treating "our data" as one undifferentiated blob is where most migration planning goes wrong, because the four things a DMS actually holds carry different risks if they go missing.
Stock records are the obvious one: descriptions, imagery, pricing history and provenance detail for cars currently on the forecourt, but also for stock already sold. A customer or a regulator asking about a car eighteen months after it left the lot doesn't care that it's no longer "live" in your system. Customer and CRM history is less obvious but matters just as much, not only the contact details and enquiry trail but the consent timestamps that prove someone actually opted into marketing contact, because a lost consent record doesn't just lose you a lead, it puts you in the position of holding data you can no longer prove you're entitled to use.
Compliance and sales-file documentation is the category dealers most often assume "comes with" the DMS export and most often find doesn't, because it's frequently the least structured data in the old system: a pre-sale check noted in a free-text field, a disclosed fault mentioned in an email rather than logged against the deal. What actually needs to be in that file, and why it needs to survive intact rather than as a summary, is covered properly in our piece on sales files and Consumer Rights Act defence. The short version for migration purposes: if the file wouldn't hold up as evidence before you moved, migrating it faithfully just moves the same weak file into a new system, it doesn't strengthen it.
Financial and invoice history is the fourth, and it carries its own specific wrinkle for used vehicle dealers: VAT margin scheme records aren't ordinary purchase and sale invoices, they're the documentation that lets you calculate and defend the margin on each qualifying vehicle, and losing the underlying purchase detail during a migration doesn't just create an admin headache, it creates a VAT problem. Ordinary commercial records generally need keeping for around six years to cover the standard limitation period for contract claims, so a provider's export needs to reach back further than "the current financial year" if you want the move to actually cover you.
One honest complication worth naming here: migration only ever moves what was actually captured in the old system in a structured way. If pre-sale checks were sometimes logged and sometimes just remembered, or consent was sometimes recorded and sometimes assumed, the migration will surface that gap rather than create it. That's worth auditing before you migrate, not after, because it's a much cheaper problem to fix while you can still ask the person who did the deal what actually happened.
What to check in a new provider's migration process before you commit
Most of the risk in a DMS switch doesn't sit in the data itself. It sits in whether the new provider has actually done this before, with a process rather than good intentions. Before signing anything, it's worth asking a new provider directly:
- Do they run the migration themselves, or hand you an export template and leave the field mapping to you?
- Have they migrated data from your specific current system before, rather than "we can take a CSV" in the abstract?
- Is there a test migration on a small subset of records before the full cutover, so mismatches surface on fifty records instead of fifteen thousand?
- Who signs off that the migrated data matches the original: the vendor, you, or a joint check against a defined sample?
- Is there a parallel-running window where both systems stay live, or is it a hard cutover on a fixed date?
- If you get partway through onboarding and decide not to proceed, can you get a usable export of your own data back, and in what format?
There's a regulatory question worth adding to that list that dealers often miss: the new DMS provider becomes a new data processor for your customer records the moment live data moves across, which means your data processing agreement with them needs to be signed before that happens, not tidied up afterwards as a formality. It's a five-minute conversation with a new provider and a genuinely awkward one to have retroactively with the Information Commissioner's Office if it never happened at all.
What to personally verify before you switch off the old system
This is the step that gets skipped most often, usually because everyone involved is relieved to be finished and keen to stop paying for two systems at once. Don't take the migration report's word for it. Check it yourself, specifically:
Search for a real customer by name and by vehicle registration in the new system, not just a record count that matches the old one, because a count can match while individual records are scrambled or duplicated. Open a sales file for a car sold well over a year ago and confirm every supporting document is attached, correctly dated and legible, not just present as a line entry with a filename that suggests it should be there. Reconcile a sample of invoices from a full quarter against your accounting records rather than a handful of recent ones, since gaps tend to hide in older data that nobody's looked at since it was originally filed. Confirm you can still run financial reports covering the periods HMRC or a finance provider might actually ask for, not just the current trading year.
Then, once all of that checks out: don't cancel the old system's licence the same week you go live on the new one. Keep read-only access, or a full exported archive, for as long as your statutory retention period runs. A dispute or an HMRC enquiry landing four years from now won't check whether you're still paying a subscription to the software that originally held the record, and by then the export you didn't bother taking is the only copy that ever existed.
None of this makes a migration risk-free, and it shouldn't be sold to you as though it does. Some manual checking afterwards is normal, and it's worth budgeting a proper half-day for it rather than a rushed twenty minutes between other jobs. A good provider's job is to make that half-day short and boring rather than pretending you won't need it at all. That's a genuinely different promise from "seamless," and it's the one worth actually trusting.
Where this fits into a bigger decision
If you're still comparing providers rather than actively planning a move, our DMS comparison guide is a better starting point than this piece, since the questions above only really bite once you've picked a direction. And if you want to see what day-to-day running looks like once stock, customer records and compliance documentation are sitting in one place rather than stitched together across systems, our features overview covers what that actually involves.
We didn't build MYDEALERSHIPVIEW to be a better database than whatever you're currently on. We built it to hand back a working day where nobody's first job every morning is chasing down a record that should already be there. If you're weighing a move and want to talk through what migrating your specific stock, customer and sales-file history would actually involve, get in touch through our features page and ask us the questions above directly, before you commit to a date rather than after.