Most website migrations fail quietly

They do not fail with a dramatic crash. They fail slowly — a few hundred broken links nobody notices for weeks, a drop in organic traffic that gets blamed on the algorithm, contact forms that stopped working on day two of the new site. The client is vaguely unhappy. The agency is vaguely defensive. Everyone moves on.

We have been called in to fix migrations gone wrong more times than we would like to count. The pattern is almost always the same: the technical execution was treated as an afterthought to the design work, and nobody owned the full process end to end.

This post is a walkthrough of how we actually do it at Daybrain Digital — every stage, every decision point, and why each one exists. If you are a CTO, technical lead, or founder planning a migration from Wix, Squarespace, WordPress, or any other platform to a custom build, this is the honest account of what good looks like.

Stage one: the audit before anyone writes a single line of code

The single biggest mistake in website migration projects is treating the current site as something to escape from, rather than something to understand. Before we touch anything, we spend meaningful time inside the existing environment.

This is not a quick look around. It is a structured technical and content audit that answers specific questions:

What does the current site actually contain?

We crawl the full site — typically using a combination of Screaming Frog and manual review — to produce a complete URL inventory. This includes every page, post, product, image, PDF, and file that has ever been indexed. You would be surprised how often clients do not know what their own site contains. Legacy landing pages from a campaign three years ago. Blog posts that are quietly driving 40% of organic traffic. Subdirectory paths that are linked from third-party sites and would 404 overnight if we did not account for them.

If your current site has any meaningful search presence, we also pull twelve months of Google Search Console data and cross-reference it with the URL inventory. This tells us which pages are actually doing work for you, not just which pages exist.

What is the technical baseline?

We run Core Web Vitals assessments across a representative sample of pages — not just the homepage. We note load times, cumulative layout shift scores, largest contentful paint. We document the current structured data markup, canonical tags, hreflang settings if relevant, and any existing redirects already in place. If you are migrating from a platform like Wix, this step often surfaces problems you did not know you had. We wrote about this in detail in our post on whether your Wix site is costing you customers — the short version is that platform constraints create performance ceilings that only become visible when you start measuring carefully.

What are the dependencies?

Third-party integrations, tracking pixels, CRM connections, email marketing embeds, payment processors, booking systems. Every integration that touches the current site needs to be catalogued before migration begins, because each one represents a potential failure point during cutover. We map these explicitly and assign ownership — who is responsible for reconfiguring each one, and by when.

Stage two: the redirect map

If the audit is the foundation, the redirect map is the structural frame. This is the document that determines whether your organic traffic survives the migration intact.

A redirect map is a complete record of every old URL and its corresponding new destination. For a site with fifty pages, this is straightforward. For a site with five hundred pages — or an e-commerce catalogue with thousands of product URLs — it becomes a significant piece of work in its own right.

We approach it in priority tiers:

Tier one: high-value pages

Any URL with meaningful search traffic, inbound links from external domains, or direct revenue attribution. These pages get exact one-to-one 301 redirects to their new equivalents. No exceptions. If a new site architecture means a product that lived at /products/widget-a now lives at /shop/widgets/widget-a, that redirect is written, tested, and tested again before launch.

Tier two: structural pages

Category pages, archive pages, tag pages, author pages. These often get restructured during a migration — especially when moving from a CMS with rigid taxonomy structures to a custom build. We document the intended new structure and map old paths to new ones systematically, rather than letting them 404.

Tier three: legacy and low-value URLs

Old campaign pages, deprecated content, URLs that were never indexed and have no inbound links. These still get documented, but the decision on each one is made explicitly — redirect to the most relevant current page, redirect to the homepage, or allow to 404 with a proper 404 response code (not a soft 404 that returns a 200 status).

The redirect map is delivered as a working document — typically a structured spreadsheet — that gets used directly by the development team during build and by whoever is managing the server configuration at launch. It is a living document until the moment the new site goes live.

