Website migration checklist: everything you need to know

The fear is understandable. The process is manageable.

Website migration anxiety is real. Your current site is live, it works (mostly), customers find you through it, and the thought of breaking something during a migration is enough to keep most business owners on WordPress long past the point where it makes sense. That fear is reasonable: a migration done carelessly can drop pages from Google, break forms, and lose leads for weeks before anyone notices.

But the failures have known causes. The horror stories come from rushed migrations, skipped steps, and missing redirect maps, not from the migration concept itself. A well-planned migration preserves every URL, every page, every SEO ranking, and every integration. Your visitors will notice the speed improvement. They will not notice the platform change.

This checklist is the process MigrateLab follows. It covers everything from the initial audit through 2 weeks of post-launch monitoring, with an extra section for sites leaving Webflow. Use it as a reference whether you are doing the migration yourself, working with us, or evaluating another agency.

Before the migration: planning and audit

Step 1: Audit your current site

Before you can migrate, you need a complete inventory of what exists. This is the most important step and the one most often rushed. A thorough audit covers:

• Page inventory. List every page on your site, not just the main navigation pages, but landing pages, blog posts, legal pages, utility pages (404, search results), and any pages created by plugins. Use Screaming Frog or a sitemap to ensure completeness.

• Content types. Identify all content types: pages, blog posts, case studies, team bios, testimonials, FAQs, product descriptions. Each type may need a different template in the new site.

• Integrations. Document every external service your site connects to: contact forms (where do submissions go?), analytics (Google Analytics, HubSpot), CRM integrations, email marketing (Mailchimp, ConvertKit), chat widgets, payment processors, scheduling tools (Calendly).

• Media assets. Count and catalog your images, videos, PDFs, and downloadable files. Note total file size: large media libraries need a separate migration plan.

• Functionality. List every feature your site provides beyond content display: search, filtering, user accounts, e-commerce, membership areas, calculators, interactive tools.

Step 2: Document all URLs for redirect mapping

This step prevents SEO damage. Every URL on your current site needs to map to a URL on the new site. If a page existed at /services/web-design/ and moves to /services/web-design (note the trailing slash difference), that needs a 301 redirect. If a blog post URL changes from /2024/03/my-post/ to /blog/my-post, that needs a redirect.

Create a spreadsheet with two columns: old URL and new URL. Include every page, every blog post, every media file URL, and every URL that has ever appeared in Google Search Console. This is tedious but critical. A single broken URL can mean lost search traffic for that page.

Step 3: Export all content and media

Extract everything from your current CMS. For WordPress, this means:

• Export all pages and posts as WordPress XML (Tools > Export)

• Download the entire wp-content/uploads directory (all media files)

• Export any custom post types, ACF field data, and WooCommerce products

• Save all plugin configuration settings you will need to replicate

• Export any form submission history you want to preserve

Store this export securely. It is your backup and your source data for content migration. Do not rely on the live site as your data source during migration. Always work from the export. (Leaving Webflow? Its export works differently; see the Webflow checklist below.)

During the migration: building the new site

Step 4: Choose your target stack

The right stack depends on your needs. The most common options:

• Next.js + Tailwind CSS: the most popular choice. Full React framework with server-side rendering, static generation, and API routes. Best for marketing sites, content sites, and applications.

• Astro: excellent for content-heavy sites (blogs, documentation, portfolios). Ships zero JavaScript by default for ultra-fast load times. Supports React, Vue, and Svelte components.

• Remix: great for highly interactive applications with complex data loading patterns. Less common for marketing sites.

For most business websites, Next.js with Tailwind is the standard choice. It has the largest community, the best AI tool support, and the most flexible deployment options.

Step 5: Set up hosting

Modern hosting is dramatically simpler and cheaper than WordPress hosting:

• Vercel: the company behind Next.js. Pro is $20 per user per month. Its Hobby tier is non-commercial only, so it is not an option for a business site built by a developer or agency. Automatic deployments from Git, edge CDN, preview deployments.

• Cloudflare Pages: free tier with unlimited bandwidth and no commercial-use restriction. Built-in CDN, edge functions, analytics.

