DMS Implementation Plan for Car Dealerships

A checklist tells you what to do. A plan tells you who decides, in what order, and what has to be true before you move to the next phase.

Most stores start a conversion with a task list from the vendor. A task list is useful and it is not a plan. It tells you what has to happen without telling you who decides, what has to be finished before the next thing starts, or what evidence proves a phase is genuinely done rather than mostly done.

The difference shows up around week eight. Somebody asks whether the chart of accounts mapping is final, three people give different answers, and two weeks of configuration work turns out to have been built on a draft. Nobody was lazy. There was simply no gate that said mapping is closed and here is who closed it.

So a plan needs four things a checklist does not have: named owners with actual authority, phases with entry and exit criteria, decision gates where somebody signs off in writing, and a date that everything works backward from. If you want the itemized task view alongside this, our migration checklist covers the seven workstreams item by item, and this page covers how to run them.

One disclosure before you weigh any of it. LeadLocate is not a dealer management system. We do not do general ledger, payables, receivables, payroll, bank reconciliation, deal posting to accounting, parts, repair orders, service scheduling, technician time, warranty claims or title and registration work, and we do not perform back office conversions. We sell lead generation and a CRM that runs alongside whatever system your store uses. This page exists because our customers go through these projects and ask.

Write down four roles and put real names against them on day one. Ambiguity here is the most expensive thing in the whole project because it is invisible until it costs you two weeks.

The executive sponsor is the dealer principal or general manager. They do not attend working sessions. They exist to break ties, approve spending outside the budget, and tell a department head that a decision has been made. Without one, every disagreement escalates to a meeting that gets scheduled for next week.

The project owner runs the thing day to day and has authority to decide, not just to coordinate. In a single rooftop this is often the controller or office manager. Give them protected time. A project owner doing this on top of a full workload is how a six month project becomes a ten month project.

Workstream leads own accounting, sales and F and I, parts, service, and integrations. One person each, and they own their data validation. They are also the people who sign the gate documents, which is what makes the sign off mean something.

The vendor project manager is not your project manager, and treating them as one is a common and painful mistake. They manage the vendor's obligations. Your side needs its own.

Set a standing weekly meeting with a fixed agenda: gate status, open decisions with owners and due dates, risks that changed, and blockers. Thirty minutes, same time, no exceptions. The discipline matters more than the format.

Work backward from your go live date. This shape suits a single rooftop; a group needs longer and usually a pilot store first. Adjust the durations, keep the gates.

Total is realistically three to six months for one rooftop. Anyone promising six weeks is moving the work rather than removing it, and the store pays for it in phase six. The conversion timeline page breaks the calendar down week by week.

Discovery is where you decide what the new system will look like, and the temptation to redesign everything at once is strong and should be resisted.

The single biggest decision is the chart of accounts. Map it field by field, and resist rebuilding it during the conversion. Two large changes at once means every reconciliation difference has two possible causes and finding out which takes twice as long. Redesign it six months after you are stable, when you can tell a mapping problem from a design problem.

The second is data scope, which is really a budget decision dressed as a technical one. Decide what migrates as live detail, what migrates as balances only, and what stays in the old system behind read only access. Most stores take balances plus a limited period of detail, and buy twelve to twenty four months of lookup access from the incumbent. That is usually much cheaper than converting years of history you will look at four times.

The third is the integration inventory. Walk the building and ask every department what software touches their day, then write down who owns each connection, the lead time to repoint it, the cost, and who to call when it breaks. Get written confirmation from each third party that they support the new platform, with a date. Discovering in cutover week that your inventory syndication vendor needs three weeks of notice is a self inflicted wound.

Close the phase with a written design document signed by the workstream leads. That signature is the gate.

Treat data as three separate passes and schedule them as such, because a single heroic load at the end is how conversions fail publicly.

Pass one is cleanup in the old system. Deduplicate customers, correct phone and email data, resolve inventory discrepancies, take a physical parts inventory, and reconcile every accounting schedule. Whatever is wrong today becomes permanent on the day it loads, and duplicates multiply during a conversion rather than disappear. This is the highest return work in the entire project and it is also the least interesting, which is why it gets skipped.

Pass two is a test load with reconciliation. Not a look at the screen. Total inventory value to the penny, parts inventory value, receivable and payable balances, and record counts by type. Write the differences down, find the cause of each, and fix the mapping rather than the symptom.

Pass three is a second test load proving the fixes held and nothing else broke. Stores that do two test loads have a quiet cutover. Stores that do one have a story they tell for years.

If your incumbent's extract arrives as undocumented fixed width files, budget for help rather than for heroics. Data migration services covers what that work involves and when it is worth buying.

Configuration testing goes wrong when it is done with clean example transactions. The rule that fixes it is simple: test against real work your store already completed, where you know what the right answer is.

Pull ten recent deals across the range you actually write: a retail loan, a lease, a cash deal, one with a trade and negative equity, one with a rebate, and one from a state or county with unusual tax treatment if you sell across a line. Rebuild each in the new system and compare every figure. A difference of eleven dollars is not a rounding problem, it is a configuration problem that would have appeared on every deal for a month.

