How long a Webflow to Astro migration takes

A typical Webflow site moves in two to four weeks, then a week of watching what the old addresses return. That range covers most of the sites I am asked about, and it is the number I would work back from if you are choosing a month. It is not a quote.

The range is real. The date comes after the audit.

Anybody who gives you a date before looking at the site is quoting the range and hoping, which is fine right up until the collection with the multi-reference fields turns up in week two. The first stage of the work exists to replace the range with a date. It is short, it happens before anything is rebuilt, and what it produces is an inventory you can hold somebody to.

Where the weeks actually go

In shares rather than durations, because a share survives a site being twice the size and a duration does not. The content, URL and integration work is not a phase at the end; it happens inside the rebuild and the migrate step, which is the only way the site on the other side is the same site.

Audit: about a tenth of it

Pages, URLs, collections, integrations, interactions and custom code are inventoried against the live site. Short, and the stage that decides whether the rest of the estimate is right. A migration scoped without it is a guess with an invoice attached.

Rebuild: around half

The templates become components and the content model is designed. This is where the number of distinct templates shows up as time, which is why a four hundred page site and a forty page site can take the same number of weeks.

Migrate: a third, and the most variable

Content, assets and metadata move across, references are resolved, and the redirect map is built against the real inventory. A clean collection moves in an afternoon. One with multi-reference fields and items that drive layout is its own small project.

Hand over: the last stretch, plus a week after

Forms, analytics, routes and redirects are checked before anything is switched, then the deploy, then a week of watching what the old addresses return and what the connected systems receive.

Five things decide where a site lands

How many distinct templates there are

The single largest variable, and the one page count hides. Forty pages rendered from four templates is a shorter job than twelve pages built individually in the Designer.

How much the CMS is doing

A title, a body and an author moves quickly. Multi-reference fields, nested relationships and items that decide layout are a content modeling exercise before they are a migration, and modeling is thinking time rather than typing time.

How many integrations have to be re-established

Each one is rebuilt and then tested at its destination rather than at the button. Five integrations is not five times one integration, but it is not one either, and the testing is the part people leave out of their own estimate.

How much URL history the site is carrying

A hundred addresses is an afternoon of mapping. Several thousand, with historic paths, paginated archives and campaign URLs, is its own workstream with its own checks.

How quickly decisions come back

The one on this list that is yours rather than mine. Where the content lives afterward, which interactions are worth rebuilding, what gets deliberately retired: each of those is a short conversation that blocks a longer piece of work while it waits.

The same five decide the price, which is why the two questions get one answer. What a migration costs.

The four things that actually add weeks

Named so a schedule can be built around them, rather than discovered halfway through one.

A redesign running at the same time. Two projects sharing one deadline is how both of them slip, and it is the most common reason a migration takes twice as long as it was scoped for.

Content that is being rewritten during the move. Migrating content and changing it are different jobs, and doing them together means nothing can be verified against a source that is still moving.

A CMS decision that is still open when the rebuild starts. The content model shapes the components, so the components wait.

Approvals that need several people in a room. Not a problem, but worth putting in the schedule rather than discovering in week three.

The shortest migration is the one that moves the site as it is and changes nothing else. Everything else is worth doing, and worth doing after.

Distinguish effort from elapsed time

The number of development days and the number of calendar weeks are not the same measure. A task may require a few hours of work but wait several days for access, content decisions or an approval. A useful schedule makes those dependencies visible instead of treating every delay as slow development.

Ask for a sequence of deliverables and decisions. The content model needs approval before a large import is finalized. Representative templates need review before every route is checked. The final source-content update needs coordination before the public switch. Some work can overlap, but only after its inputs are stable enough.

This is why a schedule should name both the person doing the work and the person supplying the next decision. The aim is not to make the client responsible for every delay. It is to avoid leaving a real dependency outside the plan.

An illustrative four-week plan

The following is a planning example for a bounded marketing-site migration. It is not a promised duration or a standard allocation that fits every site.

Operational aftercare follows the public switch according to the agreed scope. Search monitoring can continue longer and should have an owner even after the migration developer's initial support period ends.

For a simpler site, several of these outputs may arrive within the same week. For a more complex one, a single content-conversion or integration task may need its own schedule. The useful part of the example is the dependency order, not the dates.

Identify the work that controls the launch date

Some tasks can proceed independently. Asset preparation can often happen while a template is being built. Documentation can develop alongside implementation. Other tasks are on the critical path: a decision or output must exist before the next stage can finish.

Common examples are choosing the publishing model, resolving an unusual content relationship, receiving access to the production form destination and agreeing the URL changes. If one of those remains open, adding more people to unrelated work may not bring launch closer.

Review the critical path during the project. A discovered integration dependency may change it. A decision to preserve the current design may shorten it. Keep the next blocking decision visible so the team can focus on what actually determines the date.

Prepare the inputs that prevent avoidable waiting

Not every input must be perfect on day one. The schedule should identify when each is needed and what can proceed while it is being assembled. That is more useful than either pretending everything is ready or refusing to start until every minor detail is settled.

Handle content changes without repeating the migration

When the source site keeps publishing during the rebuild, the plan needs a final synchronization step. Record whether the project uses a short freeze, a delta import or another agreed method. Assign time to review the result rather than treating the final import as an invisible task on launch morning.

Stable identifiers and a clear source-of-truth policy reduce rework. They help distinguish a newly published article from an existing record that changed and prevent repeated imports from creating duplicates. If destination editors are also making changes, define how conflicts are resolved.

This work belongs in the schedule because it protects the content the business produced while development was underway. Finishing the templates early does not remove it.

What to ask when a date changes

Ask what was discovered, which deliverable it affects and what options exist. A useful answer names the dependency and its effect. It might offer a smaller first release, a later feature or a revised launch date.

Avoid recovering time by silently dropping acceptance checks. If the scope changes, change the agreement visibly. A launch that meets a calendar date while losing submissions or content has not preserved the result the schedule was meant to deliver.

For the tasks behind these milestones, use the migration checklist. For how the same uncertainties affect the budget, read what decides migration cost.

The week after launch is part of the job

The migration service described here includes a week of operational aftercare after cutover: checking known addresses and connected systems. Issues can also emerge later, so the handover should name who continues search and integration monitoring.

Continuing to develop the site afterward is a separate arrangement rather than part of the migration. How the work runs, and how the search footprint is watched.