Stage three: content migration

How content moves depends entirely on what you are migrating from and what you are migrating to. There is no universal answer, but there are universal principles.

Automated migration versus manual migration

For large content volumes — hundreds of blog posts, for example — automated migration tools are attractive. WordPress has decent import/export tooling. Squarespace exports to WordPress XML. There are third-party tools that claim to handle Wix migration automatically.

We use automation where it genuinely works and manual process where it does not. The honest truth is that automated migration tools handle the raw content reasonably well and handle the formatting, metadata, internal links, and image attribution poorly. Every automated migration we have run has required a structured quality-assurance pass afterwards — typically reviewing a sample of migrated content in detail and extrapolating the issues found to a systematic cleanup of the full dataset.

Images and media

This is where migrations get expensive if you are not careful. Images on hosted platforms like Wix and Squarespace are often stored in the platform's own CDN, with URLs that become invalid the moment you leave. We export and re-host all media assets as part of the migration, with consistent naming conventions and a clear folder structure. Alt text gets reviewed at this stage — not just copied across.

Internal links

After content migration, every internal link in every page and post points to the old URL structure. If you have redirects in place, those links will technically work — but they add a redirect hop on every internal navigation, which affects performance and is unnecessary technical debt. We run a post-migration internal link update as a discrete task, replacing old internal URLs with their new direct equivalents across the full content set.

Stage four: build and environment setup

This is the part most people think of when they hear 'website migration' — the actual construction of the new site. By this point, if stages one through three have been done properly, the build team has a complete picture of what they are building to. The URL structure is defined. The content is ready. The integrations are catalogued.

We maintain three environments throughout the build process:

Development

The working environment. Code is written, reviewed, and tested here. It is not publicly accessible. No real data. No live integrations. The development environment exists to let the team move fast without consequences.

Staging

An exact replica of what will go live — same server configuration, same environment variables, same database structure. Staging is where the client reviews the site, where QA testing happens, and where the redirect map is validated against real URL patterns. Critically, staging should mirror production as closely as technically possible. Bugs that only appear on production because staging was configured differently are a common and entirely avoidable failure mode.

Production

The live environment. Nothing goes to production without passing through staging review. This sounds obvious, but it is consistently the step that gets skipped under time pressure, and consistently the source of post-launch fires.

The pre-launch checklist

Before any migration goes live, we work through a structured checklist. This is not optional. It is not abbreviated when timelines are tight. Here is a version of it:

Technical SEO

Performance

Functionality

Content

Post-launch monitoring setup

This checklist exists because migrations fail at predictable points. The robots.txt issue alone — staging Disallow: / accidentally carried to production — has caused complete deindexation events for sites that missed it. These are not edge cases. They are common.

Stage five: DNS cutover

DNS cutover is the moment the old site stops being what your domain points to, and the new site takes over. It sounds simple. It is the stage that requires the most careful timing and the clearest communication.

TTL management

DNS records have a Time to Live (TTL) value — the duration for which resolvers cache the record before checking for updates. Standard TTL values are often set at 3600 seconds (one hour) or higher. Before a planned migration, we lower the TTL to 300 seconds (five minutes) at least 48 hours before the cutover window. This means that when we make the change, it propagates globally much faster than it otherwise would.

If you skip this step, you can end up with a situation where some users hit the new site and others hit the old one for hours after cutover — which creates support confusion and makes debugging post-launch issues significantly harder.

Timing the cutover

Cutover should happen during a low-traffic window — typically late evening or early morning, outside of core business hours. Not on a Friday. Never before a bank holiday weekend. The reasoning is simple: if something goes wrong, you want the maximum number of competent people available to fix it.

We run the cutover with the full team present and a rollback plan documented and ready. The rollback plan is not an admission that something will go wrong. It is an acknowledgement that if something does go wrong, the time to decide what to do is before it happens, not during it.

The first 24 hours