Do the same in fixed ops. A warranty job, a customer pay job, an internal, and specifically a multi line repair order that splits across pay types, because that is the transaction that breaks first. Print the actual documents on the actual printers in the actual offices. Buyer's order alignment is a stupid problem to discover at 10am on your first Monday with four salespeople standing around.

Keep a stable reference for payments while the back end is unsettled. Our desking engine covers loan and lease with a fifty state tax matrix, semimonthly frequency, trade credit caps and three lease tax methods, and it runs with no dealer management system connection at all, which is why stores use the desking tool as a second opinion during exactly this phase.

Training scheduled two months before go live is a waste of money because nobody remembers it. Put it in the last two to three weeks, deliberately.

Train by role and by task rather than by module. An advisor needs to write a repair order, look up a part, and explain a charge to a customer. They do not need a tour of the service module. Build the curriculum from the ten things each role does most often and drill those until they are boring.

Train champions first and give them extra depth. Every department needs somebody on the floor who can answer a question at 4pm on a Saturday without calling the vendor, and champions carry more of the load in week one than the vendor's support line does.

Then plan for the dip honestly. Two to four weeks of reduced productivity is normal, and a store that budgets for it manages better than one that pretends otherwise. Reduce the schedule around go live. Do not launch a sale that week, do not run a manufacturer event, and do not put your newest hire on the phones. The training plan covers curriculum by role.

Cutover deserves its own document and gets one: the cutover checklist covers the weekend hour by hour. What belongs in the plan is the decision framework around it.

Write go or no go criteria two weeks out, before anyone is emotionally invested in the date. Something like: both test loads reconciled, all critical integrations confirmed working, every role trained, printers verified, and the vendor's support commitment for go live week confirmed in writing. If a criterion fails, you delay. Deciding that in advance is what makes the delay possible, because in the week itself the pressure to go anyway is enormous and usually wrong.

Plan the first thirty days as an actual phase rather than as a return to normal. Daily fifteen minute stand ups in week one. A single visible issue list with owners and severities rather than a group chat. A named person watching accounting daily rather than at month end. And treat closing the first month on the new system as a rehearsed milestone with an owner, because that close is the real proof the conversion worked.

Where practical, run parallel for one accounting cycle. It costs real workload and it is nearly always worth it, because a mapping error found while an authoritative system still exists is an inconvenience rather than an investigation. Parallel running covers how to do it without doubling everyone's day.

Keep a short risk register with an owner and a mitigation for each. Five entries that get reviewed weekly beat thirty that get reviewed never.

The recurring five are: the incumbent's extract arriving late or unusable; the chart of accounts mapping reopening after it was closed; a third party integration nobody remembered until cutover week; the project owner having no protected time; and key staff leaving mid project, which happens more than vendors admit during periods of change.

Budget the same way. The license fee is the smallest number. Add implementation and data conversion fees, the parallel period, overtime, integration setup and any deconversion fee from the incumbent, then the unbilled cost of the productivity dip. Total cost of ownership works through the full arithmetic over three to five years.

Last, protect the selling side. Whatever is happening in the back office, customers still have to be answered within minutes. Keep the lead and communication layer stable and independent: distribution rules assigning leads, SMS and MMS threading on the customer record, automations and follow up processes firing, IVR and call routing catching inbound calls, voicemail drop working the list, and reporting still telling you who is doing the work. None of that requires a dealer management system connection or an inventory feed, which is one fewer moving part in a project with too many. Pricing is published rather than quoted, everything is month to month, and you can contact us at 844-376-2274 if you want to know exactly what stays stable while the rest of the building changes.

How long should we plan for a dealer management system implementation?

Three to six months from signature to a stable go live for a single rooftop, and longer for a group that should pilot one store first. The variables are data condition, accounting complexity and integration count rather than software installation.

Who should own the project inside the store?

One named person with authority to decide, usually the controller or office manager in a single rooftop, with protected time. The vendor's project manager manages the vendor's obligations and is not a substitute for your own owner.

What are decision gates and why do they matter?

A gate is a point where somebody signs off in writing that a phase is closed, such as chart of accounts mapping being final. Without gates, configuration gets built on drafts and the rework surfaces around week eight.

Does LeadLocate implement dealer management systems?

No. We are not a dealer management system and we do not perform back office conversions. Our role during one is keeping leads, texting, calling, follow up and reporting running while the back end changes, since none of it requires a connection to that system.

How many test data loads should we run?

At least two. The first finds mapping problems, the second proves the fixes held and nothing else broke. Reconcile balances and record counts after each rather than reviewing on screen.

Should we redesign our chart of accounts during the conversion?

No. Map it as it is, get stable, then redesign six months later. Two large changes at once means every reconciliation difference has two possible causes and diagnosis takes twice as long.

Leads, texting, calling and follow up keep running with no connection to the system you are replacing. Month to month, no long term contract.