Website Migration Checklist: 10 Steps to Launch

The new website looks sharper, the pages are finally mobile-friendly, and everyone’s ready to celebrate. Then a prospect fills out the contact form and nothing reaches the sales inbox. An old service page disappears without a redirect. The domain loads, but the forgotten MX record breaks email. Customers notice before the team does.

A website migration checklist prevents that kind of launch. It follows the move from inventory and backups through the cutover and the first 30 days, with a suggested owner, verification step, and practical structure your team can copy into a spreadsheet. Preparation comes first. Launch is a controlled cutover, not a dramatic handoff. Success means verified traffic, working forms, preserved search signals, functioning email, accurate tracking, and usable customer journeys, not merely a site that loads.

Search visibility also takes patience. A 2024 analysis of 892 domain migrations found that a new domain took an average of 523 days to recover to the original site’s organic traffic level, while 17% had still not recovered after 1,000 days. That’s why the runbook below treats migration as an operational project that continues well beyond launch night.

1. Audit Your Current Site and Document Everything

Start with the site you have, not the one you wish you had. The project lead should own the audit, with technical and marketing input, and should freeze the resulting inventory as the pre-migration source of truth.

Crawl the existing site with Screaming Frog or Sitebulb, then combine that export with analytics landing pages, Search Console data, backlink information, the CMS, and manual checks. Record every page, template, form, plugin, custom script, integration, analytics ID, tracking pixel, redirect, login procedure, and unusual configuration. Take screenshots of key pages, including seasonal promotions and time-sensitive functionality.

A simple inventory spreadsheet should include:

• Page URL: Record the complete current address, including protocol and preferred host version.
• Page purpose: Note whether the page generates leads, supports customers, sells products, or provides information.
• Template and owner: Identify the layout and the person responsible for approving its replacement.
• Integrations: List forms, payment tools, calendars, chat widgets, email services, and other dependencies.
• SEO elements: Capture titles, canonicals, indexability, status codes, and important internal links.
• Migration decision: Mark each URL as migrate, consolidate, redirect, archive, or investigate.

A basic audit can uncover embarrassing problems early. An Austin accounting firm might discover that its contact form still routes to an abandoned Gmail account. A Dallas ecommerce business may find three outdated integrations adding maintenance work and slowing pages without supporting any active customer journey.

Practical rule: Don’t approve the new design until someone can explain what every important old page, form, and integration is supposed to become.

Capture a frozen baseline before changes begin. The website audit checklist can help organize that work, but the operating principle is straightforward: if you don’t document the old site, you won’t know whether the new one preserved it.

2. Create a Detailed URL Mapping and Redirect Strategy

The redirect map is the central SEO document. Google’s site-move guidance says to map current URLs to corresponding new URLs, configure server redirects, and monitor both URL sets after launch. Treat that as a launch gate, not a suggestion for later.

Use one row per old URL. Recommended columns are old URL, new URL, redirect type, target status, canonical URL, owner, test result, and notes. A row should make the destination obvious to a developer and a reviewer who wasn’t involved in building the site.

Identical URL structures can be the safest choice. If /services/tax-planning/ remains /services/tax-planning/, you eliminate unnecessary redirect work and reduce opportunities for mistakes. If the structure changes, map each page to its closest equivalent. Don’t dump every retired URL onto the homepage. That frustrates visitors and gives search engines a poor substitute for the original intent.

Use permanent 301 redirects for pages that have moved. Public migration guidance consistently distinguishes 301s from 302s, because a 302 communicates temporary movement while a 301 is the normal choice for a permanent relocation, as explained in this migration redirect guide.

Check for redirect chains, loops, query parameters, trailing-slash differences, capitalization changes, HTTP to HTTPS behavior, and retired content. A redirect should normally go directly from the old address to its final destination. A page with no meaningful replacement needs an intentional removal decision, not a random homepage redirect.

The SEO website migration services workflow is a useful reference for the supporting work around URL exports, canonical checks, sitemap updates, analytics verification, and post-launch crawl monitoring.

The map isn’t finished when the spreadsheet is populated. Export it into the server configuration or CMS implementation, then test representative URLs manually and in bulk.

3. Back Up Your Entire Site and Database

A backup that can’t be restored is a comforting file, not a recovery plan. Before the cutover, the technical owner should sign off on a tested restoration of the file system, database, media, configuration, and relevant CDN settings.

Keep multiple copies. One can remain with the current host, another can sit with the new host, and a separate copy should be stored outside both environments. For a large site, incremental backups may be more practical between full snapshots, especially when content or orders continue changing during the migration.

Your runbook should record:

