Website Migration: Planning and Execution

Understanding Migration Types

Not all website migrations are created equal. A simple hosting change is very different from a complete platform rebuild. Understanding what type of migration you're undertaking determines your planning requirements.

Common Migration Types

• Hosting migration: Same site, different server. Lowest risk if DNS is handled properly.
• Domain migration: Moving to a new domain name. Significant SEO implications.
• Platform migration: Changing CMS (e.g., Drupal to WordPress). High complexity.
• Design migration: New look, same platform. Moderate complexity.
• Structure migration: Reorganizing URL structure and information architecture. High SEO risk.
• HTTPS migration: Moving from HTTP to HTTPS. Well-documented process.
• Consolidation: Merging multiple sites into one. Complex redirect mapping.

Pre-Migration Planning

Thorough planning prevents disasters. Don't skip these steps:

Content Audit

Know what you're migrating:

• Crawl the existing site (Screaming Frog, Sitebulb, or similar)
• Export full list of URLs with traffic data from analytics
• Identify high-value pages (traffic, conversions, backlinks)
• Flag content to retire vs. migrate vs. consolidate
• Document current URL structure patterns

Technical Inventory

Understand current technical state:

• Current hosting environment and requirements
• Existing integrations (CRM, email, analytics, etc.)
• Forms and their destinations
• Third-party scripts and tracking codes
• Authentication systems
• CDN and caching configuration

SEO Baseline

Document current search performance:

• Current rankings for important keywords
• Organic traffic levels by page
• Backlink profile (export from Ahrefs, Moz, or Search Console)
• Indexed page count
• Core Web Vitals scores

Redirect Strategy

Redirects are the backbone of successful migration. Get this wrong and everything else is moot.

Redirect Mapping Process

1. Export all existing URLs

   Crawl the site and combine with analytics data to ensure you have every URL that receives traffic or has backlinks.

2. Define new URL structure

   Document exactly what the new URLs will look like. Be specific about patterns and conventions.

3. Create mapping spreadsheet

   Old URL → New URL for every single page. Yes, every single one. Use formulas where patterns exist.

4. Handle special cases

   Pages being deleted, merged, or significantly changed need individual attention.

5. Generate redirect rules

   Convert mapping to actual redirect configuration (.htaccess, nginx conf, or plugin settings).

6. Test before launch

   Verify redirects work correctly on staging. Spot-check doesn't cut it—test all of them.

Redirect Types

• 301 (Permanent): Use for most migrations. Passes link equity.
• 302 (Temporary): Only for genuinely temporary moves. Doesn't pass full link equity.
• Avoid chains: A → B → C redirects lose equity at each hop. Go directly A → C.

What to Redirect

• All pages receiving organic traffic
• All pages with external backlinks
• All pages linked internally
• Common typo variations of important URLs
• Old URLs that might be bookmarked

Staging and Testing

Never migrate directly to production. Ever. Full staging and testing is non-negotiable.

Staging Environment Requirements

• Matches production environment as closely as possible
• Blocked from search engine indexing (robots.txt + meta tags)
• Password protected or IP restricted
• Uses test versions of third-party integrations
• Has representative sample of content (or full content)

Testing Checklist

• Functionality: All features work (forms, search, e-commerce, login)
• Content: All content migrated correctly, images display, links work
• Redirects: Every mapped redirect resolves correctly
• SEO elements: Titles, meta descriptions, canonical tags, schema
• Performance: Page speed acceptable, no major regressions
• Mobile: Responsive design works across devices
• Accessibility: WCAG compliance maintained or improved
• Analytics: Tracking fires correctly on all pages
• Integrations: All third-party connections functional

User Acceptance Testing

Involve stakeholders beyond the web team:

• Have content owners review their sections
• Test conversion paths end-to-end
• Verify business-critical workflows
• Get sign-off before proceeding to launch

Launch Execution

Launch day requires careful coordination. Here's a typical sequence:

1. Final pre-launch checks

   Verify staging is ready, team is available, and rollback plan is documented.

2. Enable maintenance mode

   Prevent content changes during migration if database is involved.

3. Execute migration

   Deploy new site to production. Method depends on your setup (DNS switch, file deployment, etc.).

4. Implement redirects

   Activate redirect rules. Verify they're working immediately.

5. Update DNS (if applicable)

   Point domain to new hosting. Allow for propagation time.

6. Verify critical paths

   Immediately test homepage, key landing pages, conversion paths, and forms.

7. Monitor for errors

   Watch server logs, analytics, and Search Console for issues.

8. Update external references

   Google Business Profile, social profiles, email signatures, etc.

Timing Considerations

• Day of week: Tuesday-Wednesday preferred (time to fix issues before weekend)
• Time of day: Low-traffic hours for your audience
• Business calendar: Avoid peak seasons, product launches, or major campaigns
• Team availability: Ensure key people aren't on vacation

Post-Launch Monitoring

Migration isn't complete at launch—it's complete when metrics stabilize and issues are resolved.

First 24-48 Hours

• Monitor server error logs continuously
• Watch real-time analytics for anomalies
• Check Search Console for crawl errors
• Test key conversion paths multiple times
• Respond quickly to user-reported issues

First Week

• Compare traffic to baseline (expect some fluctuation)
• Review 404 error reports and add missing redirects
• Monitor Core Web Vitals for performance issues
• Check that Google is crawling and indexing new URLs
• Verify all forms are receiving submissions

First Month

• Track ranking changes for important keywords
• Monitor organic traffic trends
• Review conversion rate changes
• Address any lingering technical issues
• Document lessons learned for future migrations

Key Metrics to Track

Common Pitfalls

Learn from others' mistakes:

Technical Pitfalls

• Incomplete redirects: Missing even 10% of pages causes significant issues
• Redirect chains: Old → Intermediate → New loses link equity
• Mixed content: HTTP resources on HTTPS pages cause security warnings
• Canonical errors: Wrong canonical tags confuse search engines
• Robots.txt blocking: Accidentally blocking crawlers post-launch
• Broken internal links: Links pointing to old URLs instead of new

Process Pitfalls

• Insufficient testing: "It worked on staging" isn't enough
• No rollback plan: Stuck when things go wrong
• Poor communication: Stakeholders surprised by changes
• Inadequate timeline: Rushing causes mistakes
• Single point of failure: Key person unavailable at critical moment

Setting Expectations

Website migrations are inherently risky. Even with perfect execution, expect:

• Some temporary ranking fluctuation (typically 2-8 weeks)
• Minor issues discovered post-launch (there are always some)
• User adjustment period for design or structure changes
• More time required than initially estimated

The goal isn't a flawless migration—it's a well-managed migration where issues are anticipated, quickly identified, and promptly resolved. Thorough planning, comprehensive testing, and vigilant monitoring make that possible.

When done well, migrations create opportunities: better performance, improved user experience, and a foundation for future growth. The effort is worth it—just don't underestimate what's involved.