Parallel Run Strategy for a DMS Conversion

Running two systems at once is expensive insurance. Here is how to buy the right amount of it instead of all of it.

A parallel run is the practice of keeping the outgoing system operational alongside the incoming one for a defined period, so the store can compare outputs and fall back if the new system is wrong. It comes from the accounting world, where you close a month on both sets of books and prove they agree before trusting the new one.

In a dealership the phrase gets used loosely, and that looseness causes most of the confusion. Some vendors mean full dual entry, where every transaction is posted twice. Some mean read only access to the old system for history lookups. Some mean a phased conversion where different departments move on different dates. Those are wildly different projects with different costs, and if you and your vendor are using the same word for different things, you will discover it during the worst week of the year.

So before anything else, get the definition in writing. Ask exactly which systems stay live, which transactions get entered where, who is responsible for the double entry, how long it runs, and what specifically has to be true before the old system goes dark. That paragraph, agreed in advance, is worth more than any project plan.

One note on scope. LeadLocate is not a dealer management system and does not sell one. This page is buyer education for a decision you are making with a DMS vendor. Where we come into it is at the end, because the lead and sales layer should not be part of this project at all.

In theory you run both, compare, and switch. In practice a dealership has properties that make full parallel operation close to impossible, and it is better to know that before you promise it to the dealer principal.

The first problem is the outside world. Your DMS is connected to things you do not control. Manufacturer reporting, floorplan providers, banks, parts ordering, credit bureaus, service scheduling, your website and lead providers. Most of those connections cannot be pointed at two systems at once. You get one live endpoint, and the moment you switch it, one of your two systems is no longer telling the truth.

The second problem is people. Full parallel means every repair order, every parts ticket and every deal is entered twice, by the same staff, during a period when they are also learning new software. The realistic outcome is that entry gets sloppy in one system, usually the old one, and by week two your comparison is meaningless because the data diverged for human reasons rather than software ones.

The third problem is timing. A deal posted in one system on Thursday and the other on Monday will not reconcile, and you will spend a day proving that a difference is a timing difference rather than a defect. Multiply that by a hundred transactions.

None of this means parallel running is a bad idea. It means the scope has to be narrow enough to actually execute. Our conversion timeline guide shows where this fits in the wider project.

Pick one deliberately rather than drifting into whichever one the pressure of the moment produces.

Full parallel. Everything entered twice, both systems live, for one or two full month ends. Highest confidence and highest cost. Realistic only for large groups with dedicated project staff, and even then usually scoped to accounting rather than the whole store.

Accounting only parallel. The common one. Operations move to the new system on cutover day, and the accounting office closes one or two months in both, proving the financial statement, the schedules and the reconciliations agree. This buys most of the protection at a fraction of the cost, because the accounting office is where an undetected error compounds quietly.

Read only legacy. The old system stays available for lookups but nothing new is entered in it. Cheap, and it solves the real day to day problem, which is a service advisor needing a repair order from fourteen months ago. It proves nothing about the new system, so it is a history strategy rather than a verification strategy.

Phased by department. Sales moves one month, service and parts the next, accounting last, or some other order. Reduces the size of any single failure and stretches the pain over a longer period. Works best when departments are genuinely separable in your workflow, which is less often than it sounds.

Most stores that succeed use accounting only parallel plus read only legacy access. That combination covers the two things that actually hurt: a wrong financial statement, and a customer conversation you cannot answer because the history is gone.

Budget the whole thing before you commit to a model, because the subscription overlap is the smallest number in it.

1. Two subscriptions. You will pay both vendors for the overlap period. Negotiate this before you sign the new agreement, not after, because your leverage disappears the moment the ink is dry.
2. Termination timing on the old contract. Many DMS agreements carry long notice requirements and auto renewal. Find out your notice date before you set a go live date, or you will pay for a year of a system nobody uses. Our contract exit page covers this.
3. Labor. Double entry is real hours from people who already have jobs. Estimate honestly and then add half again. If you are running accounting only parallel, that is your office manager and controller working extended hours through two month ends.
4. Overtime and temporary help. Plan it rather than discovering it. A store that refuses to fund temporary help during a conversion pays for it anyway in errors.
5. Productivity. Expect a dip for two to four weeks after cutover regardless of preparation. Service throughput drops, deals take longer, and everyone is slower. This is normal and it is not a sign the project failed.
6. Morale. Not a line item, but the one that decides whether the project succeeds. A conversion run badly costs you good people. Training planning is the cheapest insurance available.

The hidden costs page goes through the full list, including the ones that show up in month three.

The most common failure is not running parallel too briefly. It is running it indefinitely because nobody defined the finish line, and a store six months into a parallel run has two half maintained systems and no confidence in either.

Set exit criteria in writing before you start. They should be specific enough to be checked off by someone other than the person who wrote them. A reasonable set for an accounting parallel run looks like this: two consecutive month ends closed in the new system with the financial statement agreeing to the old within an agreed tolerance, all schedules reconciled, factory reporting submitted and accepted from the new system, floorplan and bank reconciliations completed cleanly, and payroll processed correctly at least once.

For operations, the criteria are different and more behavioral. Service advisors writing repair orders without needing help. Parts counter transacting at normal speed. Deals posting without escalation for a full week. F and I paperwork producing correctly on every lender form you use.

Then hold to it. When the criteria are met, shut the old system down on a scheduled date and announce it in advance. Leaving it available as a comfort blanket guarantees somebody keeps using it and your data stays split. Archive first, verify the archive opens, then turn it off. Historical record migration covers what to preserve and how.

A parallel run only means something if somebody actually compares the two outputs, on a schedule, with a written result. Otherwise you have paid for two systems and gained nothing.

