Next.js to Astro – when your project is really content.

Yes – and that is the single most important technical fact about this migration. Astro is UI-framework agnostic with official integrations for React, Preact, Svelte, Vue, SolidJS and Alpine.js. An existing component gets imported and mounted as an island via a client:* directive. Components from multiple frameworks can be combined, but only inside an .astro file. So your component library is not thrown away, it is used more selectively.

The concepts are not ported, they are replaced. In Astro, server rendering is the default rather than a component property: by default the entire site is prerendered and static HTML is sent to the browser. Dynamics appear where you ask for them – via export const prerender = false plus an adapter for a route, or via server islands with server:defer for individual regions. If you have invested deeply in App Router composition, price that effort honestly before deciding.

Usually yes. The Pages Router sits closer to a classic page model: one file, one route, one data call per page. That is exactly what Astro maps onto – file-based routing, data fetched at build time or while the route renders on the server. It gets more expensive where nested layouts with their own loading states and server-component composition are deeply interwoven. We count those places in step one, before anyone quotes a number.

Middleware patterns are a property of Next.js, not a general web concept – so there is no port, there is a sort by purpose. Redirects and rewrites belong in the 301 map or in your hosting and CDN layer anyway. Personalisation can become a server island via server:defer, which renders independently on the server without blocking the first render. Gating real user accounts, on the other hand, is an application concern – and an argument for leaving that part on Next.js.

There is no one-to-one equivalent, and we would rather say that up front. ISR semantics are Next-specific. Astro offers three routes to the same goal: prerendered HTML that is rebuilt and deployed when content changes; individual routes with export const prerender = false plus an adapter, rendering on the server per request; and server islands via server:defer, where shell and main content are cached aggressively while personalised elements load in. If you revalidate fine-grained across thousands of routes, you are not migrating, you are redesigning.

They get sorted first, ported second. Endpoints that belong to the website – form handling, a webhook, a search index, a newsletter signup – follow the same pattern as any dynamic route: export const prerender = false and the adapter for your target runtime. Endpoints that belong to the application are better left where the application is, or promoted to their own service. Dragging them along because they happened to share a repository is the most common avoidable mistake in this move.

The calls get replaced, the image files do not. Astro ships built-in image optimisation: the Image component sets alt, loading and decoding and infers dimensions so no cumulative layout shift appears; the Picture component generates several formats and sizes with a fallback. Sharp is the default image service. Two things cost time: remote images have to be allowed in the configuration, and images in public/ bypass processing entirely – the latter is often a quiet quality loss during a move if nobody looks.

Each language version is its own route with its own URL prefix, and that is where the migration work sits: URL mapping per language, hreflang pairs, canonicals. The content itself we model per language in content collections; the Zod schema validates each language separately and reports missing translations in the build rather than on the live site. Honest about effort: after the number of templates, every additional language is the second biggest schedule mover. This very site runs bilingual – we know the trip hazards from operating it.

Yes. An Astro site is its own package with its own build; whether it lives in your existing monorepo next to the application or in a separate repository is an organisational decision, not a framework one. Shared React components can be imported as a workspace package, because Astro integrates React officially. The honest catch: components that assume Next-specific imports have to be rewritten at those points. How many that is becomes clear after the inventory, not before.

No. Static is the default in Astro, and prerendered HTML runs almost anywhere. For on-demand rendering there are official adapters in the @astrojs scope for Node, Vercel and Cloudflare – so you can stay, move to your own Node runtime, or go to Cloudflare. We decide that from your operational reality rather than taste: if you already have a working deployment with preview environments and a pipeline your team trusts, do not migrate it as a side quest.

That depends on how much client JavaScript your pages genuinely need. The structural difference is unambiguous: Astro removes all client-side JavaScript from components by default, whereas hydration is the normal case in the React model. We still quote no numbers until we have measured. We record your Core Web Vitals before and after the move using your own field data – someone else's benchmark says nothing about your project.

