The Parts of a Website That Never Migrate

Migration guides talk about content, because content is the part with a file attached. It is also, for most working websites, less than half of what the site does.

Everything below has never appeared in an export file from any website builder, in any direction. Some of it can be rescued by a separate export. Some of it has to be rebuilt. And a few items on the list are gone the moment the old account closes, which is why this page belongs at the start of a move rather than the end.

Forms, and everything in them

A form is two things: a definition and a pile of submissions. Neither travels.

The definition — fields, validation, the confirmation message, where notifications go — is rebuilt from scratch on the new platform. This is usually quick, and the part people get wrong is the notification address. Rebuild the form, submit it, and confirm the message arrives somewhere a human reads. A form that silently posts into a void is the single most expensive quiet failure on a business site.

The submissions are your enquiry history, and most builders will export them as CSV from the form’s own panel. Do that before you cancel anything, because they are not recoverable afterwards.

Members, logins and anything gated

If your site has accounts, this is the hardest item on the list and the one to think about first.

Customer and member records can often be exported as CSV — names, addresses, order history. Passwords cannot. No platform hands over usable credentials to another, and you should not want one that did. The practical consequence is that every returning user has to set a new password after your move, and they will not understand why unless you tell them.

Plan an email. Send it on the day, not a week later, and say plainly that the site has moved and a password reset is required rather than leaving people to guess that something has broken. Expect a support load in the first week regardless.

Gated content, membership tiers, course progress and anything else tied to a login are almost always rebuilt by hand, and in the case of progress records, frequently lost entirely.

Bookings, calendars and appointments

Existing bookings sit in the old platform’s database with the old platform’s notifications attached to them. Nothing carries them across.

The safe procedure is to stop taking new bookings on the old system a week or two before you switch, honour the existing ones from the old calendar, and open the new system for anything from the switch date onward. Export the historical list as CSV for your records.

The dangerous version is switching mid-week with live appointments on both systems and reminder emails firing from a platform you have just cancelled.

Reviews and ratings

Product reviews are content that other people wrote on your site, and they are frequently worth more than anything you wrote yourself.

Some platforms export them. Many do not, and where they do, the destination frequently has no matching field to import them into. Shopify, for instance, handles review migration through third-party apps rather than its own tool. Check both ends before assuming.

If there is no path, screenshot them and copy the text into a spreadsheet alongside the product each one belongs to. A page of quoted reviews you re-typed is not the same as structured review data — it will not produce star ratings in a search result — but it is considerably better than losing five years of them, and it gives you something to paste back in if the new platform gains an import later.

Your analytics history

Sessions, sources, conversions — all of it lives in the analytics product, not in the website. Provided you use the same analytics property on the new site, the history continues uninterrupted.

What breaks is comparability. URLs change, so every page-level report now splits across old and new addresses. Events fire from a different tag manager or a different theme. Set the new tracking up before launch, verify it is recording, and annotate the date of the move in your analytics so that next year’s version of you understands the cliff in the graph.

Custom code, and anything an app did

Any HTML, CSS or JavaScript you or a developer added is specific to the platform it was added to. It does not travel, and a surprising amount of it is doing something load-bearing that nobody remembers.

Before you move, list every piece of custom code on the site and write down what it does. Some of it will be replaced by a native feature on the new platform. Some will be replaced by an app. Some turns out to have been fixing a bug in a theme you are no longer using, in which case you can delete it with a clear conscience.

Platform-specific code — the kind that extends the builder itself with its own scripting environment — is a total rebuild. There is no equivalent on the other side.

Your design

This is the one people assume and it is worth saying out loud anyway. Squarespace’s own migration guidance states directly that it is not possible to import a previous site’s layout, design, fonts or other content. That is the norm across the industry, not an exception.

Fonts, colours, spacing, section layouts, animations, breakpoints: rebuilt. Take full-page screenshots of every page before you start, at desktop and phone widths, and use them as the reference. You will be surprised how quickly you forget what the old site looked like, and how often you need to check a detail.

SEO settings, individually

Page titles and meta descriptions usually have to be re-entered, because most export formats do not carry them in a way the receiving platform recognises.

Put them in the inventory spreadsheet as two extra columns while you are collecting URLs. It is ten minutes of copying and it saves you rewriting a hundred page titles from nothing.

Structured data, canonical settings, and anything you configured in the old platform’s SEO panel are all re-done on the new side as well.

The things that vanish with the account

Some items on this list are not merely un-migratable. They are gone when the plan lapses.

• Form submissions, if you did not export them.
• Order and customer lists, if you did not export them.
• Images, where there is no bulk media download and you have no originals.
• Any record of what the site looked like.

Everything in that group is the reason this article exists at the front of a move rather than the end. Export first, cancel last. The full sequence is in the moving-day checklist, and the platform-by-platform picture of what an export contains is on the plan for switching website builders.

How to use this list

Copy the headings above into your inventory spreadsheet as rows, and against each one write three things: does it exist on my site, can it be exported, and who rebuilds it.

Most sites find two or three items they had not thought about at all. Finding them four weeks out is an inconvenience — you export a file, you book an extra evening, you send a warning email. Finding them on launch day is a bad afternoon, and finding them after the old account has closed is not a problem you can solve at any price.

The pattern is consistent enough to be worth a rule. Anything a visitor typed into your site, anything a visitor owns an account on, and anything a developer wrote by hand will not be in the export file. Handle those three categories first and the rest of the move is mostly typing.