• Netlify: similar to Vercel, with a free tier that was cut back in April 2026, so check current limits. Good for Astro and static sites.

• VPS (Coolify, Dokku): self-hosted option if you prefer full control. $5-20/month for a VPS.

Step 6: Rebuild the design in code

This is the core of the migration: translating your existing design (or an improved version of it) into code components. Each page becomes a React component. Reusable elements (headers, footers, buttons, cards) become shared components. The design is implemented with Tailwind CSS utilities, ensuring consistent spacing, typography, and responsive behavior.

AI tools like Claude Code accelerate this step significantly. Provide a screenshot or description of a page section, and the AI generates the corresponding code. A skilled developer using AI tools can rebuild a typical 20-page site in 3-5 days.

Step 7: Migrate all content

Content migration is transferring all text, images, and structured data from the WordPress export into the new site. For simple sites, this is manual: copying content into components or a headless CMS. For large content sites (50+ blog posts), automated scripts can parse the WordPress XML export and create entries in the new CMS.

Image migration includes downloading all media, optimizing file sizes, converting to modern formats (WebP, AVIF), and updating all internal image references.

Step 8: Set up 301 redirects

Using the redirect map from Step 2, configure 301 (permanent) redirects for every URL that has changed. In Next.js, redirects are defined in next.config.js or middleware. Test every redirect: each one should return a 301 status code and correctly point to the new URL. Missing or broken redirects are the most common cause of post-migration SEO drops.

Step 9: Reconnect forms, analytics, and CRM

Every integration documented in Step 1 needs to work on the new site:

• Contact forms should submit to the same email address or CRM as before

• Google Analytics (GA4) tracking code needs to be added to the new site

• HubSpot, Mailchimp, or other marketing tools need updated embed codes or API connections

• Chat widgets, booking tools (Calendly), and payment processors need re-integration

• Social media meta tags (Open Graph, Twitter Card) need to be set for sharing

Launch and post-launch

Step 10: Test everything

Before flipping the DNS switch, test comprehensively:

• Every page loads correctly on desktop and mobile

• All forms submit successfully and notifications are delivered

• All images display at correct sizes and resolutions

• Internal links point to correct pages

• External links work and open in new tabs where appropriate

• Lighthouse scores meet expectations (90+ for Performance, Accessibility, SEO)

• The site works correctly with JavaScript disabled (for SEO and accessibility)

• 301 redirects work for every URL in your redirect map

Step 11: DNS switchover

The DNS switch is what makes the new site live. Update your domain's DNS records to point to the new hosting. With proper configuration, this is a zero-downtime operation:

1. Set low TTL (300 seconds) on DNS records 24-48 hours before the switch

1. Update DNS records to point to new hosting

1. Monitor traffic to confirm visitors are reaching the new site

1. Keep the old site accessible (but not public) for 2 weeks as a fallback

DNS propagation typically takes 1-4 hours. During this window, some visitors may see the old site and others the new site. Both should work during this period.

Step 12: Monitor for 2 weeks post-launch

The first two weeks after launch are the monitoring phase. Watch for:

• Google Search Console. Check for crawl errors, indexing issues, and any significant changes in search impressions or clicks. Submit your new sitemap. Monitor for 404 errors that indicate missing redirects.

• Analytics. Verify that traffic levels are consistent with pre-migration levels. If you see a significant drop, check redirects and indexing status immediately.

• Forms and conversions. Confirm that form submissions are arriving and conversion tracking is working. Test every form yourself within the first 24 hours.

• Performance. Run Lighthouse audits weekly. Performance should be significantly better than the old site. If scores are lower than expected, investigate and optimize.

• User feedback. Pay attention to any customer complaints about broken pages, missing content, or navigation issues. Address them immediately.

Leaving Webflow? The extra checklist

Steps 1 to 12 apply to any platform. Webflow adds its own items, because its code export is not a content export and several of its features are tied to Webflow's hosting. Work through these alongside Steps 1, 3, 7, and 8.

Content and CMS