Not if the move is planned. Before we start we pull every indexed URL, keep the URL structure identical wherever possible and write a 301 redirect for each deviation before migrating rather than afterwards. Titles, heading structure and structured data of the load-bearing pages stay stable, and the redirects are tested before go-live. After launch we watch indexation and positions for several weeks and correct where needed. There is no guarantee, and anyone offering one cannot honour it.

Three factors set the frame, and page count is not one of them: the number of distinct page types, the depth of the content model, and how many Next-specific building blocks something depends on. As a working figure: a docs or marketing site with few layouts, one language and no CMS lands at 4 to 7 weeks; a grown site with a CMS, two languages and several dynamic routes lands at 8 to 14. Anything larger we cut into phases. Every variable is listed under Timeline.

Your old site stays online until the new one is signed off – it is built in parallel on staging. The switch itself is a change of target with fully tested redirects, scheduled into a low-traffic hour. We do not promise zero seconds, because DNS and cache behaviour are not in our hands. On volume: content collections ship built-in caching for thousands of entries, so 4,000 posts are a build question. It only gets expensive when those 4,000 posts use twelve different layouts.

Yes, and it is often the more sensible route. The usual split: the application stays in Next.js while the marketing site, blog and documentation move to Astro. Two deployments under one shared domain, separated by routing rules or subdomains. The product team keeps its stack, marketing gets a site it can maintain without engineering. Within a single project we otherwise migrate page type by page type, starting with the routes that carry no interactivity.

The objection is fair, but it lands softer than it sounds. Most of your code stays React – you hire for that exactly as before. An .astro file is essentially HTML with a script section in front of it; in our experience someone who knows React is productive within days. TypeScript is built in, with three tsconfig presets and astro check for type checking. What stays true: a job ad saying "Next.js" gets more applications than one saying "Astro". Which is why we write the README to be understood without us.

You can, and that is arranged before it is ever needed. The repository is yours, with its full history; the accounts are in your name and the build is explained in a README. Astro is free open-source software under the MIT licence – there is no licence that expires when you change supplier. On upgrades: Astro follows semantic versioning, the current major line is Astro 7, and extended maintenance with security fixes covers exactly one previous major. A predictable rhythm – but not one you can ignore for three years.

For what we built, we are. Before go-live there is a formal acceptance with a defect list; faults in our implementation are fixed within the contractually agreed warranty period at no extra invoice. Content errors, third-party outages and changes your own team ships are not part of that. Because every change is a commit, you can always trace what happened when – and roll it back. For ongoing operations there is support and maintenance as a separate agreement.

Yes. Content then lives in content collections with a Zod schema or in a connected headless CMS – Astro is CMS-agnostic and acts purely as the presentation layer. Without a CMS your team edits Markdown directly in the repository, and the schema reports missing fields before anything deploys. On request we also set up editing by chat: change a text, add a post, swap an image as a message to a Telegram bot, every change landing as a reviewable commit. New page types and layouts remain development work.

When your product is an application. When shared client-side state across routes is part of the product promise. When large parts of the surface are genuinely interactive rather than decoratively interactive. And when it simply works, measures fast enough and nobody is in pain – that last criterion is the most underrated one. A migration costs time, attention and risk; it has to give back something beyond "more modern". If we do not see that in your case, that is what the recommendation will say.

Yes. Astro is free open-source software under the MIT licence; there is no licence fee for the framework itself. Costs come from development, hosting and the services you connect – from the project, in other words, not from the tool.

Astro is an open-source project developed in public in the withastro repository on GitHub. The licence text is MIT and the copyright in it is held by Fred K. Schott. There is no subscription and no vendor who could switch off your access.

By default, no: the entire site is prerendered and static HTML pages go to the browser. You only need a runtime for rendering on demand – and then an adapter comes into play, officially for Node, Vercel or Cloudflare.

The preconditions are right: server rendering as the default, static HTML in delivery, and an image component that infers dimensions and so avoids layout shift. What actually decides it is still URL continuity, content and internal linking – not the framework.