The Webflow to Astro migration checklist

Everything a Webflow to Astro migration has to account for, grouped by when it has to be true rather than by category. Nothing is held back: if you are running the move yourself, this is the list. If you are hiring somebody, it is what to ask them about.

Before anything is rebuilt

Every item here is a decision rather than a task. Left open, each one blocks work later at a point where it is more expensive to answer.

Decide where the content will live

Content Collections in the repository, a headless CMS, or no CMS at all. This shapes the components, so the rebuild waits on it. Decide it against who publishes and how often, not against which is newer.

Decide what is being preserved and what is being changed

A migration that also redesigns is two projects on one deadline. Write down which one this is. If the answer is both, schedule them in sequence rather than together.

Name who approves what

Content, design, legal wording, the go-live decision. Approvals that need several people are not a problem; approvals nobody identified until week three are.

Agree what happens to the Webflow subscription

Audit which assets are included in the available exports and which remain external references. Copy or deliberately retain the required files, verify the new site’s dependencies and agree when the old services can be retired. Do not assume a particular CDN expiry date.

The inventory

The stage that turns an estimate into a date. Everything below gets written down while the site is still running, because the live site is the only complete record of what it does.

Every known public URL, reconciled across sources

Combine the crawl with CMS records, sitemaps, redirect history and available analytics, search and request data. Each source can reveal addresses another misses.

Every collection, with its fields and its relationships

Field types, required fields, multi-reference fields and anything that drives layout rather than content. The relationships are the part that takes the time, and the part an export flattens.

Every template, counted separately from the pages it renders

This is the number that decides the scope. Four hundred pages from four templates is a different job from twelve pages built one at a time.

Every integration, and where its data actually lands

Forms, analytics, consent, CRM, chat, scheduling, payments. For each one, write down the destination rather than the embed, because the destination is what has to be tested afterward.

Every interaction worth keeping

Most sites have a handful that matter and a long tail nobody would miss. Deciding which is which before the rebuild is how the rebuild stays short.

Every piece of custom code, and what it was compensating for

Some of it becomes a component. Some of it existed to work around a platform limit that no longer applies, and the right move is to delete it rather than port it.

During the rebuild

The checks that are cheap while the work is open and expensive once it is finished.

Build the redirect map against the inventory, not against memory

Each old address gets a decision: preserved, redirected to a specific replacement, or deliberately retired. Write the third one down too, because an intentional removal and a mistake look identical afterward.

Keep metadata attached to content, not to templates

Titles, descriptions and canonical URLs that were hand-written per page have to move as content. Regenerating them from a template silently rewrites the ones somebody chose deliberately.

Move structured data with the pages it describes

It is easy to carry across stale, and easy to leave behind entirely. Check it against what the new page actually says rather than against what the old one did.

Decide which interactions to retain, adapt or rebuild

Exported interaction code may remain usable with its dependencies. Decide whether retaining it or rebuilding the behavior better fits the project, then test the chosen implementation.

Test forms at the destination

A success message proves the browser was satisfied. Check the record in the CRM, the event in analytics and the notification that was supposed to fire.

Before the cutover

Nothing here is optional, and all of it is faster than fixing the same thing on a live site.

Every route renders, at three widths

Not a sample. Every template with real content in it, because the page that breaks is always the one with the longest title or the missing image.

Every old address returns what the map says it should

Tested against the full inventory rather than a handful. A redirect that resolves to a 200 is not the same as a redirect that resolves to the right page.

Counts reconcile against the source

Entries, assets, references. A collection that migrated 41 of 42 posts looks completely normal until somebody goes looking for the missing one.

Consent and analytics behave according to the intended configuration

Test the supported consent states and verify that analytics initialization and events follow the configured behavior. Do not prescribe a universal firing order without inspecting the implementation.

The sitemap and robots rules say what you mean

Both are easy to ship from a template with defaults nobody chose.

DNS and the rollback are agreed in writing

Who changes it, when, and what the plan is if something is wrong an hour later.

The week after

The first week provides concentrated operational aftercare. Some problems emerge later, so ongoing search and integration monitoring need named owners.

Watch what the old addresses actually return

In the logs and in Search Console, rather than by spot-checking the ones you remember.

Watch the connected systems, not the site

Forms arriving, events landing, records being created. The site looking right and the systems working are different facts.

Expect movement in search, and measure it against the right baseline

Compare pages and queries before and after rather than one total against another. Nobody can promise no movement, and anybody who does is selling something.

Keep the Webflow site reachable until you are sure

Keep an agreed recovery path and source material available during the transition, then retire services only after their dependencies have been checked.

Give every checklist item an owner and an artifact

A checkbox is useful only when the team agrees what it proves. “Content migrated” can mean that a script completed, that record counts matched, or that an editor reviewed the resulting pages. Those are different milestones.

For each item, record the person responsible, the evidence required and the environment checked. Add a state such as open, passed, accepted exception or blocked. An accepted exception should include the person who approved it and the reason. This prevents an incomplete task from looking finished simply because somebody stopped investigating it.

Use a working sheet like this. The rows are illustrative and should be adjusted to the actual project.

Test a representative content pack

Create a small collection of difficult content before the templates are considered finished. Include the longest title, an article without an optional image, an older post with unusual formatting, a page with several references and an item that should remain unpublished.

This pack should be reused during development and final review. It is more informative than testing only ideal sample content. When a component changes, the same records reveal whether the change has broken wrapping, spacing, links or relationships.

For rich text, include headings, nested lists, inline links, images and any supported embeds or tables. For navigation, include long labels and the current active state. For forms, include validation errors and successful submissions. The aim is to exercise the actual content contract, including its less comfortable cases.

Record unsupported content explicitly. If an old embed is being retired, the editor should approve that decision. If it must remain, the new renderer needs a supported treatment before the migration is complete.

Use a rehearsal to expose launch dependencies

A rehearsal walks through the release without switching public traffic. It confirms that the build can run with the intended configuration, that the final import procedure is understood, and that the people responsible can access the systems they need.

The rehearsal should identify the last moment editors can safely change the source content, the command or process that imports the final changes, and the checks that must pass afterward. It should also show where production-only configuration differs from preview configuration.

Do not assume that a successful preview proves DNS access, certificates, redirects or production environment values are ready. Those responsibilities often belong to different people. A short rehearsal finds missing access while there is still time to resolve it normally.

A cutover checklist to copy into the release record

The checklist should fit the release rather than becoming an unexamined ritual. A same-domain hosting change differs from a domain move, and a static brochure site differs from a site with accounts or transactions.

Know when to pause or recover

Agree the blocking conditions before launch. Examples include widespread route failures, lost lead submissions, unintended publication of restricted content or an unusable publishing workflow. A recoverable visual defect may have a different treatment, provided the relevant owner accepts it.

Recovery also needs a content decision. If editors have published in the new CMS or visitors have submitted forms after launch, reverting the frontend does not automatically reconcile those changes. Record where new data lives and how it will be preserved.

The failure guide explains the checks behind these gates. The SEO guide covers the longer monitoring responsibility that continues after the first week.

If you take two things from this

Two especially useful disciplines are reconciling the inventory across sources and checking important operations at their destinations. Together they make omissions and silent failures easier to detect.

How the work runs against this list, what it costs, and how long it takes.

Documentation for this revision

• Webflow code-export documentation