Migrating to Astro is a rebuild, not a conversion.

Not if the migration is planned. Visibility is lost in platform changes for four reasons almost every time: missing or blanket redirects, trimmed content, lost metadata, and a launch nobody watches afterwards. We build a complete redirect map, carry titles, descriptions, canonicals and hreflang across unchanged, mark in advance the passages that carry positions, and review Search Console in the weeks after the switch. Nobody serious gives a guarantee – a verifiable process is another matter.

No. There are tools that export content and convert it to Markdown, and Astro publishes official migration guides – among others for WordPress, Next.js, Gatsby, Hugo, Jekyll, Eleventy, NuxtJS, SvelteKit, Create React App, Docusaurus and VuePress. Those cover content and project structure, not your design. The presentation layer is rebuilt in every case. Anyone promising a one-click move either means the content export only, or bills the rebuild later.

In our experience: 3–5 weeks for a small marketing website with few templates, 6–9 weeks for a standard company website with a CMS, 8–14 weeks for a content site with a magazine or blog, and from 14 weeks for multilingual or heavily grown estates. A headless switch that keeps the editorial system sits at 4–8 weeks. That is measured from sign-off on the content inventory to switch-over day. The variables behind it are in the timeline table.

The frame is set by template consolidation, the volume and condition of the content to be transferred, the integrations and the size of the redirect plan. Moving the content is rarely the expensive part – rebuilding the front end is. So we quote both separately, so you can see what you are paying for. Which factors weigh how much is laid out on Astro development cost.

Yes, and it is often the best route. Astro is CMS-agnostic and stays the presentation layer. If your editorial team is settled, keep the backend and change only the delivery – with WordPress that is headless operation. Alternatively the content moves into a headless CMS, or straight into the repository as content collections. Which route fits is decided by your editorial routine, not by the technology.

They are on the same list as the pages. Images are carried over and moved into the Astro image pipeline, which derives dimensions and so avoids layout shift. PDFs usually keep their paths because they are linked and indexed. Old campaign URLs with query strings, paginated pages, category and tag archives and feed addresses all get redirect targets too. Those forgotten addresses are the most common cause of 404 waves after a relaunch.

Yes. On larger sites that is often the calmer route: one area runs on Astro first – frequently the blog or one language branch – while the rest stays in the old system for now. Delivery is split by path through a proxy in front, so visitors and search engines still see exactly one domain. It costs a little more setup work and lowers the risk considerably. Whether it is worth it depends on the size and revenue relevance of the site.

When the complaint is missing. If your site is fast enough, your team works happily and the maintenance bill is reasonable, switching burns budget. The same applies if your marketing builds pages visually and that works – then stay on Webflow, which we build just as gladly. And if the real problem is content or structure, an SEO audit does more than any change of technology.

Your old site stays online until the new one is signed off – the rebuild happens in parallel on a preview environment filled with your real content. Switch-over day is then a DNS or proxy change, not a shutdown. We lower the DNS time-to-live beforehand, put the change in a quiet hour and keep the old environment reachable for a while. The rollback plan is written down before anyone touches anything. Nobody serious gives you a zero-downtime guarantee; an environment that keeps running until you sign off is another matter.

Count in weeks, not days. Search engines have to crawl the new addresses, evaluate the redirects and reassess the pages – on a large estate the recrawl alone takes a while. Fluctuation in the first weeks is normal and not an alarm signal; a sustained decline is. That is why we set the monitoring window at six to eight weeks after switch-over, and submit the sitemap and changed URLs through IndexNow as well, so the reassessment does not have to wait for the next crawl.

Less than it sounds. An Astro site is HTML, CSS, TypeScript and component files; for the interactive parts there are official integrations for React, Preact, Svelte, Vue, SolidJS and Alpine.js. Anyone who knows one of those libraries is productive after a short ramp-up – unlike a grown theme with its own template language and plugin logic. On top of that, the code sits in your repository under an MIT-licensed framework. You are not tied to a vendor, you are tied to a common toolchain.

