[ ] Build on a staging environment, not production. The new site should be fully built and tested before anyone outside the project team sees it. Use a staging URL or temporary domain. [ ] Match the production server environment. PHP version, server configuration, memory limits, and SSL configuration should mirror what the live site will run on.

[ ] Implement the complete 301 redirect map. Every old URL that changes needs a permanent redirect to its new location. Use the Redirection plugin or server-level .htaccess rules. [ ] Avoid redirect chains. A single 301 redirect passes roughly 85% of link equity. Chain two together and you're losing significantly more. Every URL should redirect directly to its final destination. [ ] Test redirects before launch. Verify each redirect works correctly on the staging environment.

[ ] Test every page template. Don't just test the homepage. Test every unique template type: service pages, blog index, single posts, archives, category pages, and landing pages. [ ] Cross-browser testing. Chrome, Firefox, Safari, Edge. Desktop and mobile. [ ] Performance testing. Run Core Web Vitals tests. Compare against the pre-migration baseline. [ ] Accessibility check. Verify the new site maintains or improves accessibility standards. [ ] For associations: Test the member portal, login process, member-only content access, donation forms, event registration, and any CRM or AMS integration. These are complex systems that require thorough verification.

WordPress Migration Checklist: The Complete Pre, During, and Post-Migration Guide

Q: Theme and Functionality

[ ] Build or configure the WordPress theme. For platform migrations, this means a custom theme that recreates the current design. For WordPress-to-WordPress moves, this may mean updating or replacing the existing theme. [ ] Install and configure all required plugins. SEO plugin (Yoast is our standard), forms, caching, security, backup, and any functionality-specific plugins. [ ] Recreate all integrations. CRM, email marketing, analytics, and payment processing. Test each one individually.

Q: Content Migration

[ ] Migrate content methodically. For platform migrations, this is typically manual: copying and pasting content while cleaning up formatting, heading structure, and technical SEO as you go. "We're going to put eyes on every page and think about its technical SEO structure. We're not going to change content, and we're not going to make judgments about it. However, since we're copying and pasting it over anyway, we're going to set all the headings to best practice." [ ] Verify all media files. Every image, PDF, video embed, and downloadable file needs to be on the new site. Check that images have proper alt text. [ ] Verify internal links. Links between pages should point to the new URLs, not the old ones. Broken internal links create crawl issues that compound over time. [ ] Migrate or recreate forms. Test every form submission. Verify notifications reach the correct recipients.

Most WordPress migration checklists give you a list of technical tasks: back up your site, install a plugin, test your links. That's fine for a simple hosting move, but it's not how a professional migration actually works.

A real WordPress migration checklist starts with a conversation, not a command line. It accounts for the people who use the site, the marketing team that depends on its traffic, and the organization that must keep operating while everything changes beneath them.

This website migration checklist is based on how we actually scope and execute migrations at FatLab. It covers platform migrations (moving from Drupal, Squarespace, Sitecore, or another CMS to WordPress), WordPress-to-WordPress rebuilds, and hosting migrations.

Not every item applies to every project, but every item exists because we've seen what happens when it gets skipped.

Before You Start: The Discovery Conversation

The biggest mistake in any migration is jumping straight to execution. Before anyone writes a line of code or installs a plugin, you need to understand what you're actually dealing with.

"The only question I'm asking a client up front is: 'What does your website do?'"

That sounds obvious. Every website has pages, content, and a contact form.

But what we're listening for are the things that complicate the project: the e-commerce system, the membership portal, the custom calculator built years ago, the SSO integration, and the third-party APIs.

"When we get to the end of that part of the conversation, I say: 'Now, do you have any surprises for me?' ... This is the time to tell me that deep inside your website, someone decided that selling T-shirts was a good idea."

You'd be surprised how often that question surfaces a PayPal integration, a members-only video library, or an event registration system that nobody mentioned during the initial conversation.

These "surprises" blow up timelines and budgets if they're discovered mid-migration rather than during planning.

Two professionals discussing a wordpress migration checklist during a discovery meeting with a laptop open between them

Phase 1: Pre-Migration (Your Website Migration Checklist Starts Here)

Site Inventory

