Website migration
Move off Wix, Squarespace or GoDaddy without going dark
Hosted site builders are a reasonable place to start and a difficult place to grow. At some point the platform becomes the constraint — you cannot change what you need to change, the SEO ceiling is real, and the monthly fee buys less every year. Moving is straightforward if the URLs are handled properly, and damaging if they are not.
- Common routes
- Wix · Squarespace · GoDaddy · Webflow
- Destination
- WordPress or Next.js
- Redirects
- Every indexed URL mapped
The problem
The platform stopped being a shortcut
Builders optimise for getting something online without a developer, and they do that well. The cost shows up later: you cannot add the integration you need, you cannot control the markup that determines your performance and accessibility, the templating limits what your content can be, and the export tool produces something much less complete than the word 'export' implies.
The risk in moving is not technical difficulty. It is URL structure. Builder platforms impose their own path conventions, and the new site will not reproduce them unless somebody deliberately maps every one.
Reasons clients give us
- There is a feature the platform simply will not do, and support confirmed it
- Site speed is poor and the platform controls the parts that would fix it
- The monthly cost has crept up while the capability has not
- You have outgrown the templating and every page looks like the same template
- Accessibility or compliance requirements the builder cannot meet
- You want to own the code rather than rent the site
What is included
What a migration includes
Inventory and planning
- Full crawl of the existing site — every page, asset, redirect and status code
- Search Console and analytics export to identify the pages that matter
- A 301 map covering every indexed URL, including the platform’s own path quirks
- A content audit so you are not paying to move pages worth retiring
- A written cutover plan with a rollback option
Content and media
- Page and post content migrated with formatting and internal links intact
- Media re-uploaded, re-optimised and re-linked, not hotlinked to the old host
- Metadata carried over: titles, descriptions, canonicals, alt text
- Products, variants and categories where commerce is involved
- Forms rebuilt and tested, since submissions almost never transfer
Cutover
- Staging parity check — the new site crawled and compared against the old inventory
- DNS planned in advance with TTL lowered ahead of the change
- Email records protected, which is the most common way a cutover goes badly wrong
- SSL provisioned and verified before the switch, not after
- A launch window chosen from your traffic data, with a rollback path ready
After the move
- Redirects verified live, not just on staging
- Sitemap resubmitted and Search Console monitored daily at first
- 404 logs reviewed and anything missed redirected
- The old platform kept live but de-indexed until the new one is confirmed stable
- A post-migration report comparing crawl, traffic and vitals before and after
For reference
What moves cleanly, by platform
Every platform exports differently, and most export less than people expect. This is what we plan around before quoting.
| Moving from | Usually comes across | Almost always rebuilt |
|---|---|---|
| Wix | Blog posts via RSS, page text, product data in a limited CSV, media files by download | All layout and design, forms and their submissions, app-based features, URL structure for blog and store paths |
| Squarespace | Blog and page content via the WordPress-format XML export, product data, images | Design and layout, galleries, member areas, scheduling and commerce settings, any block-specific content |
| GoDaddy Website Builder | Very little programmatically — content is generally recovered by crawling the live site | Essentially everything: design, structure, forms, and any built-in commerce |
| Webflow | CMS collections as CSV, static page content, assets via export | Interactions and animations, forms and submissions, membership features, anything bound to Webflow hosting |
| Older WordPress | Content, media, users, taxonomies and most metadata transfer well | Page-builder layouts, which need rebuilding if the builder is being removed |
| Static HTML or a legacy CMS | Content is recoverable by crawl; media by download | Templating, navigation and any server-side functionality |
Our process
How a cutover is run
Understand needs
Inventory everything
Crawl the live site rather than trusting the CMS page list, because builder platforms generate URLs that never appear in the editor. Pull Search Console for what is actually indexed and earning.
You getComplete URL inventory and traffic baseline
Strategize
Map old to new, decide what moves
Every URL gets a destination. Content worth keeping is identified, content worth retiring is redirected to its best replacement rather than deleted.
You getApproved 301 map and migration scope
Create & build
Build and migrate on staging
The new site is built, content moved, redirects implemented, and the staging site crawled and compared against the original inventory until nothing is orphaned.
You getStaging parity report
Optimize & grow
Cut over and watch
DNS switched in a planned window with email records protected, then daily monitoring of Search Console, 404 logs and traffic through the first weeks.
You getLive site, monitored, post-migration report
Honest scoping
When to move — and when to stay
Move if
- The platform is blocking something you genuinely need to do
- You need control over markup for performance, accessibility or structured data
- Your content library has grown past what the templating can express
- You want to own the code and be able to change agency
- You are redesigning anyway, which makes the move nearly free in marginal cost
Stay if
- The current platform does everything you need and the complaint is aesthetic — redesign within it
- Your site is ten pages of thin content; rebuild it properly rather than paying to move it
- Nobody on your team will manage WordPress and you have no plan for maintenance
- You want the new site to be a pixel-perfect copy of the old one — if the design is right, the only thing you are buying is risk
One more thing. We will tell you when migrating is not worth it. It is a real project with real risk and it should buy you something specific.
Questions
Before you ask us
The things people ask about Website Migration before they get in touch. If yours is not here, ask directly — you will get a straight answer rather than a brochure.
Ask a questionWill my site go offline during the migration?
No. The new site is built and verified on staging while the current one stays live, and the switch happens at DNS level in a planned window. The old platform stays available but de-indexed afterwards until we are confident the new site is stable.
Will I lose my Google rankings?
Not if the URL mapping is done properly, though expect a few weeks of movement after any platform change. The failure mode is always the same: URLs that nobody inventoried, so nobody redirected. We crawl the live site rather than trusting the CMS page list, because builders generate paths that never appear in the editor.
Can you move my blog posts and images?
Yes. Posts migrate with formatting, categories and internal links corrected to the new structure. Images are re-uploaded to your new site and re-optimised, not left pointing at the old host — hotlinked media breaking months later is a common and avoidable failure.
What about my email?
This is the single most common way a cutover goes wrong. If your email runs on the same domain, the MX and related DNS records have to be carried over deliberately. We record the full DNS zone before touching anything and verify mail flow after the change.
How long does a migration take?
For a typical small business site, a few weeks including the rebuild — the inventory and redirect mapping are the parts that take real care. Large content libraries and commerce catalogues add time proportional to their size, which we scope explicitly rather than discover.
Do I need a redesign at the same time?
Not necessarily, and doing both at once makes it harder to tell what caused any change in performance. That said, if the design is already the weak point, combining them is far cheaper than two projects. We will give you the honest trade-off rather than the bigger quote.
Get the honest version before you commit
Send us your current URL. We will crawl it, tell you what will and will not come across, where the redirect risk sits, and whether moving is worth it at all.