Migration
Shopify migration, run as a method rather than a data dump
Most failed replatforms did not fail technically. They failed because nobody decided what the old data was supposed to become. We treat a migration as a mapping problem first and an engineering problem second, whichever platform you are leaving.
How we work
What makes a migration uneventful
A migration is the one project where success means customers notice nothing at all. Everything below exists to keep launch day quiet: the reconciliation, the dry runs, and a redirect map tested against real crawl data.
Dry runs before production
Every migration runs end to end at least twice into a staging store before anything touches production. We reconcile counts and spot-check records against the source system, so the go-live load repeats something that has already worked.
Redirects tested against real crawl data
We check the map against what search engines and your analytics say is actually being requested, rather than against a sitemap. That is how orphaned but still ranking URLs get found before they turn into 404s and cost you traffic you did not know you had.
One team through cutover
The people who mapped your data are online during the switch and watching the numbers the week after. Nobody hands you over to a support queue at the moment it matters most.
A scope you can hold us to
Fixed scope, staged releases and a named date. Open-ended migrations tend to turn into rebuilds, and a rebuild needs its own budget and its own conversation. We would rather raise that at the start than halfway through.
AI, and where it stops
Where we let AI accelerate, and where a human signs off
AI is genuinely good at the tedious middle of a migration. It proposes field mappings across thousands of attributes, drafts redirect rules, and finds the records that break the pattern. It is not good at deciding what your business means by a customer group. So we use it for throughput and keep the judgement calls human.
Inventory, largely automated
We extract the full shape of the old store, every attribute, template, price rule, URL and integration, and let tooling classify it. A person then reads the result, because an inventory nobody has read does not tell you anything yet.
AI-proposed mapping, human-decided
AI drafts the field by field mapping to Shopify and flags what it is unsure about. Every proposal gets reviewed before it is accepted. The ambiguous ones, meaning pricing logic, customer groups and anything with money or tax in it, are decided with you rather than inferred.
Build, load, reconcile
The storefront gets built while the data pipeline is written, then both meet in staging. We reconcile totals against the source system and investigate every discrepancy, because a migration that is only roughly right shows up later as support tickets.
Staged cutover and aftercare
DNS moves in your quietest window with the old store still reachable behind it. Then daily monitoring of Search Console, logs and revenue while search engines re-crawl, and a fix loop that stays open until the numbers have settled.
Migrated to Shopify
Stores we have moved, and what they moved from
Magento, WooCommerce, Shopware, Craft Commerce and hand-built systems. The source platform changes what the mapping looks like. The method behind it stays the same.
Migration FAQ
What people ask before committing
The questions that come up whichever platform you are migrating from.
Thinking about it?
Start with a scoping call.
The catalog is rarely the driver. Cost tracks the number of decisions involved: how much custom logic exists, how many integrations have to keep working, and whether the design is being rebuilt at the same time. We scope it before quoting, and that scope is what we hold ourselves to.
None that a customer sees. The new store is live and tested on a staging domain before cutover, and the switch itself is a DNS change with the old store still reachable behind it. We plan the riskiest hour for your quietest traffic window.
For mapping proposals and pattern detection, yes, and on large catalogs it saves weeks. Nothing gets accepted because a model suggested it. A person reviews every mapping, and anything touching pricing, tax or customer identity is decided with you explicitly.
Sometimes, though the trade is worth stating plainly. Doing both at once costs less than doing them one after the other, but it removes your ability to tell whether a change in the numbers came from the platform or the design. If the current design converts, we usually migrate first and redesign after.
They get inventoried in week one, because they are the most common reason a migration slips. Some have Shopify apps, some need a middleware layer, and occasionally one needs rebuilding. We would rather find that in the audit than in the second month.
Admin access to the current platform, someone who can answer questions about how the business actually works, and a decision-maker for the ambiguous mappings. Roughly a few hours a week. Most of the load sits with us.
By platform
Migrating from a specific platform
The mapping problems are different for each one. These pages go into the detail.
Martin Winkler
Co-Founder & CEO
Mark Chang
Founder & CTO