Replacing a business website? Plan the handoff before launch.

Inventory what the current website already does

Start with the live site rather than the new design. List its public pages, downloadable files, enquiry forms, booking links, analytics or verification records, and any pages customers reach from ads, profiles or saved links.

Record the current address of each important item, its business purpose and the person who can approve what happens to it. Include content that seems old until someone confirms it is no longer needed; an unfamiliar page may still answer a customer question or receive visits.

• Current URL and page purpose.
• Main customer action on the page.
• Form, booking or download dependency.
• Content owner and approval status.
• Keep, replace, combine or retire decision.

Give every old page a destination decision

Match each important current page to the most relevant page on the replacement site. If an address will remain the same, mark it as unchanged. If it changes, record the old and new addresses together so the technical handoff can be tested.

Do not send unrelated retired pages to the new home page simply because it is convenient. A removed page should have an intentional outcome based on whether equivalent content exists. Google recommends preparing an old-to-new URL map and using server-side permanent redirects for moved pages when technically possible.

A redirect plan supports customers and search systems, but it does not guarantee that visibility or rankings will remain unchanged. Google notes that significant site moves can cause temporary fluctuations while pages are recrawled and reindexed.

Separate the redesign from the launch dependencies

The website files are only one part of the transition. Confirm who controls the domain, DNS, hosting, content system and any accounts used by forms, booking links, analytics or verification. Access should be held in appropriate business-controlled accounts rather than depending on one person's memory.

Changing a website does not automatically require changing every connected service. Document what must stay untouched, especially business email and other services that use the domain. Any DNS change should be reviewed against the existing records and the intended hosting configuration before it is applied.

• Business owner or authorized approver.
• Person responsible for the technical launch.
• Account holder for the domain and hosting.
• Recipient responsible for testing each customer action.
• Support contact if a launch check fails.

Test customer journeys in the preview

A visual review does not prove that a customer request reaches the business. In the preview, run representative journeys from the page where a customer starts to the place where staff receive and handle the result.

Use fictional or specifically approved test information. An illustrative service-business test might submit a quote request, confirm the expected on-screen message, verify delivery to the designated recipient and check that the team can identify the next action. This is a planning example, not an 1120 client result.

Repeat the important checks on a phone-sized screen and a larger screen. Test navigation, contact details, forms, booking links and downloads without assuming that a successful page load means the complete workflow works.

Define a content freeze and approval point

Choose a point when routine edits to the current and replacement sites pause long enough for the final comparison. Otherwise an approved phone number, service description or policy may change in one version and not the other.

Before launch, the business approver should review the final page list, contact details, primary customer actions and any content intentionally removed. Record unresolved items instead of hiding them in a general approval message.

• Which version is the approved launch copy?
• Who may request a change during the freeze?
• Which open items block launch?
• Which non-blocking items have an owner and due date?
• Where are the previous site files or exports retained?

Write a launch sequence with named checks

Put the launch actions in order and assign each one to a person. Include the hosting or domain change, URL redirects where required, removal of temporary indexing restrictions, sitemap and canonical checks, and tests of the main customer paths.

Google advises checking redirects, canonical links and robots instructions when a site move starts, then submitting the new sitemap and monitoring errors. The exact steps depend on whether the domain or page addresses change; do not apply a domain-move procedure to a redesign whose URLs remain the same.

Record the expected result for each check. 'Forms work' is vague; 'the test enquiry from the contact page reaches the designated inbox and can be identified by the assigned staff member' is observable.

Agree on recovery criteria before changing the live site

Decide which failures require a correction on the new site and which justify restoring the last working deployment or configuration. The recovery decision should consider the business-critical path, the time needed to diagnose the issue and whether customers have a clear alternative contact method.

Keep the last working version and the information needed to restore it until the replacement has passed its agreed checks. A rollback plan reduces uncertainty, but it is not a promise of uninterrupted service or instant recovery.

• Main pages fail to load or show the wrong business information.
• A primary enquiry or booking path cannot be completed.
• Important old addresses lead to unintended destinations.
• A domain change affects another required service.
• The launch team cannot confirm which version is serving customers.

Check the live website after the switch

Run the launch checks again on the public domain, not only on a preview address. Open the home page, important service pages, contact route and a sample of old addresses from the mapping. Confirm page titles, canonical addresses, indexing instructions and the sitemap match the intended live version.

Continue reviewing customer actions and unexpected errors after launch. Google recommends monitoring both old and new URLs during a move and checking for crawl errors. The right monitoring period and tools depend on the size of the site and the changes made.

Bring the transition map to 1120

1120's published services include business websites, lead and CRM automation, booking and email workflows, customer portals and custom business software.

Bring the current website, the pages and customer actions that must continue, and the people responsible for approvals. That creates a concrete starting point for discussing a replacement. Hosting, migrations, integrations, timelines and deliverables require project-specific assessment before they are committed.

Start with your business process.

Describe how customers reach you and what your team needs to do next.

Explore 1120 capabilities