The replatform decision, made with evidence

Start with the constraint, not the mood

Almost every replatform conversation we are brought into starts the same way: something feels wrong. The site feels slow, the theme feels dated, the last three campaigns felt harder to ship than they should have, the current agency feels unresponsive. All of that might be true, and none of it is a reason to migrate, because none of it names a thing the current platform cannot do.

The test that separates a real migration case from a mood is whether you can finish one sentence: "we cannot do X on our current platform, and X is worth $Y." Not "we would prefer to", not "it would be nicer if". Cannot, as in blocked. If the sentence does not finish, the conversation is not really about the platform, and it is worth finding out what it is actually about before a six-figure migration gets scoped to fix it.

This matters because the alternative diagnosis is usually cheaper and faster to fix. A slow site is very often an app problem, not a platform one. A theme that cannot support a new merchandising idea is a theme problem, fixable by extending it rather than replacing what it sits on. An unresponsive agency is a vendor problem with an obvious, non-destructive fix. Replatforming solves exactly one class of problem: a genuine, named limit in the platform itself.

Constraints that used to justify a migration, and do not any more

Some of the reasons merchants replatformed two or three years ago have since been addressed on the platform they were leaving, which makes them worth checking before anyone builds a business case on them.

The clearest example is the product variant limit. For years, a catalog that needed more than 100 variants on a single product (a large size and color matrix, a made-to-order configuration with many option combinations) was a documented, hard reason a specific class of merchant looked elsewhere. Shopify raised that limit to 2,048 variants per product for all merchants in October 2025, which removes the constraint for the great majority of catalogs that hit the old cap. A three-option limit and some throttling on very large catalogs still apply, so it is worth checking your specific numbers against the current limits rather than the old ones, but "we have too many variants for Shopify" is no longer true for most of the merchants who used to say it.

Checkout customization is the second example. Editing checkout.liquid directly used to be the only way to make anything beyond cosmetic changes to Shopify's checkout, which was a real constraint for merchants with specific checkout requirements. Shopify now provides a dedicated checkout and accounts editor built on UI extensions and Checkout Blocks, separate from the theme editor, for customizing branding, content and functionality on checkout, the thank-you page, the order status page and customer accounts. It is not identical to unrestricted code (some things that were possible in checkout.liquid are not possible the same way) so the sensible step is to check your specific requirement against what the current editor and available extensions support, rather than assuming the old ceiling is still there.

The pattern in both cases is the same: a specific, well-known constraint gets cited as the reason for a migration years after the platform vendor addressed it. Checking the current state of the constraint costs an afternoon. Scoping a migration around a constraint that no longer exists costs the whole project.

Constraints that still justify one

None of this means replatforming is never the right call. It means the bar is a named architectural limit, not a feeling, and the genuine cases tend to share a shape: something about how the business is structured does not fit the object model of the platform it is on, and no amount of app or theme work changes that.

A catalog and order model that genuinely needs to be split and governed as separate legal entities, currencies or tax jurisdictions in ways the current platform cannot represent is an architectural constraint. An integration pattern where the source-of-truth system needs a data relationship (a custom entity, a workflow state, a rule engine) that has no equivalent object on the current platform is an architectural constraint. A specific, checked requirement that neither the current checkout customization tools nor any available app can meet, after you have actually gone looking, is an architectural constraint.

What distinguishes these from the previous section is that they do not resolve by reading a changelog. Nobody is going to ship a feature that makes two separate legal entities sharing a catalog not a hard problem, because it is a genuinely different shape of business than the platform assumes. That is the test: would a plausible product update from the vendor make this constraint disappear? If yes, wait and check; if no, it is a real migration driver.

Price both sides, not just one

Once a constraint is confirmed real, the decision is a comparison, and both sides need a number attached, not just the side that is easy to measure.

The cost of migrating is the more visible one: the build, the cutover window and everything that has to be rehearsed before it, every integration rebuilt against a new platform, the redirect and SEO risk on the URL map, and the weeks of reduced velocity on everything else while the team is heads-down on the move. All of that is knowable in advance to within a reasonable range, and it should be priced before a decision is made, not discovered during the project.

The other side is the actual value of removing the constraint: the revenue a data model makes possible, the deals a missing capability is costing, the operational cost of a workaround the business has been living with. This side gets skipped constantly, because it takes more effort to quantify than "the migration will cost about this much." A constraint worth $40,000 a year does not justify a $250,000 migration with a six-month disruption. The same constraint attached to a $2m opportunity might. The number, not the discomfort, is what should decide it.

Run the theme-and-app diagnosis before anyone scopes a migration

Because a platform problem and an app or theme problem present identically to a frustrated merchandising team, the cheap step that should happen before any migration conversation is a proper audit of what is actually installed and running.

An app audit (what every installed app costs in performance, in maintenance, in overlapping functionality) resolves a surprising share of "the site feels slow and clunky" complaints on its own, at a fraction of a migration's cost and with none of its risk. A theme audit does the same for "we cannot build the pages we need." Only after both come back clean, and the actual limit is still standing, does a platform-level constraint deserve the conversation a migration requires.

What we would talk you out of

Replatforming to fix a slow site, before an app audit has ruled out the more common and much cheaper cause. Most performance complaints are app or theme problems wearing a platform costume.

Replatforming because a limit you read about two years ago is still assumed to apply. Check the current documentation for your specific number before it becomes a line item in a business case. The variant limit and checkout customization examples above are exactly the kind of assumption that goes stale.

Replatforming to solve a relationship problem with an agency or an internal team. Change the agency or the team; it is reversible and it is a fraction of the cost of a migration that was never really about the platform.

Scoping a migration before the value side of the equation has a number on it. A cost estimate for the move without an equally rigorous estimate of what the constraint is actually costing is half a business case, and it is always the easier half.

Questions this raises

Read next

• Shopify migration services
• The migration dry run: rehearsing a cutover
• The app audit: what every installed app costs you