Live on Shopify Horizon in four weeks. Fixed price. Nothing you have today stops working.
A complete migration — documented, built, tested, and handed over — with the price and the date agreed before anyone writes a line of code.
We don’t quote a migration we haven’t looked at. The audit is $2,500, comes off this price, and does the documentation work that would otherwise eat your first two weeks.
Not a new theme. A different operating model.
The point of this isn’t that your storefront looks different afterward. It’s that changing it stops being a development project.
Campaigns, landing pages, and merchandising changes go from idea to live storefront in a fraction of the time, because most of them stop requiring a developer.
Your engineers spend less of the week executing content and layout requests, and more of it on the work that actually needs them.
The storefront gets easier for your own team to run and evolve — without stacking another layer of custom code every time the business wants something changed.
That’s the outcome. The rest of this page is how we get there and what it costs.
Four things. We’re not going to pretend there are twenty.
Sections nest and get reused instead of being rebuilt every time. Content management stops being a rebuild exercise.
Describe the block you want in plain language and get working code. The request that used to become a ticket becomes a change.
Your team restructures pages directly rather than filing a request and waiting for a sprint.
Storefront capability is being built on this architecture. Shopify’s own reference theme shipped three releases in the last twelve months; Horizon shipped nineteen, and is on its fourth major version since launch. Here’s the release history, updated quarterly.
There are other differences. These are the four that hold up under scrutiny, and we’d rather give you four you can check than twenty you can’t.
What happens, and when we need you.
The audit already documented what your store does. This is the working session where you correct anything we got wrong, add the business rules that only live in your team’s heads, and approve the final specification. One to two days, and it’s the only phase that needs real time from your team.
Your Horizon theme, built against the approved specification. Reviewed by a solutions engineer. Handed to your GitHub.
A sandbox environment for your team to test in, plus before-and-after reports on speed, SEO, and accessibility.
We publish. Then a 90-minute session with your team on everything the new storefront lets them do without you.
A 30-minute session once they’ve actually used it and have real questions.
Anything that worked before and doesn’t now, we fix free. More on that below.
This is why the audit comes first. Most agencies spend the first two weeks of a migration working out what your store does. We’ve already done that — so week one is a review, not an investigation, and the four weeks are four weeks of building.
We don’t ask you to remember what you built. We read it.
The reasonable objection to any fixed-price migration is that nobody can capture four years of accumulated customization in a week — so the input is incomplete and the output is wrong.
That’s true if you do discovery by asking people what they remember. So we don’t.
Your theme is a file system, not a memory. Every section, block, setting, snippet, metafield reference, script tag, app embed, and translation key is enumerable, and we extract all of it. You don’t get asked what you built. You get handed a list of what you built, and your job is to correct it rather than write it.
We record how your store actually behaves before we touch anything — real templates, real states, real breakpoints. Acceptance for the new build is a comparison against that recording.
Which means: if it worked on your old store and it doesn’t work on the new one, the comparison catches it — whether or not anybody wrote it down.
The document isn’t the safety net. The diff is.
And your old theme doesn’t go anywhere. It stays in your library, unpublished and unmodified, permanently. Rollback is one click.
Four, in writing. Here’s why each one is possible.
We don’t go live until the new build meets or beats your current Core Web Vitals. If we can’t get there, you don’t pay the final milestone.
Worth being precise about why this is a guarantee rather than a theme claim: on a store that’s been customized for years, speed is driven far more by accumulated apps, scripts, tags, and image weight than by which theme it runs on. Nobody can promise you a number based on a theme. What we can do is measure your store before we start, agree that baseline, and commit to beating it — because a rebuild is the one moment you get to leave the accumulated weight behind.
Fixed timeline, with a credit if we miss it. Sign-off happens in the first day or two, because the audit did the documentation work before either of us signed anything.
Or we fix it, free. Possible because every requirement has a written acceptance criterion — not “the cart drawer works” but the specific, testable version of that.
Anything that existed and worked on your previous theme and doesn’t work on the new one, we build — free, and whether or not it appears in the requirements document. This is the one that matters. It moves the risk of a miss from you to us, which is where it belongs.
Published, so you can compare.
| Readiness Audit | Horizon Sprint | Horizon Sprint — Complex | |
|---|---|---|---|
| Price | $2,500 | $40,000 | $75,000+ |
| Timeline | 5 business days | 4 weeks | 6–8 weeks |
| For | Any store on a pre-Horizon theme | One store, one market | Multistore and/or multimarket |
| Credit | Comes off the Sprint if booked within 30 days | — | — |
First, the comparison that isn’t one.
You can get a Shopify theme customized for $5,000–$15,000. That’s a real service and sometimes it’s the right one. It is not this.
This is a migration: your existing functionality documented, rebuilt on a different architecture, tested against a recording of how your store actually behaved, and guaranteed. Different work, different risk, different number.
Second, where $40,000 actually sits.
Published US agency ranges put mid-market Shopify migrations at $15,000–$75,000, moderately complex ones at $45,000–$75,000, and custom Plus replatforms at $75,000–$250,000+.
Against that, $40,000 is at the floor of the band — with four guarantees attached. Here’s the full pricing breakdown and where those figures come from.
Third, the thing that actually matters.
| A typical migration quote | A Horizon Sprint | |
|---|---|---|
| Scope | Discovered during the build | Documented and signed before it |
| Price | An estimate, revised | A fixed price |
| Timeline | “Roughly eight to twelve weeks” | Four weeks, guaranteed |
| Compatibility | Breakage found at launch | Mapped before you sign |
| Changes | Change orders | Change control, with a freeze date |
| Risk | You carry it | We do |
You can probably find a lower number. What’s harder to find is a number that doesn’t move.
What’s in, what’s extra, and what we don’t do.
Included
Available as add-ons, priced separately once the audit tells us whether you need them
- Third-party search engine implementation (Algolia and similar)
- Third-party CMS implementation (Contentful and similar)
- Third-party app version upgrades (Recharge Affinity and similar)
- Analytics and tagging migration — GTM, server-side, consent
- Data services — analytics engineering, data pipelines, and agentic data setup, support and audit
- Integration and tech stack audit — including business systems integration across ERP, PIM, OMS, CRM and finance
- Managed services — ongoing operation and evolution of your storefront after launch
Not something we do as part of this: CRO-led redesign, and data warehouse work.
One clarification on tagging, because it’s the thing people assume: everything currently firing will still fire. That’s included and guaranteed. Re-architecting your tagging is the paid add-on.
This is probably you if:
Not sure yet? Work through the decision framework first. It includes the cases where the answer is no.
Who we’ve built for.
Anatta has built and run Shopify storefronts for:
Before / after data from a completed Horizon migration lands here.
Before / after data from a completed Horizon migration lands here.
Before / after data from a completed Horizon migration lands here.
Questions about the migration.
Does our store go down?
No. The entire build happens on an unpublished duplicate theme. Your live store is untouched until you approve the new one and we publish — which is a single action, at a time you pick.
Can we see it before it goes live?
Yes. You get a sandbox environment in week three and your team tests in it before anything is published.
What happens to our current theme?
It stays in your theme library, unpublished and unmodified, permanently. We don’t delete it and we don’t edit it.
Will our apps still work?
Most will. Some need reconfiguration on the new architecture, and a few need a vendor update or a rebuild. The audit maps every app in your stack before you sign, so you know which is which and what it costs — rather than finding out in week three.
What about our SEO?
URL structure is preserved, your existing redirects carry over, and structured data is rebuilt to match what you emit today. You get a before-and-after SEO report at handover.
What about our tracking and tags?
Everything currently firing still fires. We verify it event by event against the recording we made before starting, rather than eyeballing it in preview.
Won’t Shopify’s theme updates overwrite our customizations?
Not the way we build. We never edit core theme files — all custom work lives in separate blocks and sections, so an update can’t overwrite it. This is the most common complaint about Horizon and it’s a consequence of how a theme is built, not the theme itself.
Who does the work?
An architect owns requirements and the build standard, a solutions engineer reviews the finished theme. The same people through the whole engagement.
How much of our team’s time does it take?
A day or two at the start for the requirements sign-off session, then sandbox testing in week three and the training session in week four. The build itself costs you almost nothing — it happens on a duplicate theme while your team gets on with the quarter.
Do we have to do the audit first?
Yes. We won’t quote a fixed price on a store we haven’t examined — that’s how fixed prices turn into change orders. It’s $2,500, it comes off the Sprint, and if it tells you not to migrate, you’ve saved considerably more than that.
What if we need changes after launch?
For thirty days, anything that worked before and doesn’t now is free. New functionality that never existed is new work, and we’ll quote it.
What if we’re mid-redesign?
Then this is the right moment rather than the wrong one. You’re rebuilding anyway — the only question is which architecture you rebuild onto, and that’s cheaper to decide now than to revisit in a year.
We won’t quote this until we’ve looked at your store.
Every fixed-price migration that turns into a fight does so for the same reason: somebody priced a store they hadn’t examined, found the surprises in week three, and sent a change order.
The audit exists so that doesn’t happen. Five days, $2,500, and it produces the scope this entire page is priced against. It’s also the reason we can offer the guarantees — you can’t underwrite a promise about a store you haven’t measured.
If it turns out you shouldn’t migrate, the audit will say so, and that’s a good outcome for both of us.
Four weeks. A price that doesn’t move. Everything still works.
Start where every Sprint starts.
Credited in full against your Sprint if you book within 30 days.
Want to talk it through first? Speak to an architect →
