A WordPress to Astro migration with Web Aloha costs $999 for a small site of up to 5 pages without a blog, $1,499 for a business site with up to 15 pages and 20 blog posts, and $2,499 for larger sites. Those are our published package prices in USD, and the final quote follows a review of your site. What moves a project from one package to the next is scope: how many pages and templates you have, how the content is built, which forms and integrations must keep working, and whether a store, bookings or a second language are involved.
This guide is the worksheet we use to scope a migration, written so you can fill it in yourself. It covers what to count, what drives the cost, what has to survive the move and how to prove it did, an acceptance checklist, how you will edit the site afterwards, and when not to migrate at all.
Short on time? The free WordPress to Astro migration assessment asks 24 questions and ends with a plain-English scope summary and a starting price. Still deciding whether to switch platforms? Start with WordPress vs Astro for business.
Step 1: Count Pages, Templates and Everything Else That Moves
Pages versus templates
Most migration quotes that go wrong start with one confusion: pages versus templates.
- A page is a URL with its own content: your homepage, the About page, one service page, one blog post.
- A template is a layout that pages share: the blog post layout, the service page layout, a category archive.
Forty blog posts that share one post template are mostly content conversion. The template is built once and the posts flow into it. Ten pages that each have a unique Elementor or Divi layout are ten pieces of design and component work, because page-builder markup is rebuilt as clean components rather than copied. So count both, and flag every page that was built with a page builder.
To get the numbers, export your XML sitemap or run a crawl for the list of public URLs, then group those URLs by layout. The Pages report in Google Search Console shows which URLs actually earn impressions and clicks, which tells you what must not break.
The scope worksheet
| What to count | Where to find it | Why it changes the scope |
|---|---|---|
| Pages | Your sitemap or a crawl. Count unique content pages, not archives. | Sets the package size |
| Templates and unique layouts | Group pages by layout and flag every page-builder layout | Each one is designed and built as a component |
| Blog posts and other content types | Posts, plus anything with its own editor screen: projects, team members, FAQs, custom post types | Each type needs a content model and a conversion step |
| Archives and taxonomies | Category, tag, author and date pages, and pagination | Each URL needs a keep, redirect or retire decision |
| Media and downloads | The media library, PDFs and image alt text | Files move with their URLs and alt text |
| Forms | Every form, where submissions go, spam protection and email notifications | Each is rebuilt as a server endpoint or a form service, then tested |
| Plugins | Only the plugins that do a business job: forms, bookings, SEO output, search | Plugins don’t move to Astro. Each job is rebuilt, replaced by a focused service or retired. |
| Integrations | Analytics, tag manager, CRM, email marketing, chat, maps, booking widgets | Each is reconnected, replaced or retired, one by one |
| Existing redirects | Your redirect plugin’s rules and any server rules | They move into the new host’s redirect configuration |
| Languages | Each language version and its hreflang tags | Every language needs its own URL, metadata and hreflang checks |
| Store, bookings and memberships | What customers actually use: cart, checkout, accounts, booking calendars, payments | Usually kept on a specialist platform alongside Astro, and quoted separately |
| Editors | Who publishes, how often, and whether they need previews or approvals | Decides between Markdown files and a CMS (see step 5) |
Two free tools speed this up. The WordPress Theme and Plugin Detector shows the plugin signals visible on your public pages, which is a head start on the plugin list. The SEO Migration Redirect Mapper turns an old and a new URL list into a redirect plan you can review.
Some plugins need no replacement at all. Caching, minification and firewall plugins exist to keep WordPress fast and safe at runtime, and static pages don’t have that runtime to protect. Leave them off the list so they don’t inflate the quote.
Step 2: See What Drives the Cost
Every Web Aloha migration package includes content transfer, URL preservation, 301 redirects, SEO setup and deployment to a global CDN. The worksheet then decides which package fits:
| Cost driver | Simple Migration ($999) | Business Migration ($1,499) | Complete Migration ($2,499) |
|---|---|---|---|
| Pages | Up to 5 | Up to 15 | Unlimited |
| Blog posts | No blog | Up to 20 | Unlimited |
| Content | Moved into a modern Astro design | Plus a refresh of key pages | Full rewrite of every page |
| SEO | URLs, 301 redirects, metadata and schema | Plus advanced SEO and GEO work, sitemap, robots.txt and llms.txt | Plus competitor analysis and 6 new SEO blog posts |
| Editing after launch | Markdown files, with a CMS as an optional add-on | Markdown files, with a CMS as an optional add-on | Headless CMS integration included as an option |
| Checks and monitoring | Lighthouse and Core Web Vitals QA before launch | Plus 2 weeks of monitoring after launch, including rankings | Plus 4 weeks of monitoring and 1 round of updates after 3 months |
| Delivery | Within 7 days | Within 14 days | Within 21 days |
Whichever package fits your content, these are quoted separately after a review, because no package can price them blind:
- A live store with cart, checkout and orders, or subscriptions.
- Memberships, logins or gated content.
- Bookings, events or payments that run inside WordPress. An external booking platform can usually stay as it is and simply be linked or embedded.
- More than one language, with hreflang.
- Critical two-way integrations, such as a CRM or inventory system that writes back to the site.
- A new domain or brand at the same time as the move.
The full inclusions for each package are on our WordPress to Astro migration service page. These are Web Aloha’s prices, not a market average. The case studies below don’t publish what those clients paid, so don’t read the package prices as the cost of those projects.
Step 3: Decide What You Keep, and How We Prove It
A migration is only as good as its evidence. For everything you keep, agree up front how it will be checked, then check it on staging before launch and again on the live domain.
| What you keep | How we prove it | A free check you can run |
|---|---|---|
| URLs | A URL parity check: crawl the old site and staging, and confirm every old URL returns 200 at the same address or reaches its closest new page in one 301 hop | SEO Migration Redirect Mapper |
| Redirects you already have | A redirect map that includes the old plugin and server rules, tested for chains, loops and 404s | Redirect Checker |
| Titles, descriptions, canonicals and robots rules | A metadata diff: old against new, URL by URL | Meta Tag Checker and Canonical URL Checker |
| Structured data | Schema validation on every template, then Google’s Rich Results Test on key pages | Schema Markup Validator |
| Analytics and Search Console | Tags fire on every template, conversions record, the Search Console property carries on and the new sitemap is submitted | Sitemap Checker and Validator |
| Forms | A test submission from every form reaches the right inbox or CRM, with spam protection and error messages working | A manual test on staging and after launch |
| Content, images and internal links | Content coverage per URL, alt text present, no broken internal links | Broken Link Checker and Image SEO Checker |
| Language versions | Each language keeps its URL, metadata and hreflang pairing | Hreflang Checker |
| Speed | A performance budget for representative templates, measured before and after with the same tool, device and location | Website Performance Checker |
A performance budget is a limit you agree before the build, for example a maximum Largest Contentful Paint and page weight for the homepage and a blog post on a mid-range phone. Record the WordPress baseline first with the same settings, so the before and after are a fair comparison.
Step 4: Use This Acceptance Checklist
Sign off every line before you call the migration done.
Before the build
- The URL inventory is complete: sitemap, crawl, the Search Console pages that earn impressions, and old redirects.
- Every URL has a decision: keep, redirect (with its target) or retire.
- Every business-critical plugin has a replacement plan.
- The WordPress baseline is recorded: speed on representative templates, analytics conversions, and the top Search Console pages and queries.
- A full backup of the WordPress files and database is stored somewhere you control.
On staging
- Every kept URL returns 200, and every changed URL reaches its target in one 301 hop.
- Titles, meta descriptions, canonicals, H1s and robots rules match the agreed values.
- Structured data validates on every template.
- Images, downloads and alt text are present, and internal links have no 404s.
- Every form submits to the right place, and analytics and conversion events fire.
- Performance and accessibility meet the agreed budget on representative pages.
- Staging is hidden from search engines with a password or noindex, so it can’t compete with the live site.
Launch day
- DNS and SSL switch over, with the WordPress site still available as a rollback.
- The staging block is gone from production: no stray noindex, and robots.txt allows crawling.
- The new XML sitemap is live and submitted in Search Console.
- A crawl of the live domain confirms status codes and redirects.
In the weeks after launch
- Search Console pages and queries are compared with the baseline.
- New 404s and unexpected redirects are fixed as soon as they appear.
- Form submissions and analytics conversions are checked against normal levels.
- The WordPress backup is kept until the new site is signed off.
Step 5: Choose How You Will Edit the Site After Launch
This is the decision most people forget until after launch. Astro has no built-in admin screen, so choose the editing route before the build: it shapes the content model and sometimes the price. On a static site, a content change goes live when the site rebuilds, which a CMS can trigger automatically when the editor saves.
| Editing route | Good for | Honest trade-offs |
|---|---|---|
| Markdown or MDX files in Git | A technical owner, or a site that changes a few times a year | Nothing extra to pay and no admin to patch, and every change is versioned. Editors need to be comfortable with text files and Git, or send changes to a developer. |
| A Git-based CMS, such as Decap | One or two editors who want a web form instead of files | Content stays in your repository and stays portable. It has fewer workflow features than a full CMS. |
| A hosted headless CMS, such as Sanity or Contentful | Teams that need previews, roles, scheduling and approvals | The friendliest editing, but another account and API to manage, often a subscription as you grow, and your content lives on their platform, so check the export options. |
| WordPress as a headless CMS | Editors who want to keep the WordPress admin they know | Familiar editing, but WordPress still needs updates and security work as a private back end. |
| We make the changes | Sites that rarely change | Nothing to learn. Our website maintenance plans cover Astro sites, and the Pro Maintenance plan includes content updates. |
Whichever route you choose, the handoff should include a short walkthrough for adding a page and a post, a note of how changes are published and rolled back, and the domain, hosting and CMS accounts in your business’s name.
Evidence: Two WordPress to Astro Migrations We Have Published
Wellington House Repiling: a service business on WordPress and Elementor
- Starting point: a WordPress and Elementor trade site with a mobile PageSpeed score of 78, a 4.4-second Largest Contentful Paint, no dedicated service pages, minimal schema and a contact form that depended on a WordPress plugin.
- What moved: every original page (homepage, about, services, gallery, blog index and contact) and three blog posts, rebuilt in Astro and deployed on Vercel.
- What changed on purpose: six dedicated service pages for 14 pages in total, a rebuilt 67-image gallery, self-hosted fonts, and the contact form rebuilt as a serverless function that sends through a transactional email API.
- Structured data: schema on all 14 pages. The business is described as a HomeAndConstructionBusiness, the service pages carry FAQPage, Service and BreadcrumbList schema, and the blog posts carry Article schema.
- Measured result (Google PageSpeed Insights, mobile): Performance 78 to 98, Largest Contentful Paint 4.4 s to 1.8 s, Total Blocking Time 120 ms to 0 ms and Accessibility 87 to 95. These performance measurements do not establish an effect on search rankings.
Scope lesson: moving the original pages and posts was the migration, while the new service pages and the gallery were new content and design work. List the two separately in your worksheet so each is priced for what it is. Read the Wellington House Repiling case study.
Gridinta: a bilingual site with a growing article library
- Starting point: a bilingual English and Lithuanian industrial website on WordPress that was already winning search visibility, with more than 40 search-led articles.
- What had to survive: the design, URLs, search equity and publishing structure built around that content.
- How it was handled: a custom static Astro build on Vercel. Canonical URLs, English and Lithuanian hreflang, sitemap output, robots controls and legacy redirects are handled deliberately rather than by overlapping WordPress plugins. Organization, LocalBusiness, WebSite, WebPage, BreadcrumbList, BlogPosting and FAQ data connect as one schema graph, and forms use server-only delivery.
- Measured result (the same public homepage, before and after): GTmetrix Largest Contentful Paint 2.4 s to 477 ms (London, Chrome 142 and Lighthouse 12.6.1, on 4 and 7 August 2026). WebPageTest time to first byte 2.024 s to 0.237 s and requests 53 to 18 (iPhone 15 profile from Amsterdam, 5 August 2026). PageSpeed Insights mobile Speed Index 3.4 s to 0.9 s, layout shift 0.039 to 0, and the SEO score retained at 100.
Scope lesson: a second language roughly doubles the URLs that need parity checks, and hreflang must pair every page with its translation. That’s why multilingual sites are scoped separately rather than counted as extra pages. Read the Gridinta case study.
Both results are dated lab tests of specific public pages. They show what a careful migration can deliver, not a guarantee for your site, which is why every project starts with its own baseline.
When Not to Migrate
Astro suits content-led websites. It isn’t always the right move, and a good migration partner will tell you so.
- WordPress is healthy and there’s no measured problem. If speed, maintenance and publishing are fine, a migration buys you little. Speed optimization or a WordPress care plan is a smaller, cheaper step.
- The site is really an application. Memberships, courses, communities, customer dashboards and complex WooCommerce stores with subscriptions depend on plugins that don’t move to a static site. The best case is a hybrid: Astro for the public pages and a specialist platform for the rest.
- Editors need page-builder freedom. If editors design every page themselves in a visual builder and won’t accept structured sections or a headless CMS, Astro will feel restrictive.
- Nobody will own the site after launch. An Astro codebase needs someone to update dependencies, publish changes and fix problems: an in-house developer, a retained agency or a maintenance plan.
- Everything is changing at once. A new domain, brand, navigation, URL structure and content in the same launch make any ranking drop hard to diagnose. Move the platform first, or stage the changes.
- There’s no URL inventory and no time to build one. Without a crawl, sitemaps and Search Console data, you are guessing which URLs matter.
Not sure which side you’re on? The migration assessment says so plainly: when Astro isn’t a good fit, it recommends improving WordPress first and suggests the better next step.
Your Next Step
Fill in the worksheet, or let the assessment do the counting. When you’re ready, send us your current URL and the pages that bring in enquiries. We reply within 24 hours, and we confirm the scope and the price after reviewing your site.
Frequently asked questions
How much does a WordPress to Astro migration cost?
Web Aloha publishes three migration packages: Simple Migration at $999 for up to 5 pages without a blog, Business Migration at $1,499 for up to 15 pages and 20 blog posts, and Complete Migration at $2,499 for unlimited pages and posts with a full content rewrite. Live stores, memberships, bookings that run inside WordPress, extra languages and critical integrations are quoted separately. The final quote follows a review of your site.
What is the difference between a page and a template in a migration quote?
A page is a URL with its own content, such as your About page or one blog post. A template is a layout that pages share, such as the blog post layout. Forty posts that share one template are mostly content conversion, while ten pages that each have a unique page-builder layout are ten pieces of design and component work. Count both before you ask for a quote.
How do you check that nothing was lost after a WordPress to Astro migration?
Crawl the old site before the move, then crawl the new site on staging and again after launch, and compare them URL by URL: status codes and redirect targets, titles, meta descriptions, canonicals, H1s, structured data, images and internal links. Test every form and analytics event, submit the new sitemap, and watch Search Console by page and query in the first weeks. Rankings can't be guaranteed, but these checks catch avoidable losses before visitors and search engines do.
How do I edit my website after migrating from WordPress to Astro?
There are four common routes: Markdown or MDX files in Git, a Git-based CMS that adds a web editor on top of those files, a hosted headless CMS such as Sanity or Contentful, or WordPress kept as a private headless CMS. They trade cost, convenience and maintenance differently, so choose by who publishes and how often. If the site rarely changes, a maintenance plan can cover the updates instead.
When should I stay on WordPress instead of migrating to Astro?
Stay on WordPress when the site is healthy and has no measured problem, when it behaves like an application (memberships, communities or a complex WooCommerce store), when editors need page-builder freedom and won't accept a structured or headless workflow, or when nobody will own the code after launch. In those cases speed work or a care plan usually gives a better return than a rebuild.