Then the work continues without us. The repository is yours from the first commit, hosting accounts and the domain are in your name, and we build in no proprietary intermediate step only we can operate. Handover includes documentation of the content structure, the deployment path and a walkthrough. Astro itself is MIT licensed. We are a small team and we say so openly – which is exactly why we set projects up so that any other agency can pick them up.

We are. What we built, we fix – within the warranty agreed in the contract and without a debate about responsibility. Acceptance runs against a concrete list: the redirect map, checked page by page, plus metadata and form routes. Anything that arrives afterwards as a new wish is further development and gets commissioned as such. Ongoing operation – updates, monitoring, small changes – is a separate matter: support and maintenance.

Yes, and that is explicitly the intention. Your team gets the repository, a standard toolchain with no bespoke detours, and an introduction to the content model. Because the fields are typed through a Zod schema, the structure explains itself and mistakes surface in the build rather than on the live site. So your developers inherit a documented model, not a grown riddle. We stay available for maintenance or larger extensions – as a choice, not as a dependency.

Not on our account. Freshly invested budget is a good reason to wait at least one cycle – provided the system delivers. What we suggest instead: measure what is actually bothering you first. Often it is not the platform but an overloaded homepage, a consent layer, or a structure nobody maintains any more. An SEO audit or a performance analysis costs a fraction of a migration and answers whether the move is worth it at all.

Multiple languages do not multiply your templates, but they multiply everything else: separate URLs per language, hreflang pairs in both directions, a redirect map per language branch, a language switcher with correct targets, and translations whose state has usually drifted apart. Add more approval paths, because one person rarely owns every language. Realistically such projects start at 14 weeks. The calmer route is often to move one language branch first and pull the others across in waves.

It depends where the centre of gravity sits. Astro is the presentation layer – category, product and content pages are served very well from it, while basket, checkout, payments and inventory stay in a specialised system or get connected headless. But if your business is essentially checkout, stock and customer accounts, and the content is incidental, that argues against a migration. We tell you that in the first call, before any effort is spent.

Honestly, more than most expect: one to three hours a week for questions and approvals, plus two larger blocks – deciding on the retirement list and signing off against the redirect map. We also need access to hosting, domain, analytics and Search Console. The most common cause of delay is not the technology, it is an open approval. That is why we name exactly one person on your side at the start who is allowed to decide – a committee is not enough.

For pages with no rankings, gladly – a migration is the best moment for it. For pages that carry positions we advise against doing both in one step. If the move and the rewrite happen together and visibility drops afterwards, nobody can tell what caused it: the redirect, the new copy or the layout. So we move one to one first, measure for six to eight weeks, and do the editorial rework as a separate wave afterwards.

Fair question – and Astro on its own does not answer it. What helps: statically served pages need no publicly reachable backend and no plugin ecosystem that quietly loads third parties. You can choose EU hosting, and the repository is yours. What remains real work: forms, analytics, web fonts, embedded video and consent management. We document the data flows of the new site so your data protection officer has something verifiable in hand instead of an assumption.

Yes. Astro is free and open-source software under the MIT licence, with no licence fees – not per page, per user or per revenue band. Costs arise for development, hosting and, if you use one, your CMS. That is one of the reasons teams see their recurring costs fall.

Astro is an open-source project developed in the open on GitHub in the withastro repository. The licence file names the MIT licence and Copyright (c) 2021 Fred K. Schott. The code is readable, forkable and not tied to a platform – unlike a closed website product.

By default, no: Astro prerenders your pages at build time and ships static HTML that any static host or CDN can serve. Only when individual routes need to render at request time does it need an adapter for the target runtime – officially, for example, Node, Vercel and Cloudflare.

Yes, that is the standard case. Posts live as Markdown or MDX in content collections with a Zod schema that validates every field. Index, category and author pages are generated from that, as are feeds and the sitemap. Alternatively the posts come from a headless CMS.

The starting conditions are good: server-rendered HTML by default, full control over titles, descriptions, canonicals and structured data, and no client-side JavaScript unless something asks for it. What ranks, though, is not the technology but content, structure and internal linking. Astro only removes the technical excuses.

We build on the current Astro 7 line. Astro follows semantic versioning, and exactly one previous major version receives extended maintenance with security fixes. That is why a planned upgrade path is part of the project with us, rather than something for “some day”.