How to Migrate From Another Website Builder: A Real Plan

You rebuild rather than import. No builder reads another builder's project file, so migration means moving your content, your URLs and your domain, then describing the site again in the new tool. The rebuild is the fast part. The URLs and the domain are where a migration succeeds or quietly costs you traffic.

That order surprises people who expect an import button. There is no such button anywhere in this category, and planning around its absence is what separates a two-hour move from a two-week one.

What actually transfers between builders?

Content transfers. Structure transfers if you copy it deliberately. Everything that was specific to the old platform stays behind, because it was never a file you owned in the first place.

The clearest way to think about it is ownership. Your text, images and domain belong to you and travel anywhere. The old builder's templates, widgets, blocks and internal page IDs belong to that product, and they have no meaning outside it.

Read the "no" rows carefully. They are the ones people forget until launch day, and two of them, layout and forms, are the reason a migration is a rebuild rather than a transfer.

How do you plan the move before touching anything?

Start with an inventory, not a build. Open the old site and write down every page that exists, its URL path, and whether anyone visits it. Analytics answers the third column, and it is usually the most useful one.

Most small sites turn out to have four or five pages that matter and a long tail nobody has opened in a year. Rebuilding the tail is wasted effort, and dropping it is a decision better made on purpose than by accident.

Then decide what the new site should be, rather than replicating the old one out of habit. A migration is the one moment when restructuring is free, because you are rewriting everything anyway. Copying a bad structure faithfully is the most common mistake in this whole process.

Finally, note anything with logic behind it: a booking flow, a member area, a checkout. Those are not pages, they are features, and they need naming in the prompt rather than pasting as text. Very specific business rules arrive through follow-up edits rather than one perfect description, so budget for iteration there.

How do you rebuild the site itself?

Describe it once with structure, then correct it. On Zugo a single-page build takes about a minute and a multi-page platform takes a few minutes, so the first version of a five-page site exists before you have finished your coffee.

Write the prompt from your inventory: name the pages, name the audience, name the one action a visitor should take. Pasting the old site's actual headings into the prompt helps more than describing them, because the model then works from your words rather than inventing new ones. The full method is in how to write a good prompt.

Costs are predictable enough to plan. A fresh single-page build costs 6 credits, a multi-page platform costs 12 for the first three pages plus 3 for each page beyond them, and every edit costs 3. Hi-Fi mode doubles the build and the edit. Free comes with 5 credits, Pro is $25 per month with 200 credits, and Business is $99 per month.

Expect the first pass to be roughly right and the next few edits to fix the specifics. That is normal, and it is cheaper than it sounds: the content is already written, so most edits are about arrangement rather than invention.

How do you keep your URLs and not lose search traffic?

Keep the paths identical wherever the page still exists. If the old site had /pricing and /about, the new one should have /pricing and /about. Every path you change is a link somewhere on the internet that now goes nowhere, and search rankings attach to URLs rather than to pages in the abstract.

For pages you genuinely retire, the correct handling is a redirect from the old path to the closest surviving page. Redirects are configured where the old site lived or at your DNS and hosting layer, and this is the fiddliest part of any migration. Nobody automates it for you, and skipping it is the single biggest cause of traffic loss after a move.

Do the inventory of inbound links before you switch. Anything you have published, printed, or linked from social profiles points at specific addresses, and those are the ones worth preserving even when the page underneath changes.

Search will also need time to notice. Recrawling is not instant and rankings can wobble for a while after any structural change, regardless of which tool built either version. What that wobble depends on is covered in is an AI-built website good for SEO.

What is the safe order to switch over?

Build first, verify second, repoint the domain last. Reversing that sequence is how a site spends an afternoon half-broken in public.

The sequence that works: build the new site and publish it to its zugo.run address, check every page on a real phone and a laptop, wire up connectors like Supabase for data, Stripe for payments, Resend for email and Google Analytics for traffic, then point the domain at the new site and keep the old one paid up for a week.

That last part matters. Cancelling the old plan before DNS has fully propagated leaves you with no way back, and the cost of one extra month is trivial against the cost of an outage. The domain mechanics are in connecting a custom domain.

Before repointing, confirm the new build actually works rather than merely exists. Every Zugo build is booted in a sandbox and a failure is reported as a failure, which lowers the risk of publishing something dead, but it does not remove it and it does not check that your pricing table says the right numbers. That check is yours.

When is migrating a bad idea?

Three cases where the honest answer is to stay where you are, at least for now.

Your old site is large and heavily indexed. Hundreds of URLs with real search traffic make the redirect map the entire project. The rebuild takes minutes; the mapping takes days, and the risk is concentrated in the part no tool shortens.

The site depends on a platform-specific system. A shop with years of order history, a membership base, or a booking system with existing customers is a data migration first. The data itself moves through exports and your own database, but the plumbing is real work.

You are mid-campaign. Moving a site while ads are running means debugging DNS and conversion tracking at the same time. Wait for a quiet week.

The good cases are the opposite: a small site you have outgrown, a template you can no longer bend, a project where you want the source code in your own GitHub repository rather than locked in a product. For those, the move is genuinely a single evening, and you can test the rebuild half of it for yourself at zugo.dev before committing to anything.