Switching From Tekion: A DMS Migration Guide

A platform conversion is a project, not a purchase. The stores that come through it cleanly decide the hard things before they give notice.

Because Tekion is sold as one platform covering several categories, leaving it is rarely a single decision. Write down exactly which parts you are replacing before you talk to anybody, because the answer changes the size of the project by an order of magnitude.

Replacing the accounting and operations core is a full dealer management system conversion. That is the largest software project a store undertakes, it involves your controller, your parts department, your service drive and your entire back office, and it does not happen in six weeks.

Replacing only the sales side, meaning the CRM, lead handling, communication and follow up layer, is a much smaller project. It touches your sales floor and your BDC, it can run in parallel with almost no risk to accounting, and it can be done in a fraction of the time.

Stores conflate these constantly, usually because the frustration originated on the sales floor and the conversation escalated into a platform replacement nobody actually needed. Ask the question honestly: if the lead and follow up layer were fixed tomorrow, would you still be having this conversation? If the answer is no, you have a much easier project than you think. Our Tekion alternative page covers that narrower path.

This is the single most important paragraph on the page. Your leverage over any vendor is at its maximum before you sign and at its minimum after you have given notice, and the data conversation is where that asymmetry costs stores real money.

Get answers in writing, from the vendor you are leaving, before you tell them you are leaving. What exactly can you export. In what format. Does it include customer records, deal history, service history, accounting detail and communication history, or only a subset. Is there a fee. How long do they retain your data after termination and what is the process to request it later. Who at the vendor is accountable for producing it.

Then ask the same questions of whoever you are moving to, from the other direction: what can they import, in what format, and what happens to the fields that do not map cleanly.

Assume some history does not come with you. Almost none ever does completely. Decide deliberately what you will carry, what you will archive as flat files you can search later, and what you will simply leave behind. Our page on DMS data ownership covers the contractual side, and migrating historical records covers the practical one.

The order matters more than the calendar. This sequence has the fewest surprises.

1. Requirements per department. Not a feature list. A list of the specific tasks each department does daily and what the new system has to do for each one.
2. Vendor evaluation against those requirements, with department heads present, not just the GM and the controller.
3. Data audit and cleanup in the current system. Migrating a decade of duplicate customer records reproduces the mess in a system you are paying to be better.
4. Contract, including the exit terms of the new agreement. Negotiate your future exit while you are being courted.
5. Configuration and test migration. Move a data sample and have the people who use it check it, not the vendor.
6. Training, department by department, before cutover.
7. Parallel run.
8. Cutover, then a stabilization period with the old system still readable.

Skipping step three is the most common shortcut and it is the one that produces a new system everyone distrusts within a month. Skipping step five is the one that produces a cutover weekend nobody sleeps through. Our data cleanup guide covers the audit.

A conversion judged only by whether accounting balances will fail three other departments. Each one needs its own acceptance criteria and its own owner.

Name a person per row who has authority to say the row is not ready. Then agree in advance that any single row failing delays the cutover. Stores that leave this ambiguous discover on the Monday after go live that the service department was never asked, and by then the decision has been made for everybody.

We publish separate checklists per department for exactly this reason, including the sales department checklist and the service department checklist.

Most stores think of the cutover date as the risky moment. It is not. The risky moment is the two weeks after, when something does not work and there is no way back.

A parallel run means both systems are live for a defined period with a defined scope. It is expensive, it is annoying, and it is the difference between a bad week and a bad quarter. Scope it deliberately rather than trying to run everything twice, which no store has the staffing to do honestly.

What is usually worth running in parallel: the accounting close for one full month, so you can prove the numbers match before you trust them. Repair order flow for a week or two. Deal writing for a couple of weeks with a small sample compared line by line.

What is usually not worth it: duplicating every customer interaction, which produces exhausted staff and worse data in both systems.

Set the end date in advance and hold it. Parallel runs that drift produce a store where nobody knows which system is authoritative, and that is worse than either system alone. Our parallel run guide covers scoping it, and the cutover checklist covers the weekend itself.

The failures are boringly consistent across conversions, and none of them are exotic.

Training happened too early. Staff trained six weeks before go live have forgotten most of it. Train close to cutover and repeat after, when people have real questions instead of hypothetical ones.

Nobody owned the third party integrations. Every service that posts into or reads from the platform has to be repointed: website, lead providers, chat, phone, payment, marketing tools. Build the inventory of them early, because it is always longer than anyone expects.

