Industries

A practical runbook for replacing a DealerCenter website

Replacing a dealership website is a handoff between systems, people, and customer journeys. The design matters, but the harder questions concern continuity: where inventory comes from, which addresses shoppers already use, who receives inquiries, and who controls the accounts needed to launch. A migration runbook makes those dependencies visible before a dealership commits to a replacement platform or agrees to a launch date.

If search work is part of the scope, our website rule applies. We only do SEO on a site we built.

Define what is moving before choosing the replacement

A request to replace DealerCenter website functionality should begin with a boundary document. Identify whether the proposed change covers only the public website or also changes inventory management, third-party integrations, communication tools, and other connected services. Do not assume that replacing the website requires replacing every operational system. Equally, do not assume that an existing connection will remain available simply because the dealership wants to retain it.

The first useful deliverable is a dependency map. List each website feature, its source of information, its account owner, and its destination. For example, a vehicle inquiry may depend on an inventory identifier, a form service, a notification address, and a customer management destination. That chain needs an explicit replacement plan. A screenshot of the current form is insufficient because it does not show what happens after submission.

Make access and ownership a launch prerequisite

Record who can access domain registration, DNS, website administration, inventory exports, analytics, and any connected lead services. Distinguish possession of a login from authority to change a service. The runbook should identify the person responsible for each approval and any notice or cancellation terms that need review. If access is missing, resolve it during discovery rather than treating it as a task for the afternoon of launch.

Give inventory its own migration track

Inventory is changing business data, not a folder of pages to copy once. Establish the intended source of truth and confirm how the replacement website will receive updates. Request the actual feed specification or a representative export. Review available fields, photo references, vehicle identifiers, availability states, and update behavior. Any proposed integration should be assessed against those observed inputs rather than an assumption that all dealership feeds share the same structure.

Use a field map to describe how source information becomes a shopper-facing listing. A source may distinguish sale price, another price field, and text describing financing. The replacement should not collapse those into an ambiguous number without dealership review. Likewise, missing mileage or an absent photo should have an intentional display rule. Exceptions belong in the specification because they are precisely where a seemingly complete import can produce a confusing vehicle page.

• Select representative records that include complete listings, missing optional fields, multiple photos, and changes in availability.
• Document what creates, updates, hides, or removes a vehicle on the replacement website.
• Assign responsibility for investigating stale information and specify how a suspected mismatch will be checked against the source.

Test changes, not just the first import

A successful initial import does not establish that the ongoing connection behaves correctly. The acceptance plan should include a price edit, a photo change, and a vehicle leaving the available stock. These can be checked in a staging environment or through an agreed controlled process. Record the expected behavior before running each check so that approval means the system followed a defined rule, rather than merely displaying something plausible.

Map existing addresses to useful destinations

Build a URL inventory from the sources available to the dealership, including a crawl, sitemaps, and relevant account exports where access permits. Group addresses by purpose: inventory browsing, individual vehicles, contact information, trade-in information, and editorial content. Then decide which addresses can remain the same, which need a direct replacement, and which need a considered retirement path. This is a content and customer-experience decision as well as a technical task.

Avoid using the homepage as a universal destination for retired pages. A shopper following an old vehicle link needs a relevant next step, but a sold vehicle and a discontinued service page present different problems. Define destination rules by page type and check that the destination actually answers the likely need. Redirects should support continuity; they are not a promise that search visibility or traffic will remain unchanged.

Trace every inquiry through to its recipient

List each conversion path separately, including general contact, vehicle inquiries, and any other forms included in the agreed scope. For each path, specify the required fields, destination, confirmation message, and failure behavior. A vehicle inquiry should preserve enough listing context for the recipient to understand the question. A generic notification that omits the vehicle can create extra follow-up even when the form technically submits.

Use clearly labeled test submissions and confirm receipt with the intended destination. Check the shopper-facing confirmation and the internal record independently. If information travels through several services, identify which system provides the authoritative record of receipt. Collection notices, consent language, retention choices, and any specialty forms should be reviewed against current requirements with qualified counsel where appropriate before implementation.

Turn launch day into an execution checklist

The cutover document should name an owner, sequence the changes, and establish conditions for proceeding. Complete staging approval before changing public routing. Confirm that the replacement can serve the intended domain securely, that the latest inventory is available, and that redirects and inquiry destinations have been checked. Keep a record of relevant existing settings so that a troubleshooting decision is based on known values rather than memory.

Set rollback conditions before they are needed

Rollback is a defined response to an unacceptable launch issue, not a vague assurance that everything can be undone. Specify which failures would pause the launch, who makes that decision, and what reversal remains possible under the service arrangements. DNS changes, data updates, and cancellation of an old service are different actions. The runbook should account for their separate dependencies and should not promise an instantaneous reversal.

After cutover, repeat the essential checks on the public domain: inventory browsing, individual listings, image loading, navigation, redirects, and inquiry receipt. Review measurement configuration separately from operational functionality. A website can accept inquiries while recording events incorrectly, or record an event while an inquiry fails downstream. Keep the previous service available for the agreed verification period when the commercial and technical arrangements allow it.

Compare proposals by the handoff they define

Ask prospective partners to make responsibilities concrete. A useful migration proposal identifies required access, integration assumptions, exclusions, acceptance checks, launch ownership, and post-launch support boundaries. It should also explain what the dealership receives at handoff, including account access and integration documentation. This makes the buying decision more specific than comparing page designs: the dealership can judge whether the proposed process addresses the systems on which its website actually depends.