Website Migration Checklist: 10 Steps for a Safer Move

Your redesigned website launches on a Friday morning, and the first few hours feel promising. Then a customer reports that a contact form doesn't work. Your team finds product pages returning errors, old blog links leading nowhere, and analytics showing far fewer conversions than expected. By the time someone checks search visibility, several important pages have disappeared from their former positions.

That scenario isn't unusual because a website migration changes more than colors, layouts, or hosting. It can affect rankings, lead generation, customer experience, compliance, analytics, security, and ownership at the same time. A safer move coordinates the existing site's content and technical assets with the new platform, staging environment, launch controls, redirects, performance checks, and post-launch responsibilities.

The business risk can last longer than launch week. A widely cited study of 892 domain moves found that the average site took 523 days to return to its pre-migration organic traffic level, while 17% never fully recovered after 1,000 days. Those findings make a website migration checklist a long-horizon business continuity plan, not a final-day task list (migration study and checklist guidance).

For a Cincinnati-area small or mid-sized business, the right approach is practical. Assign clear owners, define what success means, decide when to pause or roll back, and keep the people who manage sales, customer service, marketing, technology, and compliance involved. If the work exceeds your internal capacity, a Cincinnati-area agency such as HDM can help coordinate the move without separating the technical work from revenue and customer outcomes.

1. Audit Your Current Website and Document All Assets

Before anyone changes the CMS, hosting account, domain, or design, create a reliable record of what already works. Crawl the current site and export its URLs, status codes, page titles, canonical settings, internal links, images, downloads, and templates. Then compare that crawl with analytics, Google Search Console, your XML sitemap, paid campaigns, social profiles, and sales or service workflows.

The inventory should include more than public pages. Record forms, booking tools, payment systems, chat widgets, CRM connections, email notifications, plugins, custom code, tracking tags, search filters, customer portals, and third-party integrations. A website can look complete while a hidden workflow sends leads to an inactive inbox or relies on a plugin that won't exist on the new platform.

Build a business-priority baseline

Mark pages according to their business role, not just their traffic. A service page that generates qualified inquiries may deserve more protection than a high-traffic article that rarely supports a sale. Capture priority keyword rankings, branded search results, organic traffic, organic conversions, page speed, load times, Core Web Vitals, and URL-level conversion data before launch. These benchmarks are the only dependable way to identify regressions afterward, as Lumar's migration checklist guidance explains.

Use a shared spreadsheet with fields such as:

• Current URL: Record the exact live address, including capitalization and trailing-slash behavior.
• Business role: Identify whether the page supports leads, sales, support, recruiting, or brand visibility.
• Owner: Name the person responsible for approving content and functionality.
• Dependencies: Note forms, integrations, custom scripts, or third-party services.
• Migration decision: Mark the page to keep, revise, combine, redirect, or remove.

A Cincinnati manufacturer, healthcare provider, or professional-services firm often has important assets outside the marketing team's view. Ask sales, service, operations, and compliance staff to review the inventory. You can also check your site's sitemap as one source for discovering URLs, but don't treat the sitemap as a complete record because it may exclude older linked pages, campaign landing pages, or files.

2. Plan Your New URL Structure and Create Redirect Mapping

A URL change is a customer-routing decision and an SEO decision. If /services/seo-help becomes /services/seo, the old address still exists in search results, bookmarks, ads, emails, partner websites, and browser history. Without a direct route to the correct new page, visitors encounter a dead end and search engines lose context about the relationship between the old and new content.