Immediately after cutover, we are watching several things in parallel:

The first 24 hours are not a time to celebrate and move on. They are a monitoring period. Issues that do not appear on staging sometimes appear on production — infrastructure differences, real-world traffic patterns, integrations behaving differently against live data. Most of these are caught and resolved within the first few hours if someone is watching for them.

Stage six: post-migration SEO monitoring

A migration is not complete at launch. It is complete when the search performance of the new site has stabilised and matched or exceeded the baseline of the old one.

That takes time. Google needs to crawl and re-index the new site. Ranking positions will fluctuate during the transition period — this is normal and expected, not a signal that something has gone wrong. The question is whether traffic recovers within a reasonable timeframe, and what to do if it does not.

What to monitor

We track the following in the six to eight weeks after a migration:

When to intervene

If specific pages show sustained drops in impressions — not just ranking position fluctuations, but actual impressions declining — that is a signal to investigate. The usual causes are: the redirect from the old URL is not working correctly, the new page has a canonicalisation issue, or the new page content is materially thinner than the original. Each of these has a specific fix. None of them requires panic; they require diagnosis.

This monitoring discipline is part of what separates a migration service from a migration product. Anyone can flip DNS. The value is in knowing what to watch for afterwards and having the capacity to respond to it. At Daybrain Digital, post-launch monitoring is built into every migration engagement — not offered as an optional add-on.

A worked example: moving from Squarespace to a custom Next.js site

To make this concrete, here is a representative example of how a migration plays out in practice. The details are illustrative, but they reflect real patterns we encounter.

A professional services firm is running a Squarespace site. It has around 80 pages, a blog with 120 posts, a client portal integrated with a third-party tool, and a contact form connected to their CRM. They want to move to a custom Next.js site hosted on their own infrastructure for performance, flexibility, and ownership reasons.

What the audit surfaces

The crawl identifies 80 pages and 120 blog posts — expected. It also finds 34 URLs in Google Search Console that are indexed but do not appear in the site navigation: old service pages from a rebrand two years ago, a resource section that was removed from the menu but never deleted. Fourteen of these pages have meaningful external inbound links. Without a redirect map, those links would 404 on day one of the new site.

Core Web Vitals on the Squarespace site show an LCP of 4.2 seconds on mobile — well outside the 'good' threshold of 2.5 seconds. The culprit is unoptimised hero images served directly from Squarespace's CDN without responsive sizing. This becomes a target for improvement on the new build.

What the redirect map looks like

The Squarespace URL structure uses /blog/post-title for blog posts. The new site will use /insights/post-title to reflect a content repositioning. That is 120 blog post redirects, plus the 34 legacy pages, plus the standard structural pages (category archives, tag pages, author pages). The redirect map ends up with 187 entries, each reviewed and approved before build begins.

Content migration

Squarespace exports to WordPress-format XML. We use that as a starting point but run it through a custom parser rather than importing directly into WordPress — the destination is Next.js with content stored in a headless CMS, so we need the content in a different shape. The parser extracts the content body, metadata, tags, and publish dates, then formats them for the new CMS. Images are downloaded from the Squarespace CDN, renamed consistently, converted to WebP, and uploaded to the new media storage.

Post-migration, a QA pass reviews 30 randomly sampled posts for formatting issues. Six have malformed blockquotes from a quirk in the Squarespace XML export. We write a script to find and fix all instances of the pattern across the full dataset rather than fixing them manually.

The result

At launch, all 187 redirects are live and verified. LCP on the new site measures 1.6 seconds on mobile — down from 4.2 seconds. Organic traffic dips by around 8% in week one as Google processes the new sitemap, then recovers fully by week four. The fourteen pages with external inbound links retain their search visibility because their redirects were in place from day one.

This is not a remarkable outcome. It is what a well-executed migration looks like. The fact that it feels unremarkable is the point.

What platform you are migrating from changes the specifics

