What's the most common thing that breaks during a website migration?

Forms. Contact forms, email capture, booking requests, these are tied to the old platform's form handler and don't carry over. On launch day, forms often look correct but submissions don't arrive anywhere. Always test forms before DNS cutover. Second most common: tracking scripts (Google Analytics, Facebook pixel, etc.) that don't get reinstalled. Third: embedded widgets (calendars, chat boxes, video players) that need to be reconfigured.

Will my contact form still work after I move my website?

Not automatically. Contact forms are almost always tied to the source platform's backend, Squarespace forms send via Squarespace's servers, Webflow forms via Webflow's, etc. When you move, the form HTML might copy over but submissions go nowhere. Forms need to be replaced on the new platform: either using the new platform's form handler, a third-party service (Formspree, Web3Forms, Basin), or a custom serverless function. Test thoroughly on staging before cutover.

What about my blog posts when I change platforms?

Text content (titles, body, dates) usually transfers cleanly if the source platform has a reasonable export. Images often need to be downloaded and re-uploaded separately (Squarespace, Wix, and Webflow all have weak media export). Categories and tags transfer with most platforms. What tends to break: inline embeds (YouTube videos, social posts, custom blocks), formatting specific to the old platform's editor, and internal links that reference old URL structures.

Will my ecommerce store survive a website migration?

Only partially. Product data (names, prices, descriptions, images) usually exports to CSV or similar formats. Order history, customer accounts, and saved payment methods are much harder to migrate and sometimes impossible without custom work. Cart and checkout flows need to be rebuilt on the new platform. Shipping, tax, and payment processor configurations all need reconfiguring. Treat ecommerce migrations as separate projects with their own timelines.

Do my Google Analytics and tracking pixels transfer during a migration?

No. Tracking scripts are pieces of code embedded in the site's HTML. They don't transfer automatically, you (or the migration team) need to reinstall each one on the new site. Common scripts to reinstall: Google Analytics (GA4), Google Tag Manager, Facebook/Meta pixel, LinkedIn insight tag, Hotjar, any heatmap tools, any A/B testing tools. Verify each one is firing correctly after launch before considering the migration complete.

Do custom domains break when you move a website?

The domain itself is portable and doesn't break. What changes is where the DNS points. During migration, you update A or CNAME records to point at the new host, and within minutes to hours the domain resolves to the new site. Email is a common gotcha, if you change DNS without preserving MX records, email stops working. Document every DNS record before making changes.

What happens to my SEO and rankings during a website move?

Rankings transfer cleanly if the migration preserves URLs, implements 301 redirects for any changed URLs, keeps meta titles and descriptions, and preserves schema markup. They drop if any of those are missed. The biggest cause of post-migration ranking drops isn't the move itself, it's specific technical failures (usually missing redirects) that are preventable with a pre-launch checklist. See the SEO rebuild guide for the full breakdown.

Can I move my website without users noticing?

Usually yes, if the migration is done properly. With a low-traffic cutover window, DNS pre-propagation, and a rollback plan, most small business migrations happen without visitors noticing anything more than a brief delay. If forms, tracking, or integrations break, users will notice, which is why testing on staging before cutover matters. Plan cutover for your quietest window (typically weekday evenings or weekend mornings for small business sites).

What breaks during a WordPress migration specifically?

Plugins don't transfer automatically between hosts, they need to be reinstalled and reconfigured on the new site. Custom fields and custom post types migrate if you export via WXR and the new platform supports them. Page builder content (Elementor, Divi, WPBakery) often doesn't transfer cleanly and may need manual rebuilding. Cached pages need regenerating on the new host. Members, comments, and user-generated content require specific migration steps.

What should I check before I migrate my website?

Inventory every page, form, integration, and tracking script. Document every DNS record. List all plugins or third-party services the site depends on. Note any platform-specific features you use (Member Areas, Scheduling, Commerce extras). Export all content while you still have access to the old platform. Download all images and media separately (exports rarely include these). Get a complete Google Search Console report of indexed pages before migrating. All of this takes 2–4 hours and prevents most surprises.

What actually breaks when you move a website to a new platform?

Before you commit to moving a website, it’s worth knowing what tends to break, and how to tell which of those apply to your specific site. Most “my migration was a disaster” stories trace to predictable, preventable issues that were invisible until launch.

This guide walks through the five categories of things that commonly break, how to audit your current site for each, and what to handle before the new site goes live.

Short answer

The things that commonly break during a website migration:

