A redesigned website can look perfect in a browser while putting revenue at risk. A missing redirect can send a valuable service page to a dead end. A form may appear functional but fail to deliver inquiries to the CRM. An analytics tag may disappear during the content transfer, and a payment gateway can fail only when a real customer reaches checkout.
That's why a website migration checklist should be treated as a revenue-protection operation, not a platform switch. The work needs to follow a controlled sequence: establish baseline evidence, inventory the current site, build and protect the new environment, test critical workflows, control the DNS change, and monitor both search visibility and conversions after launch.
Recovery also takes longer than many business owners expect. A large SEO migration study published in 2025 found that the average site took 523 days to regain its previous organic traffic after a domain migration. The shortest recovery times recorded were 19, 22, 23, and 33 days, while 17% of sampled migrations still hadn't returned to prior traffic levels after 1,000 days (migration research and benchmark). A launch checklist matters because it reduces preventable disruption, while a monitoring plan makes sure problems don't remain hidden.
1. Conduct a Comprehensive Site Audit and Inventory
Start with evidence, not assumptions. Before anyone changes the CMS, create a complete record of the current site's pages, templates, media, redirects, forms, integrations, plugins, custom code, and business-critical workflows.
A crawl with Screaming Frog SEO Spider can reveal live URLs, status codes, title tags, meta descriptions, canonicals, internal links, images, and redirect behavior. Combine that crawl with analytics exports and Search Console data so your inventory reflects both what exists and what customers use. A page that receives little internal linking may still generate qualified leads or attract valuable external links.
Build a business-priority inventory
Your spreadsheet should connect technical details to commercial importance. Record the old URL, page type, page owner, target URL, title, meta description, canonical, conversion action, and testing priority. Mark product pages, service pages, contact pages, booking flows, quote forms, checkout steps, and high-value landing pages clearly.
For a small retailer, the audit might uncover product URLs that aren't linked from the current navigation but still receive search visits. For a professional services firm, it might reveal a large collection of service, location, attorney, consultant, or resource pages that need different levels of review.
Export a meaningful period of historical analytics before the move. The exact period should match the business's reporting practices and seasonality. Preserve reports for organic sessions, landing pages, leads, purchases, revenue events, assisted conversions, and top referral sources.
Practical rule: If you can't explain where a page, form, integration, or redirect goes after launch, it isn't ready for migration.
Document third-party dependencies, including payment processors, email platforms, CRMs, appointment tools, chat widgets, review systems, analytics, advertising pixels, and shipping services. This inventory becomes the reference for staging QA, launch checks, and rollback decisions.
2. Choose the Right CMS Platform and Hosting Solution
A new CMS should solve a business problem without creating a maintenance problem. Choose the platform around the workflows that produce revenue, not around a feature list that looks impressive during a sales demonstration.
An online retailer needs dependable product management, inventory connections, payment gateway compatibility, tax and shipping support, customer account handling, and a checkout experience the team can test and maintain. A service business needs flexible landing pages, forms, scheduling, CRM routing, content editing, and reporting that connects inquiries to their source.
For a healthcare practice, privacy and security requirements may eliminate otherwise attractive options. A professional services firm may value editorial control and reusable page templates more than advanced commerce features. Hosting also needs to match the new site's operational requirements, including SSL support, backups, security monitoring, deployment access, and responsive technical support.
Use this content management system guide to clarify how the CMS fits into your publishing and management needs, then document the platform decision in the migration plan.
Test the real workflow before committing
Don't rely on a generic demo site. Build representative pages and run the workflows that matter:
- Commerce compatibility: Confirm that the payment processor, product catalog, inventory, tax, shipping, refunds, and order notifications work together.
- Lead capture: Submit forms through every major template and verify that records reach the correct CRM, inbox, automation, and reporting destination.
- Content operations: Ask the people who'll manage the site to create, edit, schedule, preview, and restore content.
- Hosting controls: Verify SSL, backup access, deployment procedures, staging support, logs, firewall settings, and escalation paths.
A lower-cost platform may reduce initial complexity but limit customization later. A highly customized build may provide better control but require stronger documentation and technical ownership. If the move also involves infrastructure changes, a documented custom cloud strategy from devPulse can help clarify dependencies, environments, and deployment responsibilities.
3. Set Up 301 Redirects and URL Structure Mapping
URL changes are where many migrations lose their connection to existing search visibility. A permanent 301 redirect tells browsers and search engines that an old address has moved to a new one. The redirect only helps when it points to the closest relevant destination.
Create a master map with one row for every old URL. Use columns for the old address, new address, redirect type, page status, owner, test result, and notes. Include URLs found in the crawl, sitemap, analytics, Search Console, CMS exports, advertising campaigns, social profiles, email templates, and important external links.
A local service provider might move /service-1 to /services/plumbing-repair. An online store might reorganize categories and product paths. In both cases, the old URL should point directly to the corresponding new page, not to a category homepage or a generic services page.
Avoid chains, loops, and irrelevant targets
An old URL should go straight to its final destination. Avoid a sequence such as old page to temporary page to final page, because every extra hop adds failure points and makes diagnosis harder. Update internal links so they reference the final URLs directly.
Use a 301 for content that has moved. If an old page has no genuine equivalent and shouldn't be republished, don't force it into an unrelated destination. Your SEO specialist or developer may choose an appropriate removal response, such as a 410, based on the content and business decision.
Run the map through a crawler and a redirect testing tool before launch. The Keyword Kick redirect checker can be part of that verification process, while a fresh crawl can identify chains, loops, broken destinations, and redirects pointing to blocked or noncanonical pages.
After launch, inspect redirect errors and crawl issues in Search Console. Keep the redirect file, test results, and change history with the migration documentation.
4. Back Up All Data and Create a Rollback Plan
A backup is useful only if you can restore it. Before the migration, preserve the current database, website files, media library, configuration files, redirect rules, DNS settings, analytics setup, email configuration, and integration details.
Keep more than one copy. Use the hosting provider's backup system alongside a manual export stored outside the production server. Protect credentials and API keys in an approved password manager or secure secrets system, not in an unsecured spreadsheet or chat message.
Define the rollback trigger
A rollback plan should answer four questions:
- Who decides: Assign one person with authority to pause or reverse the launch.
- What triggers action: Define unacceptable failures, such as unavailable priority pages, broken payment processing, missing lead notifications, severe crawl blocks, or unverified analytics.
- How restoration works: Write the exact DNS, database, file, and configuration steps in order.
- How communication happens: Prepare internal and customer-facing updates if the old site must return.
Restore a backup in a safe environment before launch. A file that downloads successfully may still contain a damaged database, missing media, invalid permissions, or unusable configuration. Test the actual recovery path and record what worked.
For a business that depends on inquiries, include the forms and their destinations in the recovery test. The workflow described in this guide to transfer lead capture forms should be considered alongside the site's CRM and notification setup.
Schedule the cutover during a period when the team can respond quickly and customer demand is manageable. Don't cancel the old hosting or delete the old environment until the new site has been verified and the migration owner agrees that rollback is no longer needed.
5. Migrate Content and Database with Quality Assurance Testing
Treat the migration as a revenue-protection operation. Import content and database records in staging before changing the live site, then verify the paths that create leads, orders, accounts, and useful analytics. The transfer may include pages, posts, products, customer data, media, navigation, custom fields, users, orders, settings, and database relationships. An import confirmation does not prove that these connections survived.
Start with a staging copy that matches production. Compare record counts, media coverage, page samples, product attributes, permissions, relationships, and formatting with the source site. Test high-value pages first, then work through lower-priority content and unusual cases.
Validate the workflows that produce revenue
A page review can miss failures between systems. Follow each journey from entry point to business outcome:
- Lead journey: Landing page, service detail, form submission, confirmation, CRM record, notification, and follow-up automation.
- Purchase journey: Product page, cart, checkout, payment authorization, confirmation, order record, receipt, inventory, and fulfillment notification.
- Account journey: Registration, login, password reset, profile changes, saved information, and logout.
- Content journey: Search, category navigation, internal links, media, downloads, and mobile reading.
Submit valid, incomplete, and invalid form data. Run payments in the processor's approved test mode. Confirm analytics events in a test property or other setup that keeps production reports clean. Check mobile, tablet, and desktop layouts across more than one browser.
Usability needs a separate pass while components are still being migrated. A migration UX study reported an average System Usability Scale score of 75%, with a standard deviation of 11%, during partial migration testing. Use that lesson operationally: observe real tasks before launch, not only after the cutover.
Small businesses should test the full inquiry-to-follow-up path, not just the form button. Record every result, assign each defect to an owner, and require a passing retest. A migration is ready only when checkout, forms, search, login, media, and analytics work together.
6. Update DNS Records and Email Configuration
A DNS change can affect revenue before anyone notices a visual problem. Visitors may reach the wrong server, while email, verification records, order notifications, or inquiry messages continue failing in the background. Treat DNS as a coordinated cutover, not a single website setting.
Start by exporting the current DNS zone or record list. Capture A and CNAME records, MX and TXT records, verification entries, subdomains, CDN settings, and records used by marketing, support, payment, or automation services. Mark each record's owner and purpose so the team can restore the correct value during rollback.
Review the hosting provider's TTL procedure before the launch window. If it recommends lowering TTL, make that change before cutover, then restore the normal value after propagation. The supplied DNS migration guidance specifies 300 seconds, or five minutes, 24 to 48 hours before migration. Schedule this change with the launch checklist and record who approved it.
Protect the mailbox and transaction flow
The website's A record and email's MX records serve different paths. Confirm that MX still points to the active mail service, then review SPF, DKIM, and DMARC. Pay particular attention to changes in transactional sending, marketing automation, or the system that sends inquiry and order messages.
Run these checks from more than one network:
- Website resolution: Test the main domain, key subdomains, and important hostnames.
- Inbound email: Send messages to every published address and confirm delivery.
- Outbound email: Reply from team mailboxes and verify authentication.
- Transactional messages: Trigger inquiry confirmations, order receipts, password resets, and appointment notices.
- Third-party callbacks: Confirm that webhooks and verification services reach the new environment.
Keep the previous DNS values in the rollback record. Log the exact time of each edit, verify propagation, and obtain confirmation from both hosting and email providers. A small business should also assign one person to monitor incoming inquiries during the cutover, because a missed message can become a missed sale.
7. Implement Security Measures and SSL Certificates
Security belongs in the migration plan from the first staging build. A new server with incomplete HTTPS, permissive access, missing firewall rules, or exposed administrative tools can create risk before the public launch even begins.
Install the SSL certificate on the new hosting environment before DNS cutover. Then test the certificate across the primary domain, subdomains, redirects, forms, account areas, and checkout. The site should consistently resolve over HTTPS, and internal resources should also load securely.
Use this explanation of what an SSL certificate does when documenting the certificate, renewal process, and ownership. Don't assume that a certificate installed by the hosting provider removes the need for verification.
Check the security boundary
Review firewall rules, administrative access, malware scanning, file permissions, security headers, backup protection, and server logs. Remove development accounts and temporary credentials. Confirm that staging is not publicly exposed without appropriate access controls.
If the site accepts payments or stores personal information, involve the relevant payment and compliance owners. Confirm that the new checkout, payment pages, integrations, and data handling remain within the required operational and compliance boundaries.
A security review should include:
- HTTPS enforcement: Redirect HTTP requests to the correct HTTPS URL without creating redirect loops.
- Mixed content: Replace insecure scripts, images, fonts, and stylesheets.
- Access controls: Restrict administrative areas and remove unused accounts.
- Monitoring: Configure alerts for suspicious logins, malware signals, and unusual traffic.
- Recovery: Verify that backups are protected and that restoration doesn't reintroduce compromised files.
After launch, review security logs and scan the new environment. Security isn't a one-time migration checkbox. It becomes part of the maintenance process the team documents and assigns.
8. Verify SEO Elements and Implement Canonical Tags
A CMS transfer can preserve visible content while losing the signals that protect search visibility and revenue. Validate titles, meta descriptions, headings, image attributes, canonical tags, structured data, robots directives, and internal links before launch.
Export current metadata, then compare it with the migrated pages. Prioritize pages that generate leads, sales, branded visits, or valuable external links. A service page may look unchanged to customers while its title, canonical URL, or schema markup is missing.
Validate SEO signals in a fixed order
Start with URL targets and crawl controls, then review page markup and discovery files. Structured data should describe the new page accurately. Do not copy schema blindly if the content, business details, products, services, or page type changed. Accurate structured data also supports machine-readable content and AI answer-engine discoverability during the migration, as outlined in this structured data and migration guidance.
Use staging for comparison, then repeat the checks on production:
- Canonical tags: Ensure every indexable page points to its intended preferred URL, not a staging, redirected, or obsolete address.
- Robots.txt: Confirm important pages, assets, and paths remain crawlable.
- XML sitemap: Include only final URLs that should be discovered and indexed.
- Heading structure: Preserve a logical hierarchy for visitors and search engines.
- Structured data: Validate relevant business, product, article, FAQ, or organization markup.
- Internal links: Replace old URLs with direct links to final destinations.
Submit the sitemap in Search Console and review indexing reports. For a domain change, complete the required ownership and change-of-address procedures. Record pre-launch rankings by page and query, then compare them after release.
Early ranking movement can reflect crawling and indexation processing, so check indexed URLs, canonical selection, redirect targets, and organic conversions before changing content. For a small business, this sequence helps distinguish a technical migration issue from a normal search adjustment and protects enquiries or checkout revenue while the new site settles.
9. Conduct Final Testing Before Launch and Set Up Monitoring
The final test should simulate the launch, not merely confirm that the homepage loads. Use a release checklist that covers customer paths, administrative tasks, integrations, performance, SEO, accessibility, security, and reporting.
Test the pages and workflows your business cannot afford to lose. A retailer should run approved test transactions across relevant payment methods. A service provider should submit forms from different devices and confirm that every inquiry reaches the right person. A membership or account-based site should test login, registration, password recovery, and permissions.
Use PageSpeed Insights or GTmetrix for performance checks, then compare results across key templates and device types. Review mobile navigation, sticky elements, pop-ups, buttons, form fields, cookie controls, and tap targets. Test on realistic network conditions where possible.
Put alerts in place before release
Monitoring should be ready before DNS changes. Configure uptime alerts, error tracking, analytics, conversion events, Search Console access, server logging, and payment notifications. Establish a shared launch channel so developers, marketers, business owners, and support staff see the same issue reports.
The final test set should include:
- Navigation: Menus, footer links, breadcrumbs, search, filters, and pagination.
- Conversion paths: Contact, purchase, signup, booking, download, and confirmation steps.
- Technical responses: 200, 301, 404, 410, and server error behavior.
- Tracking: Page views, form starts, submissions, purchases, calls, and campaign attribution.
- Presentation: Mobile, desktop, browsers, images, fonts, video, and accessibility controls.
Use the website redesign checklist to support the broader pre-launch review. Assign a named owner to every unresolved issue. A defect without an owner is a launch risk, regardless of how polished the new design appears.
10. Launch, Monitor Performance, Optimize Post-Migration, and Document the Team
Launch day begins a revenue-protection period, not a handoff. During the first 30 to 60 days, temporary organic traffic declines can occur after same-domain URL restructures, while full domain migrations may suffer larger initial losses. Industry guidance reports 10% to 30% temporary drops for same-domain restructures, 20% to 50% for full domain migrations, and losses of 50% or more after poorly managed moves (migration traffic benchmarks).
Set investigation thresholds before launch. Compare organic traffic, landing pages, leads, purchases, revenue events, conversion paths, rankings, crawl errors, and page experience with the pre-launch baseline. Review the results by template and URL, since an aggregate decline can hide a broken checkout, missing redirect group, or tracking failure.
Make recovery measurable
Plan for recovery without treating any benchmark as a guarantee. Industry guidance indicates that well-managed migrations can return to 90% of pre-migration traffic within 60 to 120 days, while severe problems may delay recovery for 6 to 18 months (recovery expectations). Use these ranges to set review dates, then diagnose affected pages rather than waiting for traffic to return.
Create a daily launch review for the early period, followed by a less frequent cadence once key signals stabilize:
- Search visibility: Check Search Console clicks, impressions, indexing, crawl errors, and priority queries.
- Revenue paths: Verify forms, checkout completion, payment status, calls, bookings, and CRM records.
- User behavior: Review exits, failed searches, support requests, recordings, and mobile friction.
- Technical health: Track uptime, server errors, redirect responses, JavaScript errors, and Core Web Vitals.
- Ownership: Log each fix, its impact, and the person who approves the change.
Keep a migration runbook with the final architecture, redirect map, DNS records, analytics configuration, hosting access, backup procedure, integration contacts, and troubleshooting steps. Train staff who update pages, publish content, manage products, process leads, and restore backups. For a small business, this limits revenue risk when the original developer is unavailable. Recheck the runbook after the first incident and record the lesson for the next release.
10-Step Website Migration Checklist Comparison
| Step / Task | Implementation complexity | Resource requirements | Expected outcomes | Ideal use cases | Key advantages |
|---|---|---|---|---|---|
| Conduct a Comprehensive Site Audit and Inventory | Moderate–High (time‑intensive) | Crawlers, analytics access, SEO/technical expertise, time | Complete page/asset inventory and baseline metrics; risk/opportunity identification | Any migration; critical for small businesses with legacy content | Prevents content loss; reveals optimizations and technical debt |
| Choose the Right CMS Platform and Hosting Solution | Moderate (decision and testing) | Platform evaluations, budget, dev/ops support, performance testing | Platform aligned with scale, SEO, security, cost | New builds or platform migrations, e‑commerce or service sites | Optimizes long‑term performance, maintenance, and conversions |
| Set Up 301 Redirects and URL Structure Mapping | Moderate (technical mapping) | Redirect mapping spreadsheet, redirect tools, QA time | Preserved SEO value; minimized broken links and 404s | Sites with existing organic traffic or URL changes | Maintains rankings and link equity; improves UX |
| Back Up All Data and Create a Rollback Plan | Low–Moderate (procedural) | Backup storage, automated/manual exports, test restores | Reliable recovery points; ability to revert quickly on failure | High‑risk migrations, e‑commerce, sites with critical data | Protects data; reduces downtime and financial impact |
| Migrate Content and Database with Quality Assurance Testing | High (most technical) | Staging environment, developers, QA testers, migration tools | Accurate content transfer; validated functionality and integrations | Large or complex sites, e‑commerce, membership platforms | Minimizes post‑launch issues; preserves conversions and data integrity |
| Update DNS Records and Email Configuration | Moderate (time‑sensitive) | DNS access, coordination with providers, monitoring tools | Traffic routed to new host; uninterrupted email delivery | Host or nameserver changes, migrations with email services | Minimizes downtime; maintains customer communications |
| Implement Security Measures and SSL Certificates | Moderate (config + ongoing) | SSL certs, WAF/firewall, malware scanning, audits, monitoring | Encrypted traffic, threat protection, regulatory compliance | Sites handling payments or personal data, all public sites | Protects user data; improves trust and search ranking |
| Verify SEO Elements and Implement Canonical Tags | Moderate–High (technical SEO) | SEO tools, meta/schema export, dev time, Search Console monitoring | Preserved rankings, correct indexing, reduced duplicate content | Sites reliant on organic search and rich snippets | Prevents ranking loss; improves SERP appearance and CTR |
| Conduct Final Testing Before Launch and Set Up Monitoring | High (comprehensive QA) | Cross‑device testing, performance tools, monitoring/alerting services | Catch critical issues pre‑launch; real‑time error detection post‑launch | All launches, especially revenue‑critical sites | Ensures conversion paths work; enables fast incident response |
| Launch, Monitor Performance, Optimize Post‑Migration, and Document/Train Team | Moderate (ongoing) | Analytics, A/B testing tools, training materials, support time | Stabilized performance, improved conversions, empowered team | Post‑launch operations and continuous improvement phases | Continuous optimization; knowledge transfer and reduced vendor reliance |
Make Migration a Controlled Growth Project
A website migration is complete only when the business can operate safely on the new environment and explain how performance compares with the old one. A polished design, successful file transfer, or working homepage isn't enough. Revenue depends on the connected system, including search discovery, redirects, forms, analytics, checkout, email, DNS, security, hosting, and the team's ability to maintain the result.
Don't switch DNS until the release owner has verified the inventory, backup restoration, staging QA, redirect map, SSL, analytics, Search Console access, payment flows, email delivery, and rollback procedure. Keep the old site and its configuration available until the new environment has passed the agreed monitoring period. Store the final redirect tests, crawl results, DNS records, and launch decisions where the next person can find them.
Set realistic expectations after release. Industry guidance reports that well-managed migrations can recover to 90% of pre-migration traffic in 60 to 120 days, while severe technical problems may extend recovery to 6 to 18 months (migration recovery guidance). A separate large migration study found an average recovery time of 523 days, with 17% of sampled migrations still below their previous organic traffic after 1,000 days (long-term migration benchmark). These findings reinforce one operational point: launch-day checks protect the first stage, but disciplined monitoring protects the months that follow.
Tie success to business outcomes, not rankings alone. A local service company should know whether calls and qualified form submissions continue. An online retailer should verify that products are findable, payments settle, orders enter fulfillment, and revenue attribution remains accurate. A professional firm should confirm that high-value service pages, contact routes, and follow-up workflows work on the devices its prospects use.
When the migration exceeds your internal capacity, MD TECH TEAM can support the connected work across development, hosting, SEO, security, and payment workflows. Its website development service includes backing up the site, moving files to production servers, restoring the database, pointing the domain to the new server, and verifying that the site goes live. A specialist can also help build the redirect map, validate the production crawl, protect analytics, and give your team documented ownership after launch.
Assign one launch-day owner, record your baseline metrics, schedule regular post-launch reviews, and keep a written decision log. That turns migration from a risky handoff into a controlled growth project with clear evidence, clear responsibilities, and a defined response when the new site doesn't behave as expected.
If your business is planning a migration, MD TECH TEAM offers web development, hosting, SEO, security monitoring, and payment workflow support for small and midsize organizations. Visit the team to discuss your current platform, redirect requirements, launch controls, and post-migration growth plan.
