Webflow CMS to Astro: Content Collections or a headless CMS

Publishing, not preference

Teams tend to choose a CMS on architecture and regret it on workflow. The useful question is not which system is better designed, it is what happens on a Tuesday when somebody needs a page live and the person who can do it is on holiday. Answer that first and the technical choice mostly makes itself.

Publishing requirements can be a strong reason to keep the current setup. A configured headless CMS can also support visual editing and approved page composition, so demonstrate the proposed workflow rather than assuming every alternative reduces editorial control.

What publishing becomes

The editing interface and the rendering strategy together determine publishing behavior. The sequence below describes a prerendered workflow; request-time rendering and caching need their own explanation.

1. Somebody makes the change. In the repository, in a CMS, or wherever the option below puts them. This is the step each answer moves.
2. It is saved. A commit, or a publish in the CMS. This is the moment that felt like going live on Webflow.
3. For a prerendered setup, a build and deployment update the public pages. Request-rendered routes can use a different update path; its caching and failure behavior should be documented.
4. The page is live. The visitor sees what the build rendered, not what the database holds.

Define what saving, previewing and publishing mean in the selected implementation. The team should know when content becomes public and how to identify a failed update.

Each is correct for somebody

Three honest answers. Each one says who it is right for and what it costs, because a comparison where one option has no downside is an advertisement.

Astro Content Collections

Astro Content Collections are a content layer that can load files or external data. In the repository-managed option described here, editors use the agreed file or Git workflow; a different loader does not require the same editing experience.

What it gives you.

• Configure schemas and relationship checks around the chosen loader and rendering path, then test representative invalid content.
• Content is versioned with the code, reviewed in pull requests and deployed with everything else.
• Nothing extra to pay for, run or keep patched.

What it costs you.

• Editing means a Git workflow. Some marketing teams take to that and some will simply stop publishing.
• No preview for a non-technical editor without building one.
• Images and files become repository concerns.

A headless CMS, such as Sanity

Teams who publish often, or where the people publishing are not the people deploying.

What it gives you.

• Editors get a real editing interface, previews and roles, which is the closest replacement for what Webflow gave them.
• Content is structured and queryable, and relationships survive the move properly.
• Ordinary editorial publication can be independent of engineering when the CMS, preview and delivery workflow are configured for it. Update timing depends on rendering and caching, not the CMS name alone.

What it costs you.

• Another system to model, host, pay for and keep in step with the site.
• The content model has to be designed rather than inherited. This is where most of the migration effort goes when a CMS is involved.
• Clear ownership is needed for content and implementation; avoid competing copies of the same editorial fact.

No CMS

Sites whose pages change a few times a year and are edited by whoever owns the codebase.

What it gives you.

• Nothing to maintain, nothing to pay for, nothing to break between systems.
• The fastest path to a site that just works.

What it costs you.

• Every content change is a code change.
• It stops being right the moment somebody non-technical needs to publish, and retrofitting a CMS later is real work.

A Collection is not exported, it is remodeled

Whichever answer you land on, the Webflow content model has to be reconstructed on the other side. The items can be moved once there is somewhere to move them to, and building that somewhere is the work.

• Collection. A schema: fields, types, and which are genuinely required.
• Collection item. An entry, in the repository or in the CMS.
• Plain and rich text fields. Choose a supported destination representation, then convert and verify its meaning and rendering.
• Reference and multi-reference. Map relationships deliberately and verify that the intended destination records resolve.
• Option fields. Enumerated values, checked rather than typed by hand each time.
• Image and file fields. Assets, moved deliberately and re-pointed. Nothing about this is automatic.
• Collection template. A route and the components it renders.
• Item slug. A route parameter, seeded from the URL that already exists.

Content migration itself is scripted rather than retyped, and verified by count and by spot check against the old site before anything is cut over.

Choose content storage and rendering separately

Where editors write content and when the website renders it are related decisions, but they are not the same decision. A CMS can supply content to a prerendered site or to routes rendered when requested. Repository content can be a good fit for reviewed releases. The implementation should make the relationship explicit.

For a prerendered setup, a content update commonly triggers a build and deployment. The previous release may remain public until the new one succeeds. For request-time rendering, freshness depends on data fetching, caching and the availability of the relevant services. Neither approach removes the need to explain when a change becomes visible.

Ask the team to demonstrate save, preview, publish and recovery. Those four actions make the chosen architecture understandable to the people who use it.

Compare the options against editorial tasks

This table describes implementation choices. Content Collections are a content layer and can load different sources; using them does not, by itself, determine the editor interface. A project may use a CMS and collections together rather than choosing only one.

Follow three hypothetical teams through the decision

A developer-maintained documentation site may value content changes reviewed alongside code. Repository files can fit that workflow, provided contributors understand previews, validation and deployment. The team still needs a clear process for images, references and failed builds.

A marketing team publishing campaigns every week may need a dedicated editorial interface. A headless CMS can provide approved sections, reusable records and previews when those capabilities are implemented. The project should demonstrate a new page and a normal correction before promising independence from engineering.

A small services site edited only a few times a year by its developer may not need a separate CMS. Keeping content close to the components can reduce operational complexity. The tradeoff appears when publishing responsibilities change or the content archive grows. Revisit the decision when the work changes rather than treating the initial choice as permanent.

These examples are decision patterns, not a ranking of sophistication. The right option is the one the team can operate while meeting its publishing requirements.

Make the failed-publish experience part of the design

A publishing workflow should explain failure as clearly as success. If a required field is missing or a deployment fails, the editor needs to know what happened, which content is affected and who can resolve it.

In a static workflow, it may be correct for the previous release to remain live while a failed build is investigated. The problem is when the editor believes the change is public and nobody notices otherwise. Add a meaningful status, notification or check appropriate to the setup.

Preview also needs clear boundaries. Editors should know whether they are seeing drafts, published content or a particular deployment. Access to unpublished material should follow the intended review process. These details often matter more to everyday publishing than the name of the CMS.

Migrate the model before migrating the archive

Start with representative records and the tasks editors need afterward. Map source fields into the destination deliberately, including relationships, publication states, assets and route data. A direct field-for-field copy may preserve an awkward structure that the migration was meant to improve.

At the same time, avoid redesigning the model without checking the existing content. Old articles, unusual embeds and missing optional values are evidence of what the renderer must handle. Use a sample import to test the model and record exceptions before processing everything.

Keep the URL contract visible. The content can move to a different system without changing the public address. Slugs, locale information and route relationships should be mapped intentionally rather than inferred from whatever filename the conversion happened to produce.

A publishing acceptance checklist

Use this checklist before completing the migration, not after the first editor becomes stuck. The Sanity modeling guide explains how to design the editorial controls, and the headless comparison connects them to the team's broader responsibilities.

Documentation for this revision

• Astro rendering documentation
• Sanity visual editing