The pay plans were not considered. If reporting changes shape, commission calculations change with it, and a salesperson who thinks the new system cost them money will never adopt it. Work this out before cutover, not after the first pay period.

The old system got switched off too early. Keep read access for as long as you can negotiate. You will need it, usually for something nobody anticipated.

Go live scheduled at month end. Do not. Pick the quietest week you have, never the last week of a month or a quarter. Our page on hidden costs of switching covers the budget side of these.

Here is the practical point that gets missed, and it is the one place we have something useful to offer during a conversion.

A platform change consumes management attention for months. During that period, lead response times slip, follow up gets thin, and the store loses deals it would otherwise have made. Nobody notices because everyone is focused on whether the schedules balance.

You can insulate the sales side by moving it off the platform being converted, either before or during. A CRM and lead layer that does not depend on the dealer management system you run keeps working regardless of what the back office is doing on any given week. LeadLocate is deliberately built that way: no DMS integration and no inventory feed are required to operate, which means a conversion in accounting does not put your lead flow at risk.

Doing that first also shrinks the main project, because the CRM requirements come off the DMS evaluation and one fewer department has to accept the new system on day one.

The reverse also works: keep the sales layer stable through the conversion, then evaluate whether you want to consolidate it back afterward once the dust has settled. Either way, the goal is that a bad conversion week does not become a bad sales month.

Vendors quote implementation. Stores experience conversion, which is longer. Plan against the second.

For a full platform replacement covering accounting and operations, most single rooftop stores should expect several months from decision to a stable go live, and a further month or two before the organization stops feeling it. Groups take longer, and rolling stores in waves rather than all at once is almost always the right call.

For a CRM and lead layer change alone, the timeline is dramatically shorter, because there is far less to configure and the acceptance criteria involve one or two departments rather than five. Weeks rather than months is realistic, and the constraint is your team's adoption rather than the setup itself.

Whatever the scope, add contingency to the vendor's estimate rather than accepting it. Not because vendors are dishonest, but because their estimate covers their work and yours covers your store's, and the store's work is the part that expands. Our conversion timeline page breaks this down phase by phase, and the migration checklist is the working document.

To be unambiguous after a page of migration advice: we do not sell a dealer management system and we cannot convert your accounting. We have no general ledger, no payroll, no parts, no repair orders and no title work. If you need a different DMS, evaluate DMS vendors on their merits and use this page as preparation for those conversations.

What we do sell is the lead, CRM, communication and desking layer that runs alongside whatever system your back office uses. That includes exclusive local leads in a territory you choose, lead distribution with rules and full history, SMS and MMS with RCS and SMS fallback, a click to call dialer with a VoIP softphone, call recording with transcription, voicemail drop, email with a real inbox, automations and follow up processes, appointments and reminders, desking across loan and lease with a fifty state tax matrix, lead pages, customer facing deal pages, and three layers of reporting.

CRM Only starts at $199 a month and plans including exclusive local leads start at $799, all month to month with no long term contract. Current figures are on the pricing page. We cannot guarantee results and we are not going to tell you a conversion will be painless, because it will not be. What we can do is keep one part of the store steady while the rest of it changes. Contact us if you want to talk it through before you commit to anything.

Do we have to replace the whole platform to fix the sales side?

Usually not. Replacing the CRM, lead and follow up layer is a much smaller project than a full conversion, it can run alongside your existing system, and it takes weeks rather than months. Ask whether you would still be switching if that layer were fixed.

When should we ask about getting our data out?

Before you give notice, in writing. Your leverage is highest before the vendor knows you are leaving. Ask what can be exported, in what format, whether communication history is included, whether there is a fee, and how long data is retained after termination.

How long should a parallel run last?

Long enough to close one full month in accounting and to compare a sample of deals and repair orders line by line, with an end date set in advance and held. Parallel runs that drift leave nobody sure which system is authoritative.

When should we schedule go live?

The quietest week you have, and never the last week of a month or quarter. Train close to the cutover rather than weeks ahead, and keep read access to the old system for as long as you can negotiate.

Is LeadLocate a dealer management system?

No. There is no general ledger, payroll, bank reconciliation, deal posting to accounting, parts, repair orders or title work. We provide the lead, CRM, communication and desking layer that sits alongside whichever DMS you run.

Can we use LeadLocate during a conversion?

Yes, and that is often the point. No DMS integration or inventory feed is required to operate, so lead flow and follow up keep running regardless of what the back office is doing that week. Month to month, no long term contract.

See the lead and CRM layer running independently of your back office, with your own territory mapped. Month to month, no long term contract.