For engineering-led teams whose marketing pages are trapped in the product's Next.js repo, release process, and mental overhead.
Why migrate
Content moves into a CMS instead of a pull request, so a copy change doesn't need a code review and a deploy.
The marketing site ships on its own cadence rather than riding the product's release train.
Astro ships zero JS by default. Marketing pages stop paying the cost of a hydration model they never needed.
No server components, caching layers, or rendering-mode decisions for pages that are fundamentally documents.
Astro islands let you keep the React components that genuinely need interactivity, and drop the rest.
Static output on a CDN instead of a Node runtime, with fewer moving parts to monitor.
Honest assessment
This is a narrower migration than the others and it's the wrong call for plenty of teams. Worth being precise about it.
Nothing. This migration usually carves the marketing pages out of the app and leaves the product exactly where it is.
The two are then routed together, either on separate subdomains or via edge rewrites so the marketing site and app share one domain.
Publishing experience
The point of this migration is usually not performance. It's that marketing can no longer be blocked on engineering for a headline change.
Editors publish through a visual CMS with preview, rather than opening a pull request against the product repo.
Design tokens and component patterns stay consistent across the marketing site and the product.
Interactive React components can be embedded as islands, so nothing genuinely dynamic is lost.
Architecture
The product app keeps its own pipeline. Only the marketing surface moves, which is what makes this a low-risk migration.
Process
We map which routes are genuinely marketing pages, which are app surfaces, and which are ambiguous and need a decision.
Marketing content is modelled as CMS collections, with MDX and hardcoded copy extracted out of the repo.
Existing components are translated into the Astro component library, reusing your design tokens rather than reinventing them.
Astro build, component library, CMS wiring, and edge rewrites so both surfaces coexist on one domain.
Redirect testing, Core Web Vitals, accessibility audit, analytics parity, and route-by-route comparison against production.
Staged rollout, usually route by route, then Search Console and vitals watched closely for the first weeks.
Content migration
Copy embedded in JSX, MDX files, and JSON fixtures is extracted and modelled as structured CMS content.
Presentational React components are ported to Astro components; genuinely interactive ones stay React and become islands.
Images move to the Astro asset pipeline with build-time optimisation replacing runtime image handling.
Route-by-route diffing against production, so the new site is verifiably equivalent before any traffic moves.
SEO & redirects
Every indexed URL is pulled from Search Console, analytics, the sitemap, and a fresh crawl, not just the ones the CMS knows about.
A one-to-one 301 redirect map, built and tested against the live inventory before launch.
Titles, descriptions, canonicals, Open Graph, and structured data carried across and diffed page by page.
Sitemaps, robots, and internal linking rebuilt, then submitted and monitored through Search Console after cutover.
Rankings, crawl errors, redirect hits, and Core Web Vitals monitored for the first weeks, with fixes shipped fast.
Design options
Keep the current design, move the platform. Lowest risk and the fastest route to a better-performing site.
Talk through this optionRebuild on a proper component system and modernise typography, spacing, and the templates that matter most.
Talk through this optionNew IA, new visual system, new site, with the migration handled underneath it as a single project.
Talk through this optionThe details
Relevant work
AI builders got your site live fast. We turn it into something that ranks, converts, holds up to scrutiny, and your team can maintain.
View migration pathMove from Webflow to Astro and a headless CMS without giving up marketing autonomy, keeping your content, SEO equity, and integrations.
View migration pathMove off plugin-heavy WordPress onto a fast Astro frontend with a visual CMS marketing can still run, with content, SEO equity, and integrations intact.
View migration pathFAQs
No. This migration is deliberately scoped to the marketing surface. The product app stays on Next.js and keeps its own pipeline.
Yes. Presentational ones get ported to Astro; interactive ones stay React and run as islands. Shared design tokens keep both consistent.
Edge rewrites. Marketing routes serve from the Astro build, app routes proxy to the Next.js deployment. Visitors see one site.
Often yes, because the real win is workflow: marketing stops needing a developer. If neither performance nor workflow is a problem, don't do this.
Usually four to eight weeks, since the design system typically already exists and only the marketing routes are in scope.
The Astro site gets its own pipeline, which is part of the point: marketing deploys stop being coupled to product releases.