[ ] Run a Screaming Frog crawl of the entire current website. This reveals every page, every URL, every linked asset. Crawlers are effective at finding things three or four links deep that nobody remembers exist.
[ ] Run a Google site:domain.com search to see how many pages are in Google's index. Compare this to your crawl results. Discrepancies reveal pages that are indexed but not linked internally, or pages that exist but aren't being crawled.
[ ] Inventory unique page templates. Homepage, service pages, about pages, blog index, single post template, archive pages, landing pages. Each unique design requires a template in the new WordPress theme.
[ ] Inventory features and functions. Carousels, sliders, custom calculators, animated elements, search functionality, filtering systems, interactive tools. Every feature needs a WordPress equivalent.
[ ] Count content volume. Number of pages, number of posts, number of custom post types, number of media files, number of downloadable assets (PDFs, documents). This determines the labor required for content migration.
[ ] Document all third-party integrations. CRM connections, email marketing platforms, analytics tools, payment processors, social media feeds, chat widgets, and scheduling tools. Each one needs to be reconnected to the new site.

SEO Baseline

[ ] Document current search rankings for your most important keywords. Use Google Search Console, a rank tracking tool, or manual searches.
[ ] Record traffic data. Monthly visitors, top landing pages, top organic queries. Take a screenshot of your Google Analytics and Search Console dashboards.
[ ] Map all URLs. Create a spreadsheet matching every current URL to its planned URL on the new site. This becomes your redirect map. Every URL matters. Industry data shows only about 10% of migrations actually improve SEO, and 50% of poorly executed migrations result in significant traffic loss.
[ ] Document current meta titles and descriptions. These need to be transferred to the new site if you're using Yoast, Rank Math, or another SEO plugin, export that data.
[ ] Catalog current structured data (Schema markup). Rich snippets, organization schema, FAQ schema, breadcrumbs. This needs to be recreated on the new site.
[ ] Lower DNS TTL to 60-300 seconds 48-72 hours before the planned cutover. This ensures faster DNS propagation when you switch.

Stakeholder Communication

[ ] Notify the marketing team. If someone other than the migration team handles marketing, they need to know. A temporary dip in SEO is normal, even with perfect execution. If they hear about it for the first time when traffic drops, you'll get a panicked email.

"If we don't consult with them and tell them that they need to let their marketing department know, their consultants know, that they're going to be doing this, we're going to get a really nasty email from someone when they see this drop in traffic."

[ ] Align on scope. A migration is not a redesign. The current website is the design scope. If design changes are wanted, they should be planned as a separate phase after the migration stabilizes.

"We're going to write a really tight scope. It's not going to be a redesign."

[ ] Set expectations about the SEO dip. Even with every redirect in place and every page perfectly mapped, there will be a temporary decline in search visibility. Google sees the structural change, re-evaluates the site, and traffic dips for a few weeks before recovering.

"Even though you've already set all your 301s and you've ensured everything is mapped appropriately and optimized, Google does see the structure change. It sees the markup. And that little shift is going to force Google to kind of think about the website, re-evaluate it."

[ ] Plan compensating marketing. During the weeks following launch, increase other marketing activities: social media posting, email campaigns, paid ads if appropriate. This offsets any temporary dip in organic traffic.
[ ] For associations and nonprofits: Communicate with your membership about upcoming changes. If the member portal experience will change, prepare documentation and support resources in advance.

A developer working on a staging website build on a large monitor in a clean workspace as part of a site migration process

Scope and Budget

[ ] Define what's being migrated and what's not. For large sites with thousands of pages, this is the time to discuss archiving outdated content rather than migrating everything. Not every page deserves a new home.
[ ] Get the "surprises" out early. Ask specifically about hidden functionality: e-commerce, event registration, donation processing, gated content, user accounts, API integrations. Every undiscovered feature adds scope.
[ ] Understand the cost of waiting. If you're on a platform that's causing ongoing problems, those problems aren't free.

"I understand that you may not have the budget today for a full rebuild, but the problem is you're spending the same amount of money moving forward."

Organizations that delay migration due to budget constraints often spend the equivalent amount on support tickets, workarounds, and staff frustration over the following year.

Migration is a multi-week to multi-month project, depending on size. Plan for it and budget for it.

Phase 2: WordPress Site Migration Steps During the Move

Staging Environment