Forms, they look fine on the new site but submissions don’t arrive
Tracking scripts, Google Analytics, Facebook pixel, etc., silently not installed
Third-party integrations, booking tools, chat widgets, embedded media
Platform-specific features, Member Areas, Scheduling, custom commerce
SEO, if 301 redirects, metadata, or schema aren’t preserved

Each is preventable with a pre-migration audit. Sites that go wrong are almost always the ones that skipped the audit.

1. Forms

The single most common breakage. Contact forms, email capture forms, booking request forms, quote forms, these all tend to be tied to the source platform’s backend.

What happens: The HTML form element might copy over to the new site looking correct. But the submit endpoint is still pointing to the old platform’s form handler, which either fails or goes to someone else’s inbox. On some platforms, the new site strips the form entirely and leaves a broken placeholder.

How to fix: Replace forms on the new platform before launch. Options:

Platform’s native form handler. If the new platform has forms (most do), use those.
Third-party form service. Formspree, Web3Forms, Basin, or Basin handle submissions and forward to email.
Serverless function. A small script on Cloudflare Pages or Netlify that processes the form and sends email via a transactional service.

Testing matters. Submit the form with real data. Verify the email arrives. Test from mobile. Confirm spam protection works. Every single form on the site needs this treatment.

2. Tracking scripts and analytics

Every bit of tracking code you’ve added to the site over the years, Google Analytics, Google Tag Manager, Facebook Pixel, LinkedIn Insight Tag, Hotjar, Microsoft Clarity, chatbot scripts, A/B testing tools, lives in the HTML of the current site. None of it transfers automatically.

What happens: Site looks fine on launch day. A week later, someone notices traffic reports are empty. Conversions aren’t being attributed. Retargeting campaigns stop working because pixels aren’t firing.

How to fix: Audit every script on the current site before migration. Document each one: what it is, where it’s installed, what data it captures. Re-install each on the new site. Verify each is firing correctly using each tool’s own debugger (GA4 real-time, Facebook Pixel Helper, LinkedIn Insight Tag debugger).

Common scripts to audit:

Analytics (GA4, Plausible, Fathom, Matomo)
Tag manager (Google Tag Manager, Tealium)
Ad pixels (Meta, LinkedIn, Twitter, Google Ads)
Heatmaps and session recording (Hotjar, Clarity, FullStory)
Chat widgets (Intercom, Drift, Crisp)
A/B testing (Google Optimize is gone, but Optimizely, VWO, Convert remain)

3. Third-party integrations

Beyond tracking, most websites have embedded features from third-party services: calendar bookings, chat widgets, testimonial tools, review collectors, payment forms, event registrations, newsletter signup forms linked to Mailchimp or ConvertKit.

What happens: These often look like regular content blocks in the source platform’s editor but are actually iframe or script embeds. On migration, the embeds may strip out, display wrong, or lose their configuration.

How to fix: List every third-party integration. For each:

Identify the embed code or integration method
Re-add it to the new site
Test it end-to-end (not just that it renders, actually go through the flow)

Common integrations to audit:

Booking and scheduling. Calendly, Acuity, SavvyCal, Squarespace Scheduling
Email capture. Mailchimp embedded forms, ConvertKit forms, MailerLite widgets
Reviews and testimonials. Testimonial.to, Senja, Trustpilot widgets
Payment forms. Stripe Payment Links, PayPal buttons
Chat. Intercom, Drift, Crisp, Tidio
Social proof. Use Proof, Nudgify
Video. Wistia players (YouTube usually survives better)
Maps. Google Maps embeds (usually survive; check API keys)

4. Platform-specific features

This is where migrations get ugly. If your current site uses platform-specific features, Member Areas, Scheduling, Commerce with specific configurations, those features don’t exist on the new platform and can’t transfer.

What happens: The feature was load-bearing on the old site. On the new site, it’s either gone or needs to be rebuilt with a different tool. The replacement might not have feature parity, and users who relied on the old feature need to be migrated (memberships, saved payment methods, booking history).

How to handle: Decide before migrating whether the feature is actually worth keeping:

Member Areas / memberships. Replacements: Memberstack, Outseta, Ghost (for content-led), Circle (for community). All require manual re-onboarding of existing members.
Scheduling / bookings. Replacements: Calendly, SavvyCal, Cal.com. Existing bookings usually don’t migrate, users need to re-book.
Commerce with custom configs. If you’re using platform-specific product variants, subscription logic, or fulfillment integrations, the replacement platform (usually Shopify) needs to be configured to match, and existing customer accounts and order history may need custom import scripts.
Custom forms with conditional logic. If your form logic is complex (e.g., show these fields only if X is selected), document the logic and rebuild on the new stack.