• Backup timestamp: Note exactly when the copy was created.
• Storage location: Include the account, bucket, host, or offline location.
• Coverage: Confirm files, database, media, configuration, and redirect rules are included.
• Restore owner: Name the person who can perform the recovery.
• Rollback trigger: Define the condition that causes the team to stop troubleshooting and revert.
• Retention decision: Keep recovery copies available through the early post-launch period.

Automated scheduling catches changes that a one-time manual export misses. It’s especially useful for stores, membership sites, publishers, and businesses whose teams edit content right up to launch.

A Dallas technology startup might need a saved copy after a new host experiences hardware trouble shortly after launch. The point isn’t the story itself. The point is that recovery has to be possible while the business is still operating.

Test restoration from each important backup source before launch. A developer should be able to restore the site in a clean environment and explain what data would be lost if the rollback happened after the final content sync.

4. Choose Your Migration Method and Set a Migration Window

There’s no universally safest migration method. A small brochure site, a busy online store, and a complex SaaS platform have different failure points. Choose between a big-bang cutover, parallel run, phased migration, or blue-green deployment based on traffic, technical complexity, data volatility, and the cost of downtime.

A small Austin law firm may reasonably choose a quiet Sunday big-bang launch when the site has limited transactional complexity. A Dallas SaaS company with a highly available application may prefer blue-green deployment, where the new environment is prepared before live traffic is switched. A phased approach offers tighter troubleshooting, but it creates a longer period of operational overlap and demands disciplined URL and analytics tracking.

Write the selected method into an owner-approved runbook:

• Method and scope: State what’s moving and what isn’t.
• Start and finish targets: Include the intended cutover window and checkpoints.
• DNS targets: Record the current and new records before anyone edits them.
• Validation gates: Specify what must pass before the next step begins.
• Abort threshold: Define the condition that triggers rollback.
• Recovery contact: List technical, hosting, DNS, and business contacts.

Schedule the work during a historically low-traffic period, but don’t confuse quiet with risk-free. Keep the full team available, notify stakeholders and customers in advance when disruption is possible, and give the timetable more room than your optimistic estimate allows.

A cheap migration window is expensive if nobody with registrar access, hosting access, and business authority is available when the cutover stalls.

The method should match the business consequence of failure. Parallel systems may cost more to maintain. A big bang may be faster. Phased work may be easier to debug but harder to coordinate. Pick deliberately.

5. Test Everything on Staging Before Going Live

Staging is where you’re supposed to break things. Use an environment that matches production closely enough to expose template, hosting, caching, database, and integration problems before customers encounter them. Protect it from accidental indexing with access controls and temporary crawl restrictions, then remove those restrictions during the release process.

Test complete customer journeys, not just page appearance. A page can look perfect while its form submits to the wrong endpoint, its payment field rejects valid input, or its calculator uses an outdated formula.

Build the testing plan with these columns:

• Test case: Describe the exact action, such as submitting a contact form or downloading a proposal.
• Expected result: State what the user should see and where the data should arrive.
• Browser or device: Record the environment used for the test.
• Tester and status: Assign a person and mark pass, fail, blocked, or needs retest.
• Defect owner: Name the person responsible for correction.
• Retest date: Don’t let a fix disappear into a chat thread.

Test navigation, search, logins, forms, payments, downloads, video, media, third-party tools, consent behavior, and error states. Use real content instead of placeholder text. Open the site on actual phones and tablets, not only desktop browsers or emulators. Use browser developer tools to inspect console errors and simulate slower network conditions.

A San Antonio ecommerce company might catch a payment field character-limit bug in staging. An Austin B2B firm could discover that a pricing calculator returns the wrong result for a legitimate input. Neither issue is dramatic until a customer meets it on launch day.

Require separate approval from the technical lead, marketing owner, and business owner. The person who built the new site shouldn’t be the only person deciding that it works.

6. Update DNS Records and Monitor Propagation

DNS is where a website migration can become an email outage. Assign the registrar change to the person with the correct access, then give a second owner responsibility for independently checking public records.

Review A, AAAA, CNAME, and MX records, along with subdomains, verification records, email services, CDN entries, and any external systems that depend on the domain. Lower the TTL ahead of the migration when appropriate, keep the old host active during propagation, and record the original values before editing anything.

The launch checklist should include:

• Web verification: Confirm the new A, AAAA, or CNAME destination resolves correctly.
• Mail verification: Send and receive test messages through the business domain.
• Subdomain verification: Check staging, support, app, portal, and other active subdomains.
• Public lookup: Compare results from multiple locations and networks.
• Old-host status: Keep the previous environment available while traffic shifts.

A Dallas startup may lower TTL before the cutover and see DNS changes spread quickly. A Texas accounting firm that forgets its MX records can face bounced messages and missed leads. The latter is not an SEO problem, but it belongs in the same runbook because customers don’t separate your DNS records into neat project categories.

