When Next.js is the right choice, and when it is not
Next.js was built for applications, and in that role it is hard to replace. Logins, user dashboards, carts, admin panels, content that depends on who is signed in - server-side rendering and the full React model genuinely earn their place there.
A company website, a blog, a landing page or a content platform work differently. Their content is the same for every visitor and changes rarely, yet every page view still goes through the same rendering and hydration machinery.
Migrating to Astro makes sense in exactly that second case - not because Next.js is bad, but because a content site is paying for capabilities it never uses. We build applications in Next.js ourselves and we keep doing it, so the recommendation depends on what your project actually is.
What happens to your React components?
Astro runs React components natively, so existing code does not get thrown away. During the audit we split components into two groups: the ones that only render content, and the ones that genuinely need interactivity in the browser.
The first group is rendered to HTML at build time and ships no JavaScript at all. The second stays a React component but loads as its own island - when it is needed, rather than together with the entire page.
In practice the largest part of the work is not rewriting components, it is deciding which one belongs in which group.
What does the architecture look like after the migration?
In Next.js the view, routing, rendering and data layer are all part of one application, and hosting has to be able to run it. After the migration those layers are separated.
Content lives in a headless CMS, usually the same one as today, the frontend is Astro and React components in a repository, and the build output is static files served from Cloudflare infrastructure. The parts that genuinely have to be dynamic stay on the edge - as a deliberate exception rather than the default mode for the whole site.
Forms and API endpoints move to edge functions, so none of your current functionality disappears.
What drives the scope and the price?
Every migration is different, which is why we do not work from off-the-shelf price lists. The scope depends mostly on the number of page types, the number of components and the state of their code, the number of API endpoints, and the integrations and forms that have to move.
It also depends on how much of the site truly needs on-demand rendering, whether the design stays as it is, and where the content should live in the end.
After the audit we prepare a concrete scope, the risks, a recommended architecture, a timeline and a quote. Only then do you decide whether to start.
What happens after launch?
The migration does not end on the day we switch DNS. For the first weeks we monitor indexing, 404 errors and Core Web Vitals to make sure Google has moved cleanly to the new version.
From there the site grows through a controlled process: changes go through the repository, code review and staging, and deployments are automated and reversible.