[ ] Build on a staging environment, not production. The new site should be fully built and tested before anyone outside the project team sees it. Use a staging URL or temporary domain.
[ ] Match the production server environment. PHP version, server configuration, memory limits, and SSL configuration should mirror what the live site will run on.

Theme and Functionality

[ ] Build or configure the WordPress theme. For platform migrations, this means a custom theme that recreates the current design. For WordPress-to-WordPress moves, this may mean updating or replacing the existing theme.
[ ] Install and configure all required plugins. SEO plugin (Yoast is our standard), forms, caching, security, backup, and any functionality-specific plugins.
[ ] Recreate all integrations. CRM, email marketing, analytics, and payment processing. Test each one individually.

Content Migration

[ ] Migrate content methodically. For platform migrations, this is typically manual: copying and pasting content while cleaning up formatting, heading structure, and technical SEO as you go.

"We're going to put eyes on every page and think about its technical SEO structure. We're not going to change content, and we're not going to make judgments about it. However, since we're copying and pasting it over anyway, we're going to set all the headings to best practice."

[ ] Verify all media files. Every image, PDF, video embed, and downloadable file needs to be on the new site. Check that images have proper alt text.
[ ] Verify internal links. Links between pages should point to the new URLs, not the old ones. Broken internal links create crawl issues that compound over time.
[ ] Migrate or recreate forms. Test every form submission. Verify notifications reach the correct recipients.

Redirect Mapping

[ ] Implement the complete 301 redirect map. Every old URL that changes needs a permanent redirect to its new location. Use the Redirection plugin or server-level .htaccess rules.
[ ] Avoid redirect chains. A single 301 redirect passes roughly 85% of link equity. Chain two together and you're losing significantly more. Every URL should redirect directly to its final destination.
[ ] Test redirects before launch. Verify each redirect works correctly on the staging environment.

QA and Testing

[ ] Test every page template. Don't just test the homepage. Test every unique template type: service pages, blog index, single posts, archives, category pages, and landing pages.
[ ] Cross-browser testing. Chrome, Firefox, Safari, Edge. Desktop and mobile.
[ ] Performance testing. Run Core Web Vitals tests. Compare against the pre-migration baseline.
[ ] Accessibility check. Verify the new site maintains or improves accessibility standards.
[ ] For associations: Test the member portal, login process, member-only content access, donation forms, event registration, and any CRM or AMS integration. These are complex systems that require thorough verification.

Phase 3: Launch

[ ] Do a final content sync. If the live site received updates during the migration period, capture and migrate those changes.
[ ] Update DNS records. Point your domain to the new server.
[ ] Verify SSL certificate. Confirm HTTPS works correctly with no mixed content warnings.
[ ] Submit updated XML sitemap to Google Search Console.
[ ] Monitor DNS propagation. Use a DNS checker to confirm the change is rolling out globally.
[ ] Verify the site is live and functional. Load the site from multiple devices and locations. Test critical functionality: forms, checkout, login.
[ ] Do NOT cancel the old hosting yet. Keep it active.

Phase 4: Post-Migration

This is the phase that most migration guides skip entirely. It's also the phase that determines whether your migration succeeds or becomes a source of ongoing problems.

The Overlap Period

[ ] Maintain access to the old system for one to two weeks. Don't shut down the old site or cancel the old hosting immediately after going live.

"We always like to have overlap. It's always good to have that archive for as long as we can."

Once the entire organization starts using the new site, issues surface that weren't visible during QA. A page that was missed, an attachment that didn't transfer, a feature that works differently than expected.

Having the old site available as a reference makes resolving these issues straightforward rather than arduous.

SEO Monitoring

[ ] Monitor Google Search Console daily for the first 4 weeks. Watch for crawl errors, indexing issues, and traffic changes.
[ ] Check for 404 errors. New 404s indicate URLs that need redirects you may have missed.
[ ] Verify redirects are working in production. Test your redirect map against the live site.
[ ] Watch search rankings for your priority keywords. Expect some fluctuation. A temporary dip is normal. A sustained drop of more than 30% after 4 weeks indicates a problem that needs investigation.

"A migration, though it is a disruption, should only improve SEO."

The goal is for any dip to be temporary and for the long-term trajectory to be upward, especially if the new site improves the technical SEO of the old one.

Staff Training

