When to leave Webflow, and when to fix the site instead

Leaving Webflow makes sense when the new setup solves a recurring problem and your team can operate it afterward. It makes less sense when a repair to the existing build would do the job.

I work with Webflow and Astro. My starting point is not which platform is newer. It is what the site needs to do, which changes the team makes regularly, and who will own the result.

Signals that deserve a migration review

The content model is working against the site

A growing catalog, repeated content duplication or difficult relationships can expose a mismatch between the model and the pages that need it. Identify the exact constraint first: stored items, Collections, lists on a page and nested content are different limits.

Check the actual account and current product documentation before deciding a cap is unavoidable. Webflow changed its plan structure in 2026, with different transition dates for existing accounts.

A migration becomes more persuasive when the requirements still do not fit after considering a better model and the available plan options.

Important behavior belongs on a server

Account-specific information, protected data and application logic need an appropriate execution environment. But distinguish a site built in the Webflow Designer from the wider Webflow platform. Webflow Cloud supports code-based applications alongside Designer-built sites.

The decision may be to add an application, not rebuild the entire marketing site. Work out where the boundary belongs before choosing a destination.

Engineering already owns most meaningful changes

Look at recent requests. If a developer is already needed to maintain scripts, integrate data, review behavior and coordinate releases, a repository-based workflow may make that work easier to organize.

That is a stronger reason than preferring a framework. Write down the work the new setup should improve: code review, testing, reuse, deployment or changes made with coding agents.

The marketing site is becoming part of the product

Shared data and design conventions can make a separated marketing build expensive to maintain. That does not mean putting everything in one repository automatically solves the problem. The team still needs compatible components, clear ownership and a release process.

A useful migration proposal explains what will actually be shared and what should remain separate.

Reasons to fix Webflow first

A heavy image, duplicated tracking script or awkward Collection setup can be an implementation problem rather than a platform problem. Moving it without diagnosis can preserve the same problem in different code.

The team's publishing workflow also matters. If marketers regularly create layouts in the Designer and do not want to take on a component-based publishing model, that capability has real value.

An Astro site can offer visual editing through a configured CMS such as Sanity. That needs to be designed and implemented; it is not the same product experience by default.

You do not have to move everything

There are three useful options to investigate: repair the current site, move the part that has outgrown it, or migrate the full site.

A hybrid setup can preserve a familiar marketing workflow while putting an application or specialized content area elsewhere. It can also introduce extra systems to maintain. Treat it as an architectural option, not a universal compromise.

Use recent requests as the evidence

Before comparing platform features, collect a handful of changes the team actually attempted. Include something routine, something difficult and something urgent. A copy edit, a new campaign page, a new content relationship, a CRM change and an emergency correction make a more useful sample than a list of features nobody currently needs.

For each request, record who did the work, what blocked it and whether the same blockage has happened before. The distinction matters. A one-off integration may not justify replacing an otherwise effective publishing environment. A recurring need that requires fragile custom code every week may deserve a different architecture.

Then describe how the request would work in each option. If the proposed migration cannot explain who performs the task and what they use, its benefit is still an assumption.

Compare repair, a partial move and a full migration

A repair keeps the existing platform and improves its implementation. It can preserve a familiar editing workflow and avoid the work of moving content, routes and integrations. Its limit is that some requirements may still be awkward after the cleanup.

A partial move gives a defined area its own implementation. That could be a specialized resource section or an application that should not share the marketing site's publishing workflow. It can solve a specific problem without moving everything, but it introduces a boundary the team must operate: navigation, analytics, styling, authentication where relevant, and potentially multiple deployment systems.

A full migration gives the team one planned destination for the public site. It also requires a complete inventory and an explicit replacement for the platform services the site currently uses. The benefit should justify that transition work and the responsibilities that continue afterward.

None of these options is inherently the most mature. The useful choice is the smallest one that solves the established requirement without creating an operating burden the team cannot support.

Try the future publishing workflow before choosing it

Build or demonstrate a representative page in the proposed model. Ask a marketer to edit its headline, replace an image, reorder an approved section and create another page. Then ask for a design change that the model does not already support.

The exercise reveals the boundary between editorial freedom and development work. A component-based CMS can make ordinary page assembly straightforward while keeping new visual patterns under review. That may be exactly what the team wants. A team that frequently invents layouts in a visual canvas may value a different balance.

Also test the awkward moments: an invalid field, a failed preview, an unavailable reference and a publishing mistake that needs recovery. Those cases show whether the workflow is understandable after the initial demo ends.

A migration should improve the work for the people who will use it. Developer preference is relevant to maintainability, but it is only one part of that assessment.

Write a decision memo with an explicit threshold

A short decision memo can contain the current problem, the evidence, the options considered, the chosen scope and the expected result. It should name the ongoing owner and the conditions that would make the team reconsider.

For example, a hypothetical team might choose to keep Webflow for marketing and separate a customer portal because the portal needs account-specific behavior while marketing still relies on the existing Designer workflow. Another might choose a full move because engineering already maintains most changes and the team wants a reviewed collection of reusable page sections.

Those examples are architecture decisions, not claims that either arrangement always saves money. Costs depend on the services, maintenance and transition work involved. Record them separately from the desired outcome so the proposal can be evaluated honestly.

Signs that the migration is not ready to start

These are unresolved decisions, not permanent reasons to stay. Resolve them and the case may become much clearer. If they remain open, a discovery phase or a targeted repair is a better next step than a full rebuild commitment.

Use what Astro gives you to assess the destination and Webflow versus a headless setup to compare the work people will do after the move.

Make the decision against real work

Take a handful of recent changes and ask how each would happen in the proposed setup. Include a copy edit, a new page, a layout change, an integration update and an urgent fix.

Then ask who can do each task, what approvals it needs and what it costs to keep the setup working.

If the answers are clearer after migration, there may be a good reason to move. If they are only newer or more technical, there is more scoping to do.

Discuss your migration. Start with the current site and the work that is getting difficult, not a framework commitment.

Sources

• Webflow: May 2026 plan changes and rollout. Checked September 18, 2026.
• Webflow Cloud: Introduction. Checked September 18, 2026.
• Sanity: Visual editing. Checked September 18, 2026.