• Don't treat the code export as your content backup. Webflow's code export (it needs a paid Workspace plan) gives you HTML, CSS, JavaScript, Assets-panel images, and empty Collection template pages. It excludes CMS content, User Accounts, Ecommerce, password protection, form submission processing, site search, and non-primary locales.

• Pull CMS content through the Data API. GET /v2/collections/{collection_id}/items returns staged items, including drafts; /items/live returns only what is published. Run both and compare, so drafts don't go live by accident and published items aren't missed. Results are paginated: loop until you have every item. CSV export from each collection is fine as a backup, but the JSON keeps structure better.

• Record each collection's schema. GET /v2/collections/{collection_id} lists every field and its type. Option fields come back as option IDs, so you need the schema to map them back to labels.

• Resolve multi-reference fields in order. A multi-reference field is an array of Webflow item IDs. Import the referenced collections first (authors, categories, tags), build a lookup of old Webflow ID to new ID, then write the relationships. Check that the order of each array survives if it controls display order.

• Parse rich text, don't paste it. Rich text fields are HTML with Webflow's own wrappers for embeds and figures (w-embed, w-richtext-figure-type-image). Convert them into your new editor's format and check embedded video and custom code blocks by hand.

Assets

• Find every Webflow-hosted URL. CMS image fields, rich text, and Open Graph images point to Webflow's CDN (cdn.prod.website-files.com, and on older projects uploads-ssl.webflow.com). Download every file, re-host it, and rewrite the references.

• Grep the finished build for those hostnames before launch. Any match is an image that will depend on your Webflow project staying alive.

Features that don't come with you

• Interactions. IX2 interactions run from webflow.js in the export, but they are stored as runtime data tied to data-w-id attributes, so they can't be edited outside the Designer. Catalogue each one (scroll, hover, page load, click) and decide to rebuild it in CSS or a motion library, simplify it, or drop it.

• Memberships / User Accounts. Webflow sunset User Accounts on 2026-01-29, so any gated content using it has already lost that feature. If you replaced it with a third-party tool, plan that tool's login and user data as its own migration. See the Webflow Memberships migration guide.

• Editors and roles. The legacy Editor was retired on 2026-08-04 and users were moved to the Content editor role automatically. List who edits what today, so you can recreate those accounts and permissions in the new CMS. Agencies that relied on whitelabeled Editor branding lost it on that date.

• Forms. Webflow form processing does not leave Webflow. Rewire every form to its new endpoint, and export your existing submissions from Webflow before you cancel.

• Ecommerce. Webflow Ecommerce is still a live product but it is not in the code export. Scope it separately; see the Webflow ecommerce migration guide.

Redirect map

• Export Webflow's existing 301 redirects from Site settings and carry them into the new map. Flatten chains so an old URL goes straight to its final destination, not through two hops.

• Map CMS paths. Webflow serves Collection items at /{collection-slug}/{item-slug}. If the new site uses /blog/{slug}, every item needs a rule.

• Include localized paths (for example /fr/...) if you use Webflow Localization.

• Keep the Webflow site plan active for at least 30 days after launch, so you can point DNS back if something goes badly wrong.

How long the checklist takes

Worked through by one person, one step at a time, a 10 to 30 page business site with a blog and standard integrations commonly takes several weeks: a week of audit and redirect mapping, then the rebuild and content migration, then integrations and testing, then launch. A 100-page site with WooCommerce can stretch to a month or more that way.

A dedicated team runs Steps 1 to 10 in parallel instead of in sequence. MigrateLab is a fast migration agency: most sites go live in 7 to 14 days, and large CMS sites (hundreds of items, ecommerce or localization) take 3 to 4 weeks. The 2 weeks of monitoring in Step 12 come after that, on the live site.

What a good migration preserves

When a migration is done right, nothing is lost:

• Every page and piece of content is preserved or improved

• Every URL either stays the same or has a proper 301 redirect

• SEO rankings are maintained, with Core Web Vitals improvements as a ranking signal working in your favour

• All integrations (forms, analytics, CRM) continue to work

• The design looks the same or better, and loads faster

The fear of migration is valid. The risk, when following a disciplined process, is minimal. The reward (faster performance, lower costs, better security, and AI editability) lasts for years.