Rebuild or Migrate? Working Out Which One You Are Doing

Somebody asks how long it takes to move a website and gets told “a weekend”. Sometimes that is right. Often the person asking has forty pages, a four-year blog archive and a store, and is about to discover that no file comes out of their platform at all.

The gap between those two situations is not a matter of degree. They are different jobs. This is how to work out which one you are about to do, and roughly what it will cost you in evenings.

The definitions, kept strict

A migration is a file operation. Content comes out of one platform in a structured format and goes into another that can read it. Squarespace to WordPress is a migration. WordPress to Squarespace is a migration. The text, the dates and the structure travel, and your job is repair work rather than typing.

A rebuild is a human operation. There is no file, so a person opens two windows and recreates the site. Leaving Wix is a rebuild whatever the destination. So is leaving GoDaddy’s builder. So is any move where the receiving platform has no importer for the thing you came from.

Most builder-to-builder moves are rebuilds. That is not an accident of engineering; there is simply no shared format between these products and no commercial reason for either company to invent one.

The two-question test

You can settle this in five minutes.

Question one: does the platform I am leaving produce a content export file? Not a products CSV, not a contacts CSV — a file containing your pages and posts. Check the platform’s own help centre for the word export. If the only exports are CSVs of records, the answer is no.

Question two: can the platform I am moving to read that file? Check the destination’s import documentation for your source platform by name. “WordPress format” is the only interchange format with real currency here; if your source writes it and your destination reads it, you have a migration.

Two yeses is a migration. Anything else is a rebuild. Where each major platform sits is on the plan for switching website builders, and the platform-by-platform detail is in the builders with no way out.

Estimating a rebuild honestly

Count the things, not the pages. Here is the arithmetic that has matched reality for us.

• Simple content page — text, a couple of images, no layout tricks: twenty to thirty minutes each, including proofreading.
• Designed page — home page, a landing page, anything with sections and columns: one to three hours each.
• Blog post — copy, paste, re-add images, set the date and the categories: ten to fifteen minutes each.
• Product — if a CSV exists: negligible each, plus two to four hours total for mapping columns and verifying. If no CSV exists: ten minutes each.
• Forms: thirty minutes each, including testing that the notification arrives.
• The URL map: one to three hours, once.
• Design and theme setup: a full day, and it will be more than you planned.
• Testing and fixing: a third of whatever the build took. It always is.

A ten-page brochure site with no blog: roughly fifteen to twenty hours. A forty-page site with a hundred-post archive: fifty to eighty. A store with four hundred products and content pages: a hundred hours is not unusual, and a specialist doing it full time is often cheaper than you doing it in evenings.

Double whatever number you land on if you have never used the destination platform before. Learning an editor while under time pressure is its own tax, and it is paid in the worst possible currency — the hours late at night when the domain has already been announced as moving.

One more line item that never makes it onto anybody’s estimate: the decisions. A rebuild forces you to re-choose a hundred small things you settled years ago and have not thought about since, from what the contact page says to whether the old services still exist. Each decision is small. Collectively they are why a rebuild that should take fifteen hours takes three weekends.

Estimating a migration

Shorter, but not short, and the work is distributed differently.

The import itself is minutes to an hour. What follows is the repair: formatting that flattened, internal links still pointing at old addresses, images that did or did not come, page types that were not in the export. Budget one to three days of fixing for an average site, and more if your source used a page builder, because page-builder output is usually the part that does not survive.

Then the same non-negotiable overheads as a rebuild: the URL map, the design setup, the forms, the testing. A migration saves you the typing. It saves you nothing else.

When rebuilding is the better answer anyway

This is worth saying, because the word rebuild sounds like a punishment and frequently is not.

Your site is smaller than you think. Look at twelve months of analytics. On most sites, a handful of pages carry nearly all the traffic and a long tail carries almost none. Rebuilding the pages that matter and redirecting the rest takes a fraction of the time and produces a better site.

Imported content often needs rewriting anyway. Content written for a platform you disliked, in a format that flattened on arrival, is not obviously a better starting point than a clean page.

The structure is probably wrong. Most sites accrete. A rebuild is the only realistic opportunity you will get to fix the navigation and the information architecture, because nobody ever schedules that on its own.

A partial migration can be worse than none. A half-imported archive with broken images and flattened layouts still has to be fixed page by page, which is most of the cost of a rebuild with none of the satisfaction. Worse, it looks finished, so it tends to go live before anybody has actually read it.

When it is not worth moving at all

The honest answer to “should I switch platforms” is frequently no, and a site about migrations should say so.

Do not move to fix a design problem. Every mainstream builder can produce a good-looking site; a new template on your current platform costs a weekend rather than a month.

Do not move because a comparison article scored something higher than what you have. Scores do not account for the fifty hours of your life in between.

Do move when there is a hard ceiling: a capability that genuinely does not exist on your platform, a bill that genuinely does not work, a product that is genuinely being wound down, or content that is genuinely trapped in a way that will get worse with every year you stay.

Making the decision on paper

Write down three numbers before you commit. The hours, from the arithmetic above. The overlap cost, which is one or two extra billing cycles. And the risk, which is the honest answer to what happens to your business if the site is wrong for a week.

If the ceiling you are hitting is worth more than those three numbers combined, go. Then work through the moving-day checklist in order, and give yourself twice the calendar time you first thought of — not because the work expands, but because life does.