A DMS migration checklist: what to export, what to verify, what to run in parallel

A DMS migration goes cleanly when three things are written down before you give notice: what to export (everything, in an open format, while you still have full access), what to verify once it lands (that what arrived matches what left, checked against your own copy rather than the vendor's word), and what to run in parallel (both systems through the cutover week, so nothing is discovered after the old one is gone). This guide is that list, in that order.

Most dealers stay on a system they have outgrown for one reason, and it is not loyalty. It is that the switch looks like it could go wrong in a way that costs a month of selling. That fear is reasonable. It is also mostly addressable, and what addresses it is a boring list written down in advance.

This is that list. It is vendor-neutral: none of it depends on where you are going, and all of it applies whether you are leaving a desktop system, a browser-based one, or three tools stitched together.

Before you give notice

The order matters here. Do these while you are still a customer in good standing with full access.

Export everything, once, as insurance. Not because you will load this copy, but because a complete export sitting on your own drive changes the shape of every subsequent conversation. Ask for it in the most open format available - CSV, Excel, a database backup, whatever the system will give you - and confirm you can open it.

Read the contract. Find the notice period, the renewal date, the termination terms, and any clause about data export: whether it is provided, in what format, at what cost, and for how long after termination. Some agreements auto-renew on a date that has nothing to do with when you started. Knowing that date is worth more than any other single item on this page.

Write down the connections. Every system that talks to your DMS is a thing that will need re-pointing. The usual list: inventory feeds to the marketplaces and your website, the email address or ADF endpoint that leads arrive at, credit application routing, book-value providers, your accounting software, your phone system, any texting tool, and any lender portal that pulls from you. Walk the store and ask. There is always one nobody remembered.

What to export

Work through these categories rather than trusting a single "export all" button.

Inventory. Every unit, not just what is on the lot. Stock number, VIN, year, make, model, trim, mileage, color, cost, pack, reconditioning spend, floor plan lender and advance, date acquired, source, current price, status, and every photo. Sold units matter too - that is your cost history.

Customers and contacts. Names, every phone number and email, addresses, co-buyers, and the flags that carry legal weight: do-not-call, do-not-text, opt-out status, and any consent record you hold. Losing an opt-out is not an inconvenience, it is a compliance failure waiting for a complaint.

Deals. Open deals first, then closed. The numbers on the worksheet, the products sold, the lender, the terms, the commission split, and the contents of the deal jacket. Anything scanned into the jacket is a file, not a row - see attachments below.

In-house notes, if you carry them. The full payment history for every active account, the schedule, the balance, every fee assessed or waived, and every arrangement recorded against the account. This is the category with the least tolerance for approximation.

Accounting. Chart of accounts, open payables and receivables, and enough closed-period history to produce a comparison. Talk to whoever prepares your statements before deciding how much history to move; they may have a firm view.

Attachments. Photos, scanned titles, signed forms, insurance certificates, license images, repair orders. These are the hardest to recreate and the easiest to forget, because they are usually not in the same export as the records they belong to.

Configuration. Your forms, templates, fee defaults, lender list, user accounts and permissions. Not data exactly, but every hour spent rebuilding these is an hour nobody planned for.

What to verify, and how

An import that "worked" is not the same as an import that is right. Verify with counts and with samples.

Counts first. How many vehicles, customers, open deals, active notes? Compare the number in the old system, the number in the export file, and the number in the new system. Three numbers that agree is a real result. Two that agree and one that does not is where you find the truncated file.

Then spot-check the hard cases. Pick, deliberately: a unit with a lot of reconditioning history, a customer with a co-buyer, a deal with several F&I products, a note with a payment arrangement and a waived fee, and a customer flagged as opted out. Open each one in the new system and compare it to the old one field by field. Easy records import cleanly everywhere; these are the ones that reveal a mapping problem.

Check the money. Total inventory cost. Total floor plan balance. Total outstanding note principal. Open receivables. If any of these do not tie out, stop and find out why before you go further.

Check the dates. Date fields are the classic silent failure: acquisition dates that reset to the import date destroy your aging, and a store that cannot see aging cannot manage a floor plan.

Check the attachments. Open a deal jacket. Confirm the documents are actually there and actually open.

What to run in parallel

Parallel running is not indecision. It is how you get a known-good comparison for the first numbers the new system produces.

Run both through at least one complete month-end, including whatever reports you send to a lender, an accountant or a partner. Enter new deals in the new system only - dual entry for daily work is how errors get created rather than caught. Keep the old system in read-only mode for lookups.

Two things deserve genuine parallel testing rather than a look-and-see. The first is your inventory feeds: publish to each marketplace from the new system, then go and look at a listing on the actual site. Photos, price and description are three separate things that can each break independently. The second is lead capture: send yourself a lead from every source - your website, each marketplace, the phone - and confirm it arrives, is attributed to the right source, and reaches the right person.

The cutover week

Freeze what you can. Ideally you stop entering new deals in the old system a day or two before the final export, so the last extract is a clean line rather than a moving target.

Take the final export. Load it. Run the verification list above again, in full, on the real data. Then flip the connections - feeds, lead routing, accounting - and test each one with a real record rather than assuming.

Tell your people what changes, in specifics: where they now enter a deal, where they look up a payment, who to ask. Most of the pain in the first week is not technical.

The one question worth asking a vendor

Ask what happens to your data if you leave them. A vendor that answers clearly - format, timing, cost, what is included - is telling you something about how they intend to keep you. So is one that does not.