Google recommends a deliberate sequence for site moves: prepare the new site, map old URLs to new URLs, activate redirects, and monitor both versions after launch (Google's site-move sequence). Build the mapping before development is finished, because URL decisions affect navigation, internal links, canonical tags, XML sitemaps, content references, and campaign destinations.

Make the map specific

Use one row per old URL. Assign the closest equivalent new destination, record the redirect type, and add a test result. Don't send every discontinued page to the homepage. A visitor arriving from an old product guide or service article should land on a relevant replacement, not a generic page that forces them to start over.

Practical rule: Keep a URL when it already has useful visibility, links, or customer value. Change it only when the new structure solves a clear problem.

Keep redirects direct. An old URL should go straight to the final destination, not through several intermediate addresses. This matters on Shopify projects, where collection and product URL patterns can change during restructuring. Review Shopify redirect practices carefully when products, collections, or app-generated paths are involved.

Your new architecture should make related services and content easy for people and search engines to understand. HDM's guidance on site architecture for SEO can help Cincinnati business owners evaluate whether the proposed navigation and content hierarchy support discovery, conversion, and future growth.

Google Search Console guidance recommends a 301 redirect from the old homepage to the new homepage, along with 301 redirects for canonical pages on the old site (Google's Change of Address guidance). Permanent server-side redirects, specifically HTTP 301 or 308, are preferred whenever possible (redirect implementation guidance).

3. Back Up Your Entire Current Website

A verified backup gives your business a recovery path if the new platform behaves differently from staging. Preserve the current database, media library, theme or template files, configuration, redirect rules, custom code, user records, product data, email settings, and integration credentials. WordPress and WooCommerce projects require the database and uploads directory, not only downloadable copies of visible pages. Shopify migrations should also preserve product, customer, order, theme, and app-related data that the platform and connected tools allow you to export.

Treat the backup as part of business continuity. Keep an independent copy in a separate secure location, record access permissions, and document restoration steps in language a business owner can follow. A file that exists but cannot be restored under pressure does not protect rankings, leads, customer service, or revenue.

Prove the rollback path

Restore the backup in a safe environment before launch. Confirm that pages render, forms submit, media loads, administrator access works, and critical integrations reconnect. For a headless CMS, verify the content export, frontend build, API connections, and deployment configuration together. This exercise exposes missing credentials, incomplete exports, incompatible software, and unclear ownership while the current site remains available.

Record the decisions that matter:

• Backup contents: List files, databases, media, configuration, customer data, and order data.
• Storage locations: Note independent locations, encryption or other safeguards, and access permissions.
• Restore owner: Name the person responsible for restoration and verification.
• Rollback trigger: Define the failures that justify returning to the old site, such as broken checkout, lost lead submissions, or major content errors.
• Retention plan: Keep the legacy backup after launch according to operational and compliance requirements.

Healthcare organizations should involve the appropriate privacy and security stakeholders. The process must protect sensitive patient information and support applicable safeguards. A hosting provider or migration tool does not automatically satisfy HIPAA-related obligations.

HDM's backup and disaster recovery guidance offers a framework for documenting this continuity plan. Before launch, answer one practical question: if the new site fails during a busy sales period, can the team restore a known working version without guessing?

4. Test the New Website Thoroughly Before Going Live

Staging gives your team a private version of the new site where failures are inexpensive. Keep it protected from public visitors and search engines while you test representative pages, templates, integrations, and content. A staging review should include the paths that create revenue or trust, not just a visual inspection of the homepage.

Start with a task-based test. Ask a person unfamiliar with the build to find a service, submit a form, request a quote, complete a purchase, locate support information, and use the site's search. Technical staff should validate links, status codes, redirects, structured data, robots directives, canonical tags, XML sitemaps, image behavior, and error handling.

Test the real customer journey

Check common browsers and real devices, including mobile phones and tablets. Confirm that forms submit successfully, notifications reach the correct people, payment processing completes, confirmation emails are delivered, and CRM records contain the expected information. Test slow connections and weaker devices because a polished desktop experience can still hide a serious mobile conversion problem.

For a Shopify migration, review product pages, collections, search, discount codes, shipping, tax settings, customer accounts, checkout, transactional emails, and installed apps. WooCommerce requires focused testing of WordPress data, plugins, payment gateways, shipping rules, inventory, order emails, and backup restoration. A headless CMS project needs tests for API responses, frontend rendering, preview workflows, caching, structured metadata, and fallback behavior when an API request fails.

Use a written defect log with the page, device, browser, steps to reproduce, severity, owner, and approval status. Performance tools can identify issues, but a real customer task tells you whether the problem affects a purchase or inquiry.

A short technical walkthrough can help nontechnical stakeholders understand what to test:

If your new architecture runs on cloud infrastructure, confirm that hosting resources match actual application requirements. Guidance on how to rightsize EC2 and RDS is relevant when an AWS-backed migration includes infrastructure changes, though cost decisions should follow testing and service requirements rather than launch-day guesswork.

5. Set Up Proper Analytics and Tracking Before Launch

A new website without validated tracking is operating without a dashboard. Install the agreed analytics property, conversion events, advertising tags, call tracking, form tracking, ecommerce events, and Search Console verification before the domain points to the new site. Test the setup on staging or a controlled environment so the first live visit produces usable information.

Track the actions that matter to the business. A Cincinnati law firm may need consultation requests and phone calls. A manufacturer may need quote submissions and specification downloads. An online retailer needs product views, add-to-cart actions, checkout steps, purchases, refunds, and revenue attribution. A healthcare organization may need appointment requests while ensuring analytics configuration doesn't expose protected health information.

Measure revenue, not just rankings

Migration reporting should connect technical events with outcomes. Compare organic traffic, organic conversions, keyword rankings, Core Web Vitals, crawl errors, indexing status, and page-template performance. Then segment the results by device, page type, market, and acquisition channel. A rankings report alone can't tell you whether a form stopped working, whether paid traffic reached the wrong landing page, or whether direct visitors abandoned a slower checkout.

This is a commonly missed part of migration planning. Many checklists emphasize redirects, sitemaps, and noindex cleanup but give less attention to conversions, assisted conversions, and performance across organic, paid, and direct traffic (business-focused migration measurement guidance).

Before launch, verify each important event with a test submission or transaction. Check that the right property receives the event, duplicated tags aren't inflating results, internal traffic is handled consistently, and campaign links preserve their UTM parameters. Record the event names, definitions, owners, and reporting locations so the next person doesn't have to reverse-engineer the setup.

Create alerts for unusual traffic, conversion, indexing, or error changes. The alert isn't a diagnosis, but it gives the business a chance to investigate before a small tracking or routing problem becomes a larger revenue problem.

6. Communicate Your Migration Plan to Your Team and Customers

A migration changes daily work for the people who answer phones, process orders, manage appointments, publish content, run campaigns, and support customers. Tell them what changes, what stays the same, when the switch happens, and who handles problems. Assign owners for customer support, content updates, campaign links, approvals, and rollback decisions.

Give internal staff access before customers do. Sales and service teams should test navigation, contact paths, product details, account features, downloadable resources, and any workflow they use every day. Their feedback can reveal a broken form or confusing path that a technical test misses.

Prepare a short briefing for customer-facing employees. Include known changes and answers about forms, appointment booking, account access, checkout, saved bookmarks, and login steps. Shopify teams should check storefront and customer-account changes. WooCommerce teams should confirm that staff understand WordPress admin and order workflows. Headless CMS teams need clear ownership for content publishing, frontend issues, and API-related questions.

Set expectations without creating alarm

Customer messages should explain the practical benefit and the action required. Tell visitors how to find services, products, support resources, or booking tools. If an account step or saved bookmark may change, state that plainly.

Use the existing site for a concise notice, then update email signatures, social profiles, Google Business Profile links, and active advertising destinations. Coordinate every message with the actual domain and platform switch so customers do not arrive at an old page or unavailable workflow.

A launch communication sheet keeps decisions visible:

• Audience: Customers, employees, partners, vendors, and internal approvers.
• Message: The improvement and any action the recipient must take.
• Timing: The planned announcement and switch time.
• Support route: The email, phone number, or owner handling questions.
• Escalation: The person who can pause the launch or approve rollback.

Healthcare providers should explain appointment requests and patient resources without promising unsupported workflows. Manufacturers and B2B firms should alert distributors, sales representatives, and partners who rely on bookmarked technical pages. Clear communication protects confidence and gives employees a practical role in launch testing.

7. Set Up Your Domain, SSL Certificate, and Hosting Configuration

The domain cutover connects the public address to the new infrastructure. Before changing DNS, verify the hosting environment, SSL certificate, email routing, DNS records, CDN behavior, server configuration, redirects, environment variables, and administrative access. Keep a written record of the current values and the intended new values so someone can reverse an incorrect change without reconstructing the setup from memory.

HTTPS must work across the full site, not just the homepage. Test the certificate, secure asset loading, canonical URLs, HTTP-to-HTTPS behavior, subdomains, forms, checkout, account areas, and any API endpoints used by the frontend. A browser warning on a payment or appointment page can stop a customer before they reach the conversion event.

Coordinate the cutover

Choose a lower-risk period based on the business's actual traffic and order or inquiry patterns. Freeze unrelated releases around the switch so a separate code change doesn't obscure the cause of a migration problem. Keep the old hosting environment available until the new site, redirects, analytics, email, and priority workflows have passed their launch checks.

Shopify owners should verify the domain connection, checkout behavior, transactional email settings, app callbacks, and any subdomains used for campaigns or customer portals. WooCommerce owners need to confirm WordPress URL settings, server rules, PHP and database compatibility, cron jobs, payment callbacks, and email delivery. Headless projects require a coordinated check of DNS, frontend hosting, CMS APIs, preview environments, image delivery, caching, and server-side rendering.

HDM's resource on SSL certificate installation is relevant when a Cincinnati business needs to verify the secure connection before launch. Keep the rollback decision in writing. If DNS points correctly but checkout fails, or if forms stop reaching the CRM, delaying the release may protect more value than pushing forward because the calendar says launch day.

8. Monitor Site Performance and Search Rankings Immediately After Launch

Launch day starts the business continuity watch. Check priority URLs from real devices and ordinary customer paths, including the homepage, major service or product pages, lead forms, checkout, account functions, support resources, and campaign landing pages. Confirm that each page loads, key actions complete, and submissions reach the right system.

Create a baseline comparison in Search Console and analytics. Review organic traffic, organic conversions, keyword rankings, Core Web Vitals, crawl errors, indexing, and page-template performance against pre-launch results. Examine sitewide trends alongside individual URLs, since steady totals can conceal a serious drop on a high-value service page.

Assign owners and set the review cadence

Give one technical owner responsibility for uptime, server errors, logs, redirects, and integrations. An SEO owner should review indexation, canonical signals, sitemaps, robots directives, rankings, and landing-page visibility. A business owner should test lead handling, order processing, appointment requests, and customer support. Record who can approve a rollback and how quickly the team must respond.

For Shopify, check storefront speed, product and collection templates, checkout, app integrations, and campaign landing pages. WooCommerce teams should compare product templates, payment processing, database response, scheduled jobs, and email delivery. Headless CMS projects need checks across the frontend, CMS APIs, caching, image delivery, preview environments, and server-side rendering.

Prioritize these signals:

• Crawl changes: Look for blocked resources, unexpected exclusions, or indexing problems in Search Console.
• Conversion changes: A broken form or checkout can reduce leads and orders while traffic remains stable.
• Template patterns: If every product, location, or service page changes performance, inspect the shared template before editing individual pages.
• Device differences: A mobile-only failure can interrupt a major customer path without appearing on desktop.
• Redirect behavior: Confirm that priority old URLs resolve directly to their intended destinations.

Treat ranking movement as a signal to investigate, not automatic proof of failure. Compare persistent losses, crawl blocks, missing pages, and conversion failures with the actual customer experience. Keep the previous environment available until the new site has passed these checks and the rollback decision is no longer needed.

9. Monitor and Fix Broken Links and 404 Errors

A 404 appears when a requested page is unavailable at that address. Some are intentional, but migrations often create accidental errors through outdated menus, blog references, missing media, campaign links, or changed product and service paths. For a Cincinnati-area business, that broken path may mean a missed inquiry, appointment, or order that never reaches the CRM.

Start with the customer journey, then inspect the technical causes. Crawl the live site after launch and review Search Console for discovered errors. Test menus, footers, articles, resource pages, PDFs, email templates, and location pages. Review business-controlled external destinations as well, including social profiles, directory listings, Google Business Profile, partner pages, and active advertising campaigns.

Repair the right layer

Correct a broken internal link at its source whenever possible. Use a permanent redirect when the old URL has a genuine replacement and still receives visitors or links. If no relevant successor exists, restore, replace, redirect, or retire the content deliberately. Sending every missing page to the homepage removes the visible error but often creates a poor customer experience and a weak relevance signal.

Check these paths in order:

• Revenue paths: Product, service, quote, booking, contact, and checkout links come first.
• High-visibility content: Repair pages receiving search visits or supporting active campaigns.
• Navigation systems: Check menus, breadcrumbs, footers, filters, and related-content modules.
• External destinations: Update links your team controls so they point directly to the current address.
• Error experience: Give visitors a useful 404 page with search, navigation, and relevant resources.

Platform checks vary. Shopify teams should test product, collection, campaign, and app-generated links. WooCommerce teams should check product variations, payment paths, and links created by plugins. Headless CMS projects require testing frontend routes, CMS-driven links, preview output, and cached responses across devices.

Record each issue, cause, fix, owner, and verification date. A second crawl confirms whether the repair worked rather than shifting the failure elsewhere. Keep the previous environment available until priority paths pass testing and rollback is no longer required. Continue monitoring after cleanup, since old emails, bookmarks, and external references can expose broken addresses later.

10. Conduct Post-Migration SEO Optimization and Content Review

A site can launch without errors and still lose visibility or leads. Once the new environment is stable, compare key pages with the approved pre-launch inventory and inspect the live HTML, not only the content editor. Check whether titles, headings, internal links, image descriptions, structured metadata, and calls to action still support the same search and customer journeys.

Use a focused review rather than changing every page at once. Verify title tags, meta descriptions, heading hierarchy, canonical settings, alt text, indexability, structured data, internal links, and XML sitemap inclusion. Look for truncated copy, placeholder text, missing navigation context, and content that no longer matches the page template. Cincinnati-area businesses should review location and service pages closely, since template changes can affect local relevance and lead quality.

Platform details matter:

• Shopify: Confirm product, collection, campaign, and app-controlled templates retain intended SEO fields and purchase paths.
• WooCommerce: Review product attributes, variations, checkout messaging, and SEO fields managed through plugins.
• Headless CMS: Test rendered metadata, frontend routes, CMS-driven content, preview output, and cache behavior across devices.

Prioritize pages tied to revenue, active campaigns, or clear technical and content problems. Refresh outdated service details, product specifications, staff information, compliance language, and calls to action. Consolidate overlapping pages only when the new structure supports that decision. Removing content to reduce page count can discard useful search coverage and customer information.

Use Search Console and analytics to compare landing-page impressions, clicks, rankings, engagement, and conversions. Segment the review by device, page type, market, and acquisition channel. Business results provide the final check. A page may retain rankings while producing fewer inquiries because its form is harder to find. Another may gain visibility but attract poor-fit visitors after its message becomes less specific.

For each priority page, confirm:

• Can visitors understand the offer quickly?
• Does the page match its target search intent?
• Is the next action obvious and functional?
• Can search engines crawl, interpret, and index it?
• Does it support related pages with useful internal links?

Keep required migration fixes separate from later optimization where possible. That separation makes diagnosis easier and gives the team a practical backlog. HDM's SEO, analytics, content, and conversion capabilities can help Cincinnati businesses turn post-launch findings into assigned improvements, with ownership and business impact recorded for each task.

10-Step Website Migration Checklist Comparison

Protect the Investment After Your New Site Goes Live

A successful launch needs an ownership plan. Assign a business owner who decides whether the move is meeting customer and revenue needs, a technical owner who handles hosting and defects, an SEO owner who monitors visibility and indexing, and an approval contact who can make final decisions about content, compliance, and rollback. One person can hold multiple roles in a small company, but each responsibility still needs a named owner.

Keep the migration record in a shared location. It should include the asset inventory, baseline reports, final URL map, redirect rules, test results, DNS changes, analytics documentation, backup locations, known issues, and rollback criteria. If a problem appears months later, your team shouldn't have to search through old email threads to determine what changed or where the previous site can be restored.

Use a review schedule that matches the risk:

• Launch-day review: Confirm domains, SSL, redirects, indexability, priority pages, forms, checkout, analytics, and customer support paths.
• 48-hour review: Compare traffic, conversions, crawl errors, server logs, indexing signals, and device performance.
• One-week review: Re-crawl the site, inspect broken links, review priority rankings, validate templates, and resolve remaining launch defects.
• Longer-term review: Evaluate page-level visibility, conversions, assisted conversions, Core Web Vitals, content quality, and the business case for further optimization.

Platform choice changes the testing emphasis. A Shopify migration needs careful checks of products, collections, customer accounts, checkout, discounts, shipping, tax behavior, transactional emails, and installed apps. Product handles, collection paths, app scripts, and checkout settings can affect both customer experience and search continuity.

WooCommerce projects require a more detailed WordPress review. Validate posts, pages, products, variations, orders, customers, plugins, payment flows, shipping rules, tax configuration, scheduled tasks, email delivery, server compatibility, and backups. A plugin that supplied filtering, structured data, redirects, or forms on the old site may need an explicit replacement or configuration change.

Headless CMS migrations bring a different risk profile. The CMS may contain the content, but a separate frontend controls rendering and routing. Test API responses, preview workflows, image transformations, caching, server-side rendering, structured metadata, redirects, error states, search, and deployment rollback. A page can exist in the CMS and still fail for visitors if the frontend doesn't request or render it correctly.

Healthcare organizations should involve the appropriate privacy, security, legal, and operational stakeholders. Verify safeguards for patient information, forms, analytics, backups, access controls, vendors, and integrations instead of assuming that a platform is compliant because it is widely used. The migration plan should show who approved each sensitive workflow and how the organization will respond if a safeguard fails.

For Cincinnati-area owners, an agency becomes valuable when the project crosses technical and business boundaries. HDM is based in Springboro, Ohio, serves the Greater Cincinnati area, and works across website development, platform migrations, Shopify, WooCommerce, headless CMS implementations, SEO, analytics, security, backups, and performance. The right partner won't just move files. They'll help your team decide what must be preserved, what should improve, how success will be measured, and what happens if the launch doesn't go as planned.

The safest migration is the one your business can explain after launch. Your team should know what changed, where the evidence lives, which pages matter most, who responds to issues, and when to choose repair instead of rollback. Treat the website as an operating asset with customers, revenue, data, and reputation attached to it, and the migration becomes manageable work rather than a high-pressure technical gamble.

---

If your Cincinnati-area business is planning a redesign, replatforming project, Shopify or WooCommerce move, or headless CMS migration, HDM can assess the plan across SEO, development, analytics, security, and conversion paths. Contact HDM to review your current site, redirect strategy, testing process, and post-launch ownership before you switch the domain.