If a team member is troubleshooting a device that still resolves the old host, they may need to reset DNS on any device. That can help with local caching, but it won’t correct a bad public record.

Don’t shut down the old host immediately. The source migration guidance recommends ongoing monitoring of both URL sets, and the old environment remains useful while resolvers and users move across.

7. Redirect Analytics, Tracking, and Conversion Configurations

A visually accurate migration can still create a reporting blind spot. Before DNS changes, move Google Analytics, Google Tag Manager configurations, advertising pixels, heatmaps, consent-dependent tags, chat tools, call tracking, and conversion events into the new templates.

The marketing owner should verify the live site using real-time reports and test submissions. Don’t assume that copying a container or script preserved the underlying event logic. Forms may have new field names. Buttons may have new selectors. A checkout may use a different confirmation path.

Use a tracking handoff sheet that records:

• Tool and property: Identify the account, property, stream, or container.
• Placement: Note the template or page where the code runs.
• Event or conversion: Describe the action being measured.
• Trigger condition: Record the click, submit, page view, or server event.
• Consent dependency: State whether the tag requires visitor permission.
• Verification result: Capture the test user, time, and observed event.

Keeping the same Analytics property preserves historical continuity, while starting fresh can make a clean comparison easier to organize. The trade-off is real. A San Antonio SaaS company that starts a new property may lose convenient visibility into its long conversion history. An Austin agency that keeps the same property may spot a sudden bounce-rate change sooner because the data stream remains continuous.

A short period of dual tracking can expose discrepancies, but it also creates duplicate-event risk. Use Google Tag Manager preview mode, test forms and purchases with controlled data, verify UTM handling, and check that remarketing audiences and advertising destinations still use the correct domain.

Monitor visits, events, forms, and conversions closely after launch. Traffic without conversion data isn’t proof that the migration worked.

8. Verify SSL Certificate and HTTPS Compliance

HTTPS must be ready before customers arrive. Install the certificate on the new host before the DNS switch when possible, then verify it again through public DNS after propagation. A certificate that works on the origin server but fails on the public hostname is still a launch blocker.

Check the primary domain, www and non-www versions, active subdomains, HTTP-to-HTTPS redirects, form submissions, embedded assets, and browser warnings. Mixed content often hides in old image URLs, scripts, stylesheets, iframe sources, or form endpoints. Search the code and inspect the browser console instead of waiting for a customer to report the warning.

The technical owner should confirm:

• Certificate coverage: Every live hostname has valid coverage.
• Redirect behavior: HTTP resolves to the intended HTTPS URL with a permanent redirect where appropriate.
• Internal links: Navigation, content, canonicals, sitemaps, and structured data use HTTPS.
• Form security: POST requests reach HTTPS endpoints and submissions complete.
• Renewal: Certificate renewal is automated and monitored.
• Security headers: HSTS is configured only after the team understands its operational consequences.

A Dallas firm may find that mixed content warnings are also preventing contact forms from submitting because the form action still points to HTTP. That kind of defect can take hours to isolate after launch, when the pressure is highest.

Use this guide to install an SSL certificate as part of the technical preparation, then run an external certificate check such as SSL Labs. Test from a clean browser and a mobile connection, not only from an administrator’s cached session.

9. Post-Launch Monitoring, Critical Function Testing, and Final QA

The first launch window needs named people, not a group chat full of spectators. Assign one person to forms and email, another to redirects and SEO, another to performance and server errors, and a business reviewer to customer-facing journeys. Put every issue in a shared log with a timestamp, reproduction steps, owner, priority, and resolution.

Start with the paths that produce revenue or leads. Submit forms, complete a payment, log in, download a file, play important media, use search, and test the primary calls to action. Watch server logs and error reporting during the cutover. A dashboard that looks green doesn’t replace a real form submission.

Within the first 24 to 48 hours, compare the live site against the pre-migration audit. Review:

• Redirect behavior: Spot-check old high-value URLs and representative legacy pages.
• Search signals: Confirm canonicals, robots directives, XML sitemaps, internal links, and indexability.
• Measurement: Verify real-time visits, events, form conversions, and campaign parameters.
• Performance: Test priority pages on desktop and mobile, then inspect Core Web Vitals.
• Business workflows: Confirm customers can complete the actions that matter.

Google’s Core Web Vitals benchmarks remain LCP under 2.5 seconds, INP under 200 milliseconds, and CLS under 0.1, according to BrightEdge’s migration guidance for AI search. The same guidance highlights structured data, FAQ schema, and AI answer-engine visibility as migration considerations, so don’t limit QA to classic ranking mechanics.

