Plan a domain switch without losing the details

A domain switch reaches much further than the homepage. The old address may appear in email, documents, login settings, sales messages and links that nobody on the current team remembers creating. A useful migration plan begins with that inventory. Before choosing a launch date, work out what depends on the address, who owns each dependency and how you will know the replacement works.

Separate the decision from the release

Acquiring a new domain and moving an existing business to it are separate milestones. The team can evaluate the address while continuing to operate on the current one. Once the move is agreed, appoint one coordinator and give each system a responsible owner. The coordinator tracks the plan; the system owners confirm their own settings and tests. A shared list with named people is more useful than a launch announcement that assumes everyone will notice what needs changing.

Write down the intended scope. Are you changing only the domain, or also the company name, design and content management system? Combining changes makes it harder to understand a problem after release. Google's site-move guidance recommends changing one thing at a time where possible. Use that as a reason to discuss sequencing, rather than treating every related improvement as part of the same launch.

Build the inventory from real usage

Start with the public website, then work outward. Include important pages, downloads, images, campaign links, forms and the destinations used in automated messages. Ask sales and support teams for examples of links they actually send. Review standard proposals, help documents, calendar invitations and signatures. The purpose is to uncover the places where a customer could encounter the old address after the new site is live.

For each item, record the current address, intended replacement, owner, test and status. Add a column for whether the old item must keep working. A downloadable guide linked from a long-running campaign may need attention even if it is absent from the main navigation. A list generated only from the visible menu will miss that kind of dependency.

Include systems that use the domain as configuration rather than as a visible link. Examples may include authentication providers, webhook destinations, application callbacks and allowed origins. Have the owner of each system check its current documentation. Do not assume that changing the website's address automatically updates services connected to it.

Map pages to the right destinations

A migration map connects an old URL with the new page that serves the same purpose. Keep the mapping specific enough to preserve useful destinations. Someone following a link to a setup guide should reach the relevant guide, not be dropped at a generic homepage with no explanation. Where content is intentionally removed, decide what response is appropriate and document that decision.

For a simple example, a company might move its pricing page, three product pages and a documentation section. The mapping should cover those exact routes and the deeper documentation links that customers use. Test a selection of real old links, including ones with query parameters. Record the expected destination so a reviewer can check the result without guessing what the migration was meant to do.

The search-related mechanics should be implemented against current guidance. Google's documentation describes preparing URL mappings, configuring redirects and monitoring the move. It also advises updating internal links and canonical references. Those are specific tasks for the website owner, with verification evidence attached to the checklist. They should not be reduced to one ambiguous item labeled “SEO done.”

Treat email as its own workstream

List the mailboxes, aliases, sending services and support tools that use the old domain. Ask the person responsible for email to plan the new addresses and the period during which old addresses should continue receiving messages. Website hosting and email delivery are different systems. A successful page load is not evidence that mail is configured correctly.

The email owner should consult the documentation for the actual providers in use, preserve the required records and run controlled send-and-receive tests. Include messages from any system that sends on behalf of the business, such as support software or transactional applications. Avoid using a migration checklist from an unrelated provider as a substitute for inspecting the current setup.

Agree how employees will learn the new address format and when signatures should change. If customers need an announcement, prepare it with a clear reason and a recognizable sender. Keep a record of the approved wording and audience. An address transition is easier to understand when the website, support team and customer-facing messages tell the same story.

Rehearse the customer journeys

Choose a few journeys that matter to the business and test them from beginning to end. A prospect might open an old campaign link, read a product page and submit an inquiry. A customer might follow a help link from an email and sign in. A partner might download a file from a saved proposal. These journeys expose gaps that checking the homepage alone will not find.

Write the expected result before running each test. Record the device or browser used, the date and any failure. If a form reports success, verify the downstream record or message through the appropriate system. If a login completes, check that it returns to the intended page. A visible confirmation screen can be only one step in a longer workflow.

Use a rehearsal environment where possible, while recognizing that some behavior depends on the final domain and its live configuration. List those checks separately for release day. The team should know which evidence is available before launch and which evidence still needs to be collected afterward. That distinction prevents a rehearsal result from becoming an unsupported claim about production.

Prepare a release and recovery plan

Choose a release window when the people needed for verification can be available. Put the order of changes in writing, including who performs each action and who checks it. Preserve the information needed to restore a previous configuration if a material problem appears. The recovery plan should identify which changes are reversible and which require a different response.

Avoid making recovery dependent on one person's memory. Store configuration references securely and keep secrets out of the general checklist. Decide what would justify pausing the rollout. For example, a broken core customer journey should receive a different response from a minor wording defect. Agreeing those distinctions before launch reduces pressure to improvise while customers are encountering the change.

Keep watching after the announcement

After release, revisit the inventory and check the paths that could not be fully tested earlier. Monitor the systems your team actually uses for errors, customer messages and website performance. Google notes that search visibility may fluctuate while a move is processed; do not promise a fixed recovery date from a generic checklist. The search owner should use the relevant reporting tools and current documentation to assess that part of the move.

Keep responsibility for old links and addresses assigned after launch week. Some may remain in printed materials, third-party sites or saved messages for a long time. A migration is easier to maintain when those obligations have owners and review dates. The next useful action is to create the inventory now, starting with ten links or systems the business depends on every day.