For small business migrations, these features are often the reason to stay on the current platform rather than migrate. If you use Squarespace Scheduling heavily, the time cost of replacing it may outweigh the benefit of leaving Squarespace. This is worth evaluating before committing.

5. SEO

Covered in depth in the SEO rebuild guide. The short version:

301 redirects from every old URL to its new counterpart. This is the biggest single factor.
Meta titles and descriptions preserved or intentionally improved.
Schema markup re-implemented as JSON-LD.
Sitemap submitted to Google Search Console after launch.
Internal links updated to point at new URLs, not through redirects.

These are preventable failures, not inherent risks of migration.

What tends to NOT break (when done properly)

To put the breakages in context, plenty of things transfer cleanly:

Text content, blog posts, page copy. Exports via WXR (Squarespace, WordPress), CSV (Webflow CMS), or manual copy-paste.
Images, usually survive if downloaded before migration (though bulk export is often missing).
Basic page structure, hero, about, services, contact. Rebuilds faithfully.
Domain, stays yours, just points at a new host.
Basic SEO if redirects are done, rankings typically hold.

The breakages are concentrated in dynamic and platform-specific elements, not in the static content most sites are mostly made of.

The pre-migration audit

Before committing to any migration, spend 2–4 hours producing this list:

1. Every page and URL

A spreadsheet: URL, page type, content source (static, from CMS, embedded), and current status (active, redirected, needs attention).

2. Every form

Where it lives, what it does, where submissions go, any integrations it triggers (CRM sync, email autoresponder, Zapier/Make automation).

3. Every third-party script

Name, purpose, where installed, configuration (tracking IDs, pixel IDs, account names).

4. Every integration

Booking tools, chat widgets, embedded forms, media embeds, commerce integrations. For each: vendor, installation method, configuration notes.

5. Every DNS record

A, AAAA, CNAME, MX, TXT, SRV records. Screenshot or export the full DNS zone before making any changes.

6. Every SEO asset

Indexed pages in Search Console, high-ranking URLs, backlinks via Ahrefs/Semrush if available, schema markup currently in use, current meta titles and descriptions (worth exporting to a spreadsheet).

7. Every platform-specific feature

Member Areas, Scheduling, Commerce configurations, page builders, custom CSS, custom code blocks.

Once this list exists, you can realistically estimate migration scope. Most surprises during migrations are items that were on this list but weren’t checked, forms that nobody knew were critical, tracking that only the marketing person understood, integrations that only worked because of a specific platform setting.

How to handle the audit

Three approaches:

DIY. Use the checklist above. Go page by page through the site with the list open. This takes an afternoon for most small business sites.

Specialist-assisted. A migration specialist will run an audit as part of scoping. If you’re considering hiring, the audit is often included in the initial quote process. SiteShiftCo does an audit as part of every project scoping call.

Use a crawler. Tools like Screaming Frog (free for small sites) crawl your entire site and produce a list of URLs, scripts, and external references. Doesn’t find everything (forms are hard to categorize automatically) but gives you a structural skeleton.

Deciding if migration is worth it

After the audit, you’ll have a concrete list of what needs to be reconnected, rebuilt, or replaced. Compare:

Complexity of the migration (the items on the audit list)
Benefit of the new platform (faster, cheaper, better suited)
Cost in time or money to execute the migration

For sites with few dependencies (mostly static content, contact form, basic analytics), the audit list is short and migration is straightforward. For sites built deeply around a platform’s features (WordPress with many plugins, Squarespace with Member Areas and Scheduling, Webflow with complex CMS structures), the audit list is long and migration is a meaningful project.

The audit determines which you’re facing before you commit.

If hiring a specialist

Any migration service worth hiring will walk through this audit with you. If they don’t ask about forms, tracking scripts, third-party integrations, and platform-specific features, that’s a signal they’ll miss these things at launch. See how to choose a website migration service for the full criteria.

For SiteShiftCo projects, the audit is part of the initial scoping. Starter migrations ($890) cover standard brochure sites; anything with complex integrations or platform-specific features is quoted as Core ($1,900+) or Custom.

Will I lose SEO if I rebuild my site?, the SEO dimension specifically
How to migrate from Squarespace to a coded site, the step-by-step migration sequence
How to choose a website migration service, buyer guide if hiring
Should you migrate yourself or hire someone?, DIY vs hire decision
Glossary: Site migration, Site export, 301 redirect, DNS