[ ] Train content administrators on the new CMS. This is not optional, and it's not something you can hand off with a quick walkthrough. A new WordPress site, even one that looks identical to the old one, is a completely different system underneath. The way you edit pages, upload media, manage menus, and update content is different.
[ ] Document common administrative tasks. How to add a blog post. How to update a page. How to upload a file. How to manage menus. Written documentation prevents the same questions from being asked repeatedly.
[ ] Identify new administrators. People who weren't involved in the migration project will need training too. Sometimes this comes months after launch.

Stabilization

[ ] Let the migration settle before making changes. Resist the urge to start redesigning pages, adding new features, or restructuring content in the first few weeks.

"We like to let that kind of just sit and chill for a few weeks before we start making any major changes, if we can."

You've just completed a major project. The priority is to confirm that everything works correctly, not to layer additional changes on top of an unstable foundation.

Design enhancements, new features, and content restructuring should be scoped as follow-up projects once the migration has fully stabilized.

[ ] Continue compensating marketing activities. Keep up the increased social media, email campaigns, and other marketing for at least 4-6 weeks post-launch to offset any organic traffic dip.

Ongoing Care

[ ] Ensure someone is responsible for WordPress maintenance. Software updates, security monitoring, backups, performance optimization. WordPress is not a set-it-and-forget-it platform.

"Once the flip is switched and the new WordPress site is live, that's when we as a support and maintenance company thrive."

This is where the difference between a migration agency and a long-term WordPress partner becomes clear. A migration agency hands you the keys and moves to their next project. They've delivered what was scoped.

But the site needs ongoing attention: WordPress core updates, plugin updates, security patches, performance monitoring, and support when something doesn't work as expected.

The migration is the beginning of the site's life on WordPress, not the end of a project.

Association and Nonprofit-Specific Items

If you're an association or nonprofit, add these to your checklist:

[ ] Member portal testing. Verify member login, account management, member-only content access, and membership level permissions.
[ ] CRM/AMS integration verification. If your membership management system connects to your website, test that integration thoroughly. Data should sync correctly in both directions.
[ ] Donation system testing. Process test transactions through every donation pathway. Verify recurring donation management works.
[ ] Event registration testing. If your site handles event registrations, test the full registration flow, including payment processing and confirmation emails.
[ ] Member communication plan. Notify members before the switch. Provide instructions for any changes to login procedures. Have support available for the first week.
[ ] Board and leadership notification. Keep organizational leadership informed about the timeline, expected disruptions, and what "success" looks like for the migration.

The Uncomfortable Truth About Timing

Every organization that needs a migration wishes it had started sooner. The decision to migrate is never urgent until the old platform breaks, a security vulnerability is discovered, or the vendor announces the end of life.

"It's not something you can decide to do after everything breaks and do super fast. It is definitely something you should plan for. It's something you should budget for."

A professional migration can take weeks to months, depending on the site's size and complexity. The WordPress site migration steps include discovery, planning, development, content migration, testing, launch, and stabilization.

Rushing any of those phases increases risk.

If you're starting to feel that your current platform isn't working, that's the signal to begin exploring migration. Not when it fails catastrophically. Not when the license renewal invoice arrives. Not when the EOL announcement drops.

Using This WordPress Migration Checklist

This WordPress migration checklist is comprehensive by design. A simple hosting migration won't require every item. A complex platform migration from Drupal or Sitecore will require all of these, and possibly more specific to your integrations.

The items that competitors consistently skip, and that we consider non-negotiable:

The discovery conversation. Not just a technical audit, but a real conversation about what the site does and what surprises are hiding.
Stakeholder communication. Marketing teams, SEO consultants, and organizational leadership. Everyone who will be affected needs to know in advance.
The overlap period. Keeping the old system available after launch.
Staff training. Real documentation and training, not a "here's your login" email.
Stabilization before enhancement. Letting the migration settle before piling on changes.
Ongoing care. The migration is the beginning, not the end.

For more context on any of these phases, the WordPress migration services hub covers the full picture. If you need to clone your existing WordPress site during the migration process, we've covered that too. For platform-specific guidance on migrating to WordPress from another CMS, we've written detailed guides on Drupal, Sitecore, Umbraco, Shopify, Magento, Squarespace, and Wix.