WordPress to Astro or Next.js
Move off WordPress, onto code you own
Plugins to update, a server to patch, and pages that need a caching stack to feel fast. I move the marketing site to code you own, with editing your team can use. Membership, checkout and other application features get their own plan before a move makes sense.
Fixed price from $5,000 typically 4–6 weeks 30 days of hypercare code in your name
The Everbase Stack
Astro or Next.js, with Sanity, on Cloudflare or Vercel.
What moves
What actually migrates.
| What you have | What happens | Why |
|---|---|---|
| Posts and pages | Move Comes across as it is. The content survives the move and the work is transporting it, not remaking it. | Exported from the database rather than scraped, converted to Markdown or loaded into whichever CMS the new site reads, and checked by count against the old admin. |
| Custom post types and fields | Rebuild Made again in the new codebase. The old version is a reference, not an import. | A post type is a shape somebody defined in PHP or in a plugin's UI. There is nothing waiting to receive it, so the model gets designed before the content can move. |
| Media library | Move Comes across as it is. The content survives the move and the work is transporting it, not remaking it. | Files come across and every reference to them gets re-pointed, including the ones living inside post bodies rather than in a field. |
| Plugin behavior | Rebuild Made again in the new codebase. The old version is a reference, not an import. | Forms, redirects, SEO fields, galleries and popups were each a plugin. Each one becomes a deliberate decision: rebuild it, replace it with a service, or drop it because nobody has used it since 2022. |
| URLs | Reconfigure The same thing, set up again. Nothing is recreated, but it has to be pointed at the new site by hand. | Permalinks stay. So do the archives, the pagination and whatever structure preceded the current one, which is usually larger than the site itself. |
Mapping
Nothing here is a file move.
- An SEO plugin Metadata in the content model Titles, descriptions and canonicals become fields on the entry rather than rows in a table a plugin owns, which is also how they survive the plugin being uninstalled.
- A form plugin A form endpoint A service that receives submissions, or a function of your own. Either way the test is a record arriving at the destination, not a success message in a browser.
- A caching plugin, a CDN and an optimizer Nothing All three existed to undo the cost of rendering per request. A page built before anybody asks has nothing for them to undo.
- A custom post type A typed collection The shape somebody defined in PHP becomes a schema the build checks, so a missing field fails the build instead of rendering an empty page for a month.
- A feature nobody has used since 2022 Retired The plugin audit is the migration. Every entry on the list is kept, replaced or dropped, in writing, before anything is built.
Hard parts
Where this migration gets complicated.
- 01
The URL footprint is usually larger than the visible site
Category archives, tag archives, author pages, date archives, pagination and whatever permalink structure preceded the current one are all live addresses that nothing in the navigation points at. The redirect map for that footprint is usually far larger than the site looks from its navigation.
- 02
Page builder output is not content
Elementor, Divi and WPBakery store layout inside the post body as shortcodes and serialized markup. The export contains it, so the text has to be extracted from the layout rather than imported with it, and that is manual on every page a builder touched.
Process
How the migration works.
-
Audit
Every post type, plugin and live address, written down while the old site is still serving them.
-
Rebuild
Templates become components, the theme's inheritance is flattened, and the custom fields get a typed model.
-
Migrate
Posts, pages, media and metadata moved and verified by count, with permalinks and archives mapped.
-
Hand over
The repository, the migration map and documentation written for somebody who was not here.
Included
What is included.
-
Design rebuild
Rebuilt as components, not approximated.
-
Responsive development
Desktop, tablet and mobile, built and checked.
-
CMS architecture
Collections and fields mapped before build.
-
Content migration
Migrated and checked against the source.
-
Asset migration
Collected, compressed and rehosted.
-
Forms and integrations
Tested through to the final record.
-
URL coverage
Every known public address preserved or deliberately redirected.
-
Metadata and canonicals
Preserved wherever possible.
-
Search footprint preservation
URLs inventoried before and checked after.
-
Pre-launch QA
Forms, templates and old URLs verified.
-
Post-launch support
30 days of indexing and traffic checks included.
After those 30 days, Continuous development is the optional way to keep shipping: $1,000 a month for the Everbase Agent, or $3,500 a month for the Partner Program (human QA on every deploy and one active request at a time), pause or cancel any month.
Search visibility can move during a migration. The goal is to preserve what search engines already understand, and to catch what changed quickly after launch.
And it is yours at the end. The repository sits in your organization rather than mine, the handoff documentation is written for somebody who was not here, and nothing about the project requires me: another developer or your own team can operate it.
Editing
Leaving WordPress does not have to mean handing every edit to a developer.
-
01
Content Collections, in the repository
For a team that publishes rarely and is happy in a pull request. The content is files beside the code, typed and checked at build time, with no service to pay for and nothing to keep running. It stops suiting you the day somebody outside engineering needs to publish without help.
-
02
Sanity
For a team that publishes regularly, or where the person writing is not the person deploying. Editors get a real interface, the model is explicit, and the site reads it at build time. It is another system to configure and pay for, and the modeling is the part that decides whether editors can work on their own.
-
03
No CMS at all
For a site whose pages change a few times a year. Everything lives in components, changes go through the same review as any other change, and there is no editorial layer to maintain. Honest for a small site, and the wrong answer the moment a blog is added.
Content Collections against a headless CMS, and how the choice is made.
Proof
A migration is not finished when the new site looks right.
-
01 Codebase
A codebase your team owns
Components, routes and styles rebuilt deliberately, not cleaned up from exported markup.
Verified by Repository and component structure
-
02 Site
Everything accounted for
Collections, content, metadata and existing addresses checked against the source.
Verified by Source inventory and migration checks
-
03 Systems
Handoffs that actually arrive
Forms, analytics and CRM checked at their destination rather than at the button.
Verified by Submissions, events and records
The migration is complete when these pass, not when the homepage looks right.
The figures above show the report's shape. Yours are counted from your own site.
Maintenance
Built for people and agents to work on.
The important part is not that an agent can write code. It is that the project is structured well enough for its changes to be understood, reviewed and reversed.
-
Marketing
Editor or AI assistant CMS Preview Publish
On the headless CMS answer above. Choose content collections instead and this lane runs through the repository and the review with the developers, which is exactly why that decision comes before the rebuild rather than after it.
-
Developers
Branch Components and routes Review Deploy
The same workflow as any other repository, which is what makes a second developer able to pick it up.
-
Coding agents
Project instructions Branch Review Deploy
Coding agents use the same repository and review process as developers. Instructions explain the patterns; tests and a human review check the changes before release.
Integrations
Changing the frontend doesn't mean changing your stack.
-
HubSpot
Forms that land in the CRM as records, confirmed by the server rather than by the browser.
CRM
-
Sanity
A content model the marketing team edits and the build renders, with a defined preview and publishing path.
CMS
-
Google Analytics
Traffic and conversions measured against the routes the site actually has.
Analytics
-
Stripe
Checkout handled by Stripe, with the webhook as the record that decides what happened.
Payments
-
Mailchimp
Signups that reach the audience exactly once, whatever the visitor clicks.
Email
-
Zapier
Site events handed to the automations the team has already built.
Automation
Other guides
Coming from somewhere else?
Let me plan your next step.
I can scope a migration. Send a brief and I will reply by email with next steps.