Shopify to Astro or Next.js
Keep the store. Own the marketing site.
Marketing waits on a developer to publish a landing page, and app scripts slow every page. I give campaign and marketing pages their own content and component system in Next.js or Astro while commerce stays in Shopify. If the existing theme already meets the team's needs, staying may be the better answer.
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 |
|---|---|---|
| Products, variants and inventory | Stays put Does not move, on purpose. The old platform keeps this because it is the thing it is good at, and the new front end reads from it. | Shopify remains the source of truth for anything with a price, a variant or a stock level. The Astro front end reads that data from Shopify rather than holding a second copy that can drift. |
| Commerce backend and checkout | Stays put Does not move, on purpose. The old platform keeps this because it is the thing it is good at, and the new front end reads from it. | Astro can own the storefront experience; completing the transaction hands off to Shopify Checkout. Payments, orders, tax and fraud stay where they already work, which is the whole design of the project. |
| Blog and marketing content | Move Comes across as it is. The content survives the move and the work is transporting it, not remaking it. | The content moves into whichever publishing system the new front end uses. The theme templates do not come with it: how it looks is rebuilt as components. |
| Theme sections and templates | Rebuild Made again in the new codebase. The old version is a reference, not an import. | Liquid sections become Astro components, and the section schema becomes a content model marketing can actually use. |
| Storefront apps | Reconfigure The same thing, set up again. Nothing is recreated, but it has to be pointed at the new site by hand. | Each one is identified by what it does before anything moves. Reviews, loyalty, chat and recommendations are then implemented deliberately on the surfaces that use them. |
| URLs | Reconfigure The same thing, set up again. Nothing is recreated, but it has to be pointed at the new site by hand. | Existing addresses are inventoried before the rebuild. Product and collection addresses stay connected to the commerce architecture, and marketing addresses are preserved wherever practical and explicitly redirected where the routing changes on purpose. |
Scope
Two scopes, and they are not the same project.
Two ways to draw the line
Marketing pages only
- Astro owns the pages that explain the product.
- Product, collection and cart pages stay in the Shopify theme.
- The two are linked, and nothing reads the Storefront API.
- Nothing that takes money is touched at any point.
A few weeks, and the right answer more often than people expect.
Astro storefront, Shopify commerce
- Astro owns the product and collection pages too.
- Product data, stock and prices read from Shopify at build or per request.
- Cart state surfaces in the Astro front end.
- Checkout still hands off to Shopify, which is not negotiable.
A storefront rebuild, and priced as one.
Hard parts
Where this migration gets complicated.
- 01
Deciding the boundary is the project
Everything else follows from where the line goes between the site that explains the product and the store that sells it. Draw it badly and you have rebuilt a checkout for no reason, or split one product page across two systems that disagree about the price.
- 02
Product data is live, not exported
Prices, stock and variants change while the site is being built, so they are read at request or rebuild time rather than copied. That is a caching decision with a business consequence: how stale a price may be before somebody is upset is a question for the merchant, not the developer.
Process
How the migration works.
-
Audit
The boundary first: which pages move, which stay, and what the front end reads from Shopify.
-
Rebuild
Liquid sections become components, the section schema becomes a content model, and the Shopify connection is cached deliberately.
-
Migrate
Marketing content into the new CMS, product data connected rather than copied, checkout tested against the live store.
-
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
Decide where each kind of content belongs.
-
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.