Skip to content

Replacing a News-Portal Stack with Astro

When a heavy news or magazine CMS stack costs more than it returns, here is a practical path toward Astro, content modeling, and a calmer publishing workflow.

  • astro
  • cms
  • migration
  • architecture
  • web development

News and magazine portals often carry a decade of plugins, themes, and “temporary” customizations. At some point the stack costs more in maintenance and performance than it gives back in editorial flexibility. I’ve pitched and worked through a few of these modernizations, and Astro is a good place to land when the job is mostly publishing rather than building a social network.

Signs you’ve outgrown the old stack

  • Page weight and TTFB that caching can’t fully hide
  • Plugin conflicts on every update
  • Editors working around the CMS instead of with it
  • A theme forked so far that upstream upgrades are out of the question
  • Features you pay for (or are afraid to remove) that nobody uses

If the product is articles, sections, authors, and media, and not a bespoke web app, a content-first static or hybrid frontend is worth considering.

What you’re really migrating

“WordPress to Astro” is a slogan, not a plan. The actual migration covers:

  1. Information architecture: sections, tags, authors, evergreen vs news
  2. URLs: redirects are most of the migration
  3. Editorial workflow: drafts, schedules, previews
  4. Design: templates that match how stories are told
  5. Integrations: newsletter, ads, analytics, and the paywall if there is one

Underestimate redirects or skip rehearsing with editors and the cutover will hurt.

A sensible target shape

  • Headless CMS (Sanity or similar) for structured articles and landing pages
  • Astro for routes, templates, and mostly static HTML
  • On-demand revalidation or webhooks when a story publishes
  • Islands for comments, live widgets, or paywall UI if needed
  • A CDN in front

Keep dynamic parts intentional. There’s no need to rebuild a monolith in Node just because the old site felt “dynamic.”

Migration tactics that reduce risk

  • Start with a section or a secondary brand, not the homepage on day one
  • Map every old URL before designing the new templates
  • Run the new stack in parallel and compare templates with real stories
  • Train editors on the new studio with their own content, not lorem ipsum
  • Measure LCP, INP, and time to publish before and after, so stakeholders see numbers

When not to rip it out

If the business logic lives in the CMS (complex membership, heavy personalization, a plugin ecosystem that is the product), a careful upgrade or a different architecture may fit better than Astro. Be honest about what the product is.

Wrapping up

For me the reasons to replace a news-portal stack are practical: editors get a simpler tool, readers get faster pages, and developers get a codebase they can change without digging through years of workarounds. Astro fits when content is the product and plain HTML can do most of the work.

Back to blog