The hardest part of switching dealer management systems is not the downtime. It is the data. A clean cutover depends on getting customer records, vehicle stock, open deals, and accounting balances into the new system without silent loss, duplication, or drift. This DMS data migration checklist walks through the parts that actually break in the field: field mapping, validation, and reconciliation, in the order you should tackle them.
If you have already read the switch-day playbook, this is the companion piece that lives one level deeper. Where the downtime guide is about sequencing and rollback, this article is about the records themselves: how to map a field in the old schema to the new one, how to prove a value survived the move, and how to reconcile the numbers before you let anyone book a deal. Treat it as the work that happens in the weeks before go-live, not the morning of.
Step 1: Inventory what you actually hold
Before you map anything, build a complete inventory of the data living in your current DMS. Most dealerships underestimate this. Beyond the obvious tables, there are attachments, notes, finance and insurance documents, service history, parts records, and years of accounting transactions. Some of it is structured, some sits in free-text fields, and some is in document storage bolted onto the DMS.
For each data domain, record the source table or export, the row count, the date range, and who owns it operationally. This inventory becomes your reconciliation baseline. If you skip it, you will have no way to prove later that the number of customer records you exported is the same number that arrived in the new system.
Decide what not to migrate
Not everything should move. Aged, inactive, or duplicate records often cost more to clean than they are worth carrying forward. Decide explicitly, in writing, what is in scope: active customers, current and recent stock, open deals, and the accounting history your jurisdiction requires you to retain. Archive the rest in a readable format rather than dragging it into a fresh system. A migration is the one clean moment you get to leave the clutter behind.
Step 2: Build the field mapping document
Field mapping is the core of the work. Every field in the source has to land somewhere defined in the target, or be consciously dropped. This is tedious and it is also where data quietly dies, so it deserves a real document that both the old and new vendor sign off on.
A workable mapping table has a row per source field and looks like this:
| Source field | Target field | Transform | Notes |
|---|---|---|---|
cust_name | customer.full_name | Split into first/last on last space | Manual review for company names |
reg_no | vehicle.registration | Uppercase, strip spaces | Primary match key |
vin | vehicle.vin | Validate 17 chars | Reject and flag if invalid |
acct_bal | ledger.balance | Currency to minor units | Sign convention differs between systems |
deal_state | deal.status | Lookup table old to new | No 1:1 mapping for two legacy states |
Three categories cause the most pain. First, identifiers: registration and VIN are your natural keys, so normalise them early (uppercase, trim, validate length) because everything downstream joins on them. Second, enumerations: deal statuses, vehicle types, and payment methods rarely map one-to-one between systems, so each needs an explicit lookup and a decision for legacy values with no modern equivalent. Third, money: currency precision and sign conventions differ, and a balance stored in minor units in one system and major units in another is a classic silent corruption.
Step 3: Validate before you load
Validation happens twice: on the way out of the old system and on the way into the new one. On export, check that every record has a usable primary key, that VINs decode, that registrations are well-formed, and that mandatory fields are populated. Records that fail go to an exceptions list for manual handling, not into the import file. A small, clean import beats a large, broken one.
Solid VIN handling matters here because it is your strongest vehicle identifier. If you are unsure how much you can trust a VIN as a key, the mechanics in VIN decoding explained cover what a VIN can and cannot tell you reliably.
Validate the target schema, not just the file
A file that imports without errors is not the same as a file that imported correctly. After the load, check that required fields in the new system are actually populated, that foreign keys resolve (every vehicle points to a real customer, every deal to a real vehicle), and that no field was truncated or coerced into the wrong type. Type coercion, dates read in the wrong format, numbers turned into text, is one of the most common post-load defects and one of the easiest to miss because nothing visibly fails.
This is also the moment to confront fragmentation. If your old setup spread the same customer across the sales, service, and parts modules, migration is your chance to consolidate. The patterns in dealership data silos explain why that fragmentation builds up, and a clean migration is the rare opportunity to collapse it rather than carry it forward.
Step 4: Run a full trial migration
Do not let go-live be the first time the whole dataset moves. Run at least one complete trial migration into a sandbox or test instance of the new DMS. The goal is not just to confirm the process completes; it is to produce numbers you can compare.
From a trial run you want three things: record counts per domain on both sides, financial totals (ledger balances, open AR/AP, deposit liabilities) matched to the cent, and a sample of records walked end-to-end so a human confirms a real customer, with their real vehicle and real deal, looks right in the new screens. Time the run too, so you know how long the real cutover will take and can plan the freeze window accordingly. The downtime mechanics of that window are covered in how to switch a DMS without downtime.
Step 5: Reconcile, then reconcile the money
Reconciliation is the step that separates a clean cutover from a hopeful one. For each domain, you match the new system back to the source and account for every difference.
- Compare record counts per domain. If the source customer count and the target count diverge, you owe an explanation for the gap (deduplicated, archived, or rejected as invalid) before you proceed.
- Compare financial control totals. Ledger balances, open invoices, and customer deposits must tie to the old system. Accounting data tolerates no rounding away of discrepancies.
- Spot-check linked records. Pull a sample of deals and confirm the customer, vehicle, and financials all resolve correctly across the joins.
- Log every discrepancy with a reason. The deliverable is a reconciliation report where each gap is either zero or explained. An unexplained gap is a defect.
Step 6: Freeze, delta, and keep the old system readable
When reconciliation passes on the trial, plan the real cutover around a freeze. Stop writes to the old system, run the final migration, then load a delta for anything that changed during the freeze window. Keep that window short and well-communicated so staff are not booking deals into a system that is about to become read-only.
After go-live, do not decommission the old DMS immediately. Keep it readable for at least one full accounting period, ideally through a tax or VAT cycle, so you can answer historical questions and re-check any figure that looks off. Exporting your historical data into an open, portable format you control is the safest version of this. It means your records are not hostage to a licence you are about to cancel, a principle explored in single source of truth for vehicle data.
Where VehIQ fits
VehIQ is being built as an API-first, EU-sovereign data layer for dealerships, and migration is exactly the kind of moment its design targets. The principle is that your records should be canonical, portable, and owned by you, in open formats, with field-level lineage so you can trace where every value came from. That lineage is what makes the reconciliation step in this checklist faster: instead of guessing why a figure moved, you can follow it back to its source field.
VehIQ is pre-seed and being developed, so this is a description of intent rather than a deployed result. The honest version is simple: a migration is painful in proportion to how locked-in and opaque your current data is. The more your records live in open, lineage-tracked formats you control, the less a future system switch costs you, this time and the next.