Wix, Squarespace, WordPress, Webflow, Shopify — each has its own quirks, and it is worth naming a few of the most relevant ones.

Wix

Wix has historically had limited export functionality. Content can be exported to some degree, but the platform's proprietary URL structure and hosting mean that migrations require more manual work than most. Wix also has a reputation for generating bloated markup that inflates page weight — one of the reasons clients leave. If you are moving off Wix, expect the audit phase to take longer and the content migration to be more manual-heavy. The performance gains on the other side are typically significant.

Squarespace

Better export support than Wix, but the XML export has known formatting quirks (see the blockquote example above). Squarespace's URL structure is reasonably clean, which makes the redirect map more straightforward. The main watch-out is media — images are served from Squarespace's CDN and need to be explicitly downloaded before the old site is closed.

WordPress

WordPress migrations are the most varied because WordPress itself varies so much between installations. A well-structured WordPress site with a custom theme and disciplined URL conventions is relatively straightforward to migrate. A WordPress site that has accumulated eight years of plugins, database cruft, and overlapping redirects from previous migrations is a significant project in its own right. We always run a database audit before committing to a timeline on WordPress migrations.

Headless or custom builds

Migrating from one custom build to another is typically the most technically complex but also the most controllable — you have full access to the data, full control over the export format, and no platform constraints. The risk is data volume and the completeness of the existing documentation. If the current site was built without thorough technical documentation, the audit phase becomes the documentation phase.

The honest conversation about timelines

Most website migrations take longer than the initial estimate. This is not because agencies are bad at estimating. It is because the audit phase reliably surfaces things nobody knew were there, and because the correct response to discovering 34 untracked indexed URLs is to handle them properly, not to ignore them to protect the original timeline.

A realistic timeline for a well-executed migration of a 100-page professional site with a blog and a handful of integrations is six to ten weeks from audit start to launch, with a further six to eight weeks of post-launch monitoring. Smaller sites can move faster. Sites with complex integrations, large content volumes, or e-commerce functionality take longer.

If someone quotes you a two-week turnaround on a migration of any meaningful complexity, ask them specifically what they are skipping. The answer will tell you what you need to know.

For teams evaluating whether to build capability in-house or work with a specialist, our post on the tools we actually use to run Daybrain gives a candid picture of what a lean technical operation looks like in practice — useful context for the build-versus-buy question.

Why the process matters more than the platform

There is a tendency in the industry to sell migrations as platform decisions — 'move from Wix to X and everything will be better'. The platform matters, but it is secondary to the process. A poorly executed migration to a technically excellent platform will still lose you organic traffic, break your integrations, and frustrate your users.

The migrations that go well are the ones where someone owns the full process — not just the build, not just the design, but the audit, the redirect map, the content migration, the QA, the cutover, and the post-launch monitoring. That end-to-end ownership is what a website migration service should mean. It is what we mean by it at Daybrain Digital.

It is also worth noting that a migration is a natural moment to address other problems — content that was never optimised, integrations that were bolted on and never properly implemented, tracking that was set up incorrectly years ago and has been producing inaccurate data ever since. The audit phase surfaces these. You can choose to fix them or not. But you will at least know they exist, which is more than most sites can say about themselves.

If you are curious about what else AI-powered tooling can do once your new site is live — particularly around automating workflows that currently eat time — our piece on Daybrain Bridge is worth reading. A faster, more capable site is the foundation; what you build on top of it is where the real opportunity sits.

The takeaway

A website migration is a technical project with real consequences for your search visibility, your conversion rates, and your users' experience. It is not a find-and-replace operation on your domain name.

The difference between a migration that preserves and improves your position and one that quietly erodes it comes down to how seriously the preparation stages are taken — the audit, the redirect map, the content migration — and whether someone is watching carefully in the weeks after launch.

If you are planning a migration and want to understand what a thorough process looks like for your specific situation, the place to start is a proper audit of what you currently have. Everything else follows from that.