Measure the source before trusting the migration.

An anonymous Webflow and Webflow CMS migration to Astro and Sanity where direct evidence corrected assumptions about content, rendering, and verification.

A migration needed a reliable source model before it needed more code.

The work moved a content-led website from Webflow and Webflow CMS to Astro and Sanity. The central problem was not only implementation; it was deciding which assumptions about the source could be trusted.

Marga was the sole engineer during July–August 2026, with a 12-day implementation window. The constraints were broad content and asset coverage, a dependable schema/query contract, and verification grounded in what could be inspected.

  1. Context: an existing content system

    Webflow and Webflow CMS were the source that had to be understood before its content could be represented in the destination.

  2. Problem: plausible assumptions

    Color usage, collection shape, fallback content, and URL parity could all look reasonable while still describing the wrong implementation problem.

  3. Constraints: one engineer, twelve days

    The implementation had to cover content, assets, pages, and verification without hiding uncertainty behind a broad or untested abstraction.

  4. Tech decision: explicit contracts

    Astro and Sanity formed the destination; Tailwind CSS and TypeScript kept presentation, content, and checks explicit enough to inspect.

Two workstreams met at a schema and query contract.

Destination implementation and source verification moved in parallel. They joined at an explicit schema/query contract: Sanity document shapes had to answer the Astro queries, while imported data had to retain the structure that the rendered pages needed.

  1. Build the destination

    Shape Astro pages, Tailwind CSS presentation, TypeScript types, and Sanity schema/query paths around content that could be checked.

  2. Audit and move the source

    Inspect Webflow and Webflow CMS content, URLs, and assets, then migrate structured documents and media according to what the source actually exposed.

Four measurements replaced plausible assumptions.

  1. Rendered color usage vs dead class frequency

    A class-frequency scan suggested one palette story; rendered usage showed which colors actually appeared. The implementation followed observed output rather than unused or stale declarations.

  2. Real source model correcting an assumed CMS collection

    Inspection of the real Webflow CMS model showed that the content did not match the assumed collection shape. The schema and import shape followed the source instead of forcing a convenient abstraction.

  3. Removing placeholder fallbacks that hid import/query failures

    Placeholder data made failed imports and queries look valid. Removing those fallbacks exposed missing data and required the actual paths to satisfy their contract.

  4. Validating deployment configuration through direct checks

    Direct configuration checks showed that the expected promotion path did not point to the current migration code. Repository state, not successful preview builds, became the evidence for that release check.

URL parity was a signal, not a complete verdict.

The route-parity harness normalized URL forms before comparison. It could verify that catalogued routes had corresponding outputs, but it could not prove that one trailing-slash setting was correct. The final form followed source URL behavior and measurement requirements rather than the green result alone.

The implementation left an inspectable trail of evidence.

Repository and migration checks covered more than 100 catalogued legacy routes, more than 100 structured documents, more than 1,000 assets, and more than 100 generated pages.

The production build completed with zero type or schema errors, and the parity check passed for every catalogued legacy route. These are build and route-inventory verification results; they do not claim observed production traffic, performance, or business behavior.

Planning a measured marketing website migration?

Share the source platform, content model, design direction, and verification needs. The Marketing Website Development service explains the visitor-facing implementation path, or start with a practical conversation.