Capability · Astro migration
Astro migration: ports the marketing surface into your GitHub.
8–12 week migration from WordPress / HubSpot / Webflow to a static-first Astro stack. Included on a 3-year retainer, $35,000 add-on with annual.
What this is
The Astro migration ports your marketing surface from a CMS you fight with into a static-first stack you own. We sell it as a multi-year retainer item rather than a POC component because it should land after the content engine and technical SEO work has proven worth keeping; until then, it is premature.
This site itself runs on the same stack. The public repository is the reference implementation — same Astro / Tailwind / Cloudflare Pages stack, same schema graph patterns, same CI guardrails. We migrate clients onto something we operate ourselves.
Why Astro
Three reasons that hold up under scrutiny.
Performance
Astro static deploys ship near-zero JavaScript by default. The Core Web Vitals targets that take heroic effort on a WordPress + plugin stack — LCP under 1.5s, INP under 200ms, CLS under 0.05 — fall out almost for free. The performance budget for this site is 50KB first-load JS per route; we hit it without trying.
Productisation
Your marketing site becomes a code artifact your dev team can review, branch, ship, and roll back. The cadence we set up in the engagement compounds because publishing is git push rather than a CMS ticket. Schema graph changes ship as PRs with diff visibility. Build-time validators (anchor-bleed in meta, unthreaded @graph) catch regressions before deploy.
Discoverability
Server-rendered HTML at first request, no hydration delay. Every byte of content is in the initial response — answer engines crawling get the full page on first hit. JavaScript-heavy sites where content arrives via React hydration are increasingly weighted-down in citation rankings; static-first sites are weighted-up.
How we run it
Weeks 1–2: discovery + URL inventory
Full URL inventory (sitemap + Google Search Console + GA4 cross-check). 301 map drafted: every existing URL either ports cleanly or 301s to a defined canonical. CMS decision: do we ship pure static or static + visual CMS layer?
Weeks 3–6: build
Astro project scaffold ports your existing marketing surface page-by-page. Schema graph implemented as code (this site’s src/lib/schema-graph.ts pattern). Build-time validators ported. Content layer connected to whatever CMS we agreed on (Sanity headless, TinaCMS, or pure-MDX).
Weeks 7–8: soak
Beta domain stands up the new site. SEO continuity rehearsal: schema graph validated, sitemap verified, robots and llms.txt published, canonical and 301 map checked end-to-end. Two-week soak under your team’s review.
Weeks 9–10: cutover
DNS cutover with warmup. CF Pages SSL provisioned. Old CMS goes dark; 301s ship from old URLs to new canonicals. Rank and citation tracking for four weeks post-cutover.
Weeks 11–12: verify + handover
Schema graph re-verified post-cutover. Lighthouse CI run on the canonical landing pages. Rank deltas reported. Marketing-site repo handed to your dev team with a written runbook.
What you get
- Astro project repo in your GitHub org with full deploy config (CF Pages, GH Actions CI, schema validators, anchor-bleed checks).
- Schema graph as code — same threading pattern as this site, ports between projects.
- Visual CMS layer (optional, picked at kickoff) — Sanity / TinaCMS / Contentlayer / pure-MDX. Authoring team keeps a familiar UI.
- 301 map — full URL inventory mapped to new canonicals; rank-loss avoidance documented.
- CWV report — pre vs post; deltas published.
- Runbook — your dev team’s how-to for shipping new pages, running schema validators, deploying via CF Pages.
When to commit
If you are renewing on a 3-year retainer, the migration is included; we typically ship it in Year 1 of the renewal. If you are renewing on annual, it is a $35,000 add-on; we run it in the off-quarter when the cadence cycle is gentlest. See pricing for the multi-year math.