Decide up front what tolerance is acceptable and who signs off. Penny perfect agreement on every account is not realistic across two systems with different posting conventions, and chasing it will exhaust your controller. A defined tolerance with a documented explanation for each variance is the workable standard.

The comparisons worth running every cycle are the financial statement by account, the vehicle inventory schedule unit by unit, the receivable and payable schedules, floorplan balances against the lender's own statement, and the parts inventory value. Every variance gets a written reason. Timing difference, posting convention difference, or defect. Only the third category is a problem, but you cannot tell which is which without doing the work.

Keep the record. A file showing that month one had eleven variances and month two had two is the evidence that lets you confidently switch off. A vague feeling that it seems fine is how stores discover in April that the December numbers were wrong.

If your data was messy going in, expect more variances and do not blame the new system for them. Cleaning before you convert is far cheaper than reconciling after, which is why pre migration data cleanup belongs before this phase rather than during it.

Each department experiences a parallel run differently, and the plan should reflect that rather than treating the store as one unit.

Accounting. The department where parallel running earns its cost. An undetected error here compounds silently for months. This is where the double close happens and where your controller needs real support. See the controller checklist.

Parts. The hardest inventory to convert because value, bin locations, supersessions and special orders all have to land correctly, and a wrong count is discovered at the counter with a customer standing there. Physical inventory before cutover is the standard advice for a reason. The parts department checklist is written for this.

Service. Open repair orders spanning the cutover are the pain point. Decide the policy in advance: close everything possible before the date, and handle the rest by a documented rule rather than by whoever is on shift. Advisors also need history lookups constantly, which is why read only legacy access matters most here. See the service checklist.

Sales and F and I. Deals in process across the cutover, lender forms, and tax setup are the risks. Verify form printing on every lender you use before go live, not after. The F and I checklist covers the paperwork side.

Here is the part most conversion plans get wrong, and it is the reason this page exists on our site.

A DMS conversion is an operations and accounting project. Your lead flow, your follow up, your texting and your appointment book have nothing to do with it, and there is no good reason for them to go down while the parts department is counting bins. Yet stores routinely let the conversion swallow the sales process, and then lose a month of pipeline they never get back.

The way to prevent it is structural. Keep the lead and communication layer in a system that does not depend on the DMS at all. LeadLocate is deliberately built that way. Neither a DMS connection nor an inventory feed is required to operate, which means a conversion changes nothing about where your leads land, who owns them, or whether follow up runs. Your salespeople keep texting, the automations keep firing, appointments keep getting set, and desking keeps working with its own fifty state tax matrix regardless of what the accounting office is doing that week.

To be clear about what we are and are not: we are not a dealer management system. No general ledger, accounts payable or receivable, payroll, deal posting to accounting, parts, repair orders, service scheduling or title work. We are the lead, communication and desking layer that sits beside whatever system your store runs.

The practical instruction is simple. Do not schedule a CRM change and a DMS conversion in the same quarter. Pick one. If both are genuinely needed, do the CRM first, because it is smaller, it is reversible, and it gives your sales floor stable ground to stand on while the harder project runs. Running two CRMs during a migration covers that smaller version of the same idea.

Pulling it together into something a general manager can hand to a project owner.

Six to eight weeks out, confirm your old contract notice date, agree the parallel model in writing with both vendors, and name one person accountable for the whole conversion. Not a committee. One name.

Four weeks out, clean the data, run a test conversion into the new system and have each department look at their own records. Take a physical parts inventory. Write the open repair order policy. Verify lender form printing.

Two weeks out, train, then train again on the actual store data rather than a demo set. Publish the cutover day plan hour by hour, including who to call when something breaks.

Cutover, then close the first month in both systems and reconcile with written variance explanations. Close the second month the same way. When your exit criteria are met, announce a shutdown date for the old system, archive, verify the archive opens, and turn it off.

Throughout, leave the sales floor alone. If your lead layer is independent of the DMS, that is a decision you already made and it pays for itself in exactly this month. If it is not, this is the argument for changing that before the next conversion rather than during it. Call 844-376-2274 or use contact us if you want to talk through the sequencing with someone who has watched this go both ways.

Is a full parallel run realistic for a dealership?

Rarely. External connections to manufacturers, floorplan, banks and lead providers usually only support one live endpoint, and double entry across a whole store degrades within two weeks. Most successful conversions use accounting only parallel plus read only access to the old system for history.

How long should a parallel run last?

Long enough to close two consecutive month ends and reconcile them, which usually means six to ten weeks. What matters more than duration is written exit criteria agreed before you start, so somebody can check them off rather than debating whether it feels ready.

What should we compare during the parallel period?

Financial statement by account, the vehicle inventory schedule unit by unit, receivable and payable schedules, floorplan balances against the lender statement, and parts inventory value. Every variance gets a written reason: timing, posting convention, or defect. Only the third is a problem.

Does LeadLocate provide a DMS or help with the conversion itself?

No. We are not a dealer management system and we do not convert one. This is buyer education. Where we fit is keeping your lead flow, follow up and desking running on a system that does not depend on the DMS, so the sales floor is not part of the project.

Should we change our CRM at the same time?

No. Pick one project per quarter. If both are needed, do the CRM first because it is smaller and reversible, and it gives your sales team stable ground while the harder conversion runs. Doing both at once is how stores lose a quarter of pipeline.

When is it safe to shut the old system off?

When the written exit criteria are met, the archive has been created and verified as openable, and a shutdown date has been announced in advance. Leaving it available indefinitely guarantees somebody keeps using it and your data stays split across two systems.

Leads, follow up, texting and desking on a platform that needs no DMS connection to work. Month to month, no long term contract, and it does not care what your accounting office is doing this week.