An Austin SaaS business might catch a broken form within minutes. A Dallas agency’s final comparison could reveal incorrect blog authorship. A San Antonio ecommerce team may find mobile checkout behaves acceptably in staging but slows under live conditions. Fast detection matters more than a polished launch report.

10. Establish Post-Migration Monitoring and Create a Maintenance Plan

Launch support shouldn’t end when the team closes the release channel. Keep a named owner for uptime, errors, redirects, analytics, backups, certificates, performance, and customer-reported problems. If nobody owns a signal, nobody will respond consistently.

Use tools such as Uptime Robot, New Relic, or Datadog for automated alerts, then review the underlying logs instead of treating alerts as the diagnosis. Check 404 errors weekly, repair broken redirects, review traffic and conversions monthly, and schedule recurring performance audits with Lighthouse or a similar tool. Test a backup restoration regularly so recovery remains a capability, not a forgotten promise.

Create a calendar with:

• First 30 days: Review traffic, conversions, crawl errors, indexation, redirects, forms, email, and performance.
• 90-day checkpoint: Compare old and new URL performance, resolve lingering 404s, verify the handoff, and update the changelog.
• Six-month checkpoint: Recheck important backlinks, templates, plugins, certificates, performance, and backup restoration.
• Ongoing ownership: Record escalation contacts, maintenance windows, renewal dates, and approval responsibilities.

A migration baseline should include at least 28 days of data, including organic clicks and impressions, priority-query rankings, sessions and conversions by landing page, indexed-page count, important backlinks, crawl errors, server responses, page speed, and Core Web Vitals. Lumar’s migration checklist recommends reviewing that comparison during the first 24 hours, daily for two weeks, then weekly until performance stabilizes.

An Austin technology company might discover a custom-plugin memory leak months after launch. A San Antonio staffing agency may find old form URLs generating 404s in the logs. Those issues are exactly why the maintenance plan needs to outlive the launch team’s sense of relief.

10-Step Website Migration Checklist Comparison

Make the Launch the Start, Not the Finish

A reliable migration runbook turns a complicated project into accountable handoffs.

The business owner approves the scope, launch timing, acceptable downtime, and rollback decision. That person also confirms which customer journeys cannot fail. If the business owner only sees the finished design, they’re missing the decisions that determine whether the move protects revenue.

The technical lead owns backups, restoration testing, DNS, SSL, hosting, deployment, server logs, and rollback. They should know where the backups live, who controls the registrar, how the new environment is reached, and what condition stops the launch. “We can fix it” isn’t a rollback plan.

The SEO or marketing lead owns the URL inventory, redirect map, metadata, canonicals, XML sitemap, analytics, conversion events, structured data, important backlinks, and Search Console checks. Their work connects the old site’s search signals to the new site’s implementation.

The business team validates forms, payment paths, logins, downloads, phone numbers, email delivery, scheduling tools, and the customer experience on real devices. Technical approval can’t confirm whether a prospective client receives a quote request or whether a customer can complete checkout.

Keep the old host available during DNS propagation and continue checking email records, web resolution, redirects, and critical workflows. Watch especially closely during the first 24 to 48 hours, then compare performance, errors, conversions, and search signals throughout the first 30 days. Semrush’s migration checklist also emphasizes baseline tracking, gated launch steps, URL mapping, staging audits, updated sitemaps, and post-launch troubleshooting. Those aren’t decorative tasks. They’re the controls that make a difficult move diagnosable.

The timeline deserves realistic expectations. A study of 892 domain migrations found an average recovery period of 523 days, and 17% of migrations had not recovered after 1,000 days. That evidence doesn’t mean every redesign will take that long. It does mean a domain move can create a search problem that persists long after the launch team has moved on.

Traffic loss is also common enough to plan for rather than dismiss. One migration benchmark summary reports that well-managed migrations saw under 15% traffic loss in the first 30 days, while partial redirect coverage led to 20% to 40% losses, and poorly covered domain changes could exceed 50%. A separate Ahrefs-based analysis reported by the same website migration statistics resource says around 60% of migrations produce measurable organic traffic loss. These figures reinforce the practical priority: map URLs completely, preserve important content, validate redirects, and investigate performance changes by page instead of guessing.

A migration isn’t complete when DNS points to the new host. It’s complete when the business can prove that customers, search engines, email, tracking, and core workflows all made the move. That proof lives in test results, logs, analytics, Search Console, conversion checks, and the maintenance calendar.

If the team can’t answer who owns the next check, the migration is still underway.

X8 Web Design can help small businesses plan and execute website migrations with URL mapping, SEO checks, hosting and domain configuration, SSL, analytics verification, and post-launch support. Visit X8 Web Design to discuss your current site, the risks in your move, and a practical launch plan.