Should you replatform at all?
Only replatform when the platform itself is the ceiling: when the limit you keep hitting is built into the software, not into how it was implemented. That distinction decides everything, because a replatform is the most expensive and most dangerous way to fix a website, and a surprising share of 'we need a new platform' briefs are really 'our current build is bad' briefs wearing a bigger budget.
The two failure modes look similar from the boardroom. A slow, brittle site on a fundamentally capable platform needs renovation: rebuilt templates, performance optimisation, the plugin sprawl cut back, the technical debt paid down. That work is cheaper, faster and carries almost none of a migration's risk. If the site got that way because a previous supplier left it in a state, that is a rescue job, a discipline of its own covered by our fix and rescue practice, not a reason to change platforms.
A genuine platform ceiling feels different. Every merchandising change queues behind a developer. Licence and extension costs climb while capability doesn't. The integration your operation now depends on cannot be built, or the vendor has announced end-of-life, or security patches have stopped. When the constraint survives good implementation, when even a well-built version of your site could not do what the business needs, the platform is the problem, and a move is worth pricing.
Renovate when the implementation is the problem
The site is slow, fragile or ugly, but the platform demonstrably supports what you need: other businesses do it on the same software. Rebuilding on the platform you have keeps your data, URLs, integrations and team knowledge exactly where they are; a competent web development team can usually prove the ceiling is implementation, not platform, within days.
Replatform when the software is the problem
The capability gap survives good implementation: features the vendor will never ship, costs that scale against you, an architecture your integrations have outgrown, or a platform that is sunsetting. Here renovation is money spent decorating a building you are about to leave. The honest move is to plan the move.
Get the verdict before the budget
Ask whoever scopes the project to argue against the migration first. A supplier who profits from the bigger project and still tells you the platform is fine is showing you how they will behave for the rest of the engagement. It's the cheapest integrity test in the industry.
What can you actually lose? The risk inventory
Four kinds of asset are at risk in every replatform: your data, your search equity, your integrations and your team's working knowledge. Write the inventory of all four before choosing a destination, not after, because what you stand to lose shapes which platforms are even viable, and because a loss you never counted is a loss you will never detect.
The inventory is not bureaucracy; it is the mechanism that makes 'zero data loss' a checkable claim instead of a hope. If you know exactly what existed at the start (how many products, orders, customers, pages, media files, URLs, API connections and scheduled jobs), then after the move you can reconcile the destination against the count, record for record. Without the count, 'nothing went missing' just means 'nobody has noticed yet'.
Data: the obvious asset, counted properly
Products and variants, orders, customer accounts, content, reviews, media, discount logic, historical analytics. The subtle danger is relational: an order that arrives without its customer, a product stripped of its category history. Count entities and their relationships, and agree before the move which records, if any, are deliberately being left behind.
Search equity: the asset that leaves silently
Every URL that ever earned a link, a ranking or a bookmark is an asset with an address. Change the address without a one-to-one redirect and the equity does not transfer. It evaporates, and the traffic graph tells you weeks later. Ranking preservation through a migration is a specialism of its own; our technical SEO service exists in large part because of moves that skipped it.
Integrations: the plumbing nobody documented
Payment gateways, shipping and tax engines, ERP and inventory syncs, email and CRM connections, analytics, feeds, webhooks, cron jobs. These fail loudly on cutover night if they were never inventoried. The classic migration disaster is not lost data but an order flow silently disconnected from fulfilment.
Team workflows: the human muscle memory
Your team's speed on the current admin is an asset the project plan rarely prices: publishing routines, reporting habits, the workarounds that keep operations moving. Budget real retraining time and expect a productivity dip in the first weeks on the new platform. Pretending otherwise just moves the cost somewhere it can't be managed.
Which platform should you move to?
Choose the destination by answering three questions in order: how do you sell, who will maintain the site, and what must it integrate with? Platform marketing answers none of these: every vendor's homepage promises everything. So the decision framework has to start from your operation rather than from feature lists.
How you sell narrows the field fastest. A catalogue-led store with conventional checkout flows suits a commerce platform; a content-led business publishing daily has different needs entirely; a brand whose storefront must appear in apps, marketplaces and kiosks at once is describing an API-first architecture. Who maintains it narrows it further: a platform your team cannot operate without an agency on retainer is a dependency, not a capability. And the integration list from your risk inventory is the hard filter: a platform that cannot talk to your ERP is disqualified no matter how good the demo looked.
The four destinations, honestly compared
| Route | Strongest fit | The trade-off to plan for |
|---|---|---|
| Custom build | Products or workflows no packaged platform models well; software that is itself the business. | You own the roadmap, and the maintenance. Budget for engineering as an ongoing capability, not a one-off project. |
| Shopify | Catalogue-led D2C and retail that wants hosting, checkout, and PCI burden handled by the platform. | Convention over configuration: deep customisation happens within Shopify's model, and platform fees scale with you. |
| WooCommerce | Content-plus-commerce on WordPress, full data ownership, and licence economics you control. | You inherit the hosting, performance and update discipline the platform would otherwise carry for you. |
| Headless commerce | Multi-storefront brands and teams that need frontend freedom over an API-first backend. | Two systems to run instead of one. The flexibility is real; so is the engineering maturity it assumes. |
Two honest notes on the shortlist. First, if your ceiling is content rather than commerce, the same framework applies with different candidates: a publishing operation outgrowing its CMS is usually choosing between modern WordPress development done properly and a headless content stack, not between shop platforms. Second, commerce estates rarely fit one label cleanly; our eCommerce development practice spends as much time keeping clients off the wrong platform as building on the right one, because the most expensive migration is the one you have to redo.
How does a migration run without losing anything?
A disciplined migration runs in a fixed sequence: inventory, redirect map, build, rehearsal, cutover, rollback armed. It refuses to skip steps under deadline pressure. 'Zero data loss' is not a promise of luck; it is a verification standard: nothing on the old platform is switched off until its replacement is verified against the inventory, and if a reconciliation check fails, the cutover stops until it passes. That is the entire mechanism. Everything below is that principle applied in order.
1 · Inventory before movement
The counts from your risk inventory become the migration's contract: every entity, URL, integration and scheduled job documented before the first byte is copied. Reconciliation at the destination happens against this document, record for record. Loss becomes detectable before it becomes permanent.
2 · The redirect map as a deliverable
Every URL that ever earned equity gets a mapped, one-to-one destination before cutover, not a blanket rule to the homepage after it. The map is drafted from the URL inventory, reviewed, tested on staging and monitored after launch. It is a document someone signs off, not a setting someone toggles.
3 · A rehearsed cutover, not a brave one
The full move is rehearsed on staging first: data copied, redirects live, integrations reconnected, test orders placed, edge cases walked. The rehearsal's output is the runbook: who does what, in what order, with what checks. So the real cutover is the boring second performance of a show that already went well.
4 · A cutover window agreed in writing
Content freeze, final data sync, DNS switch, verification checks, scheduled for your quietest hours and agreed with everyone whose work stops during the freeze. For most sites visitors notice nothing; where live transactions are involved, a short honest maintenance window beats an optimistic no-downtime promise that gets improvised on the night.
5 · Rollback armed, hopefully unused
Before the switch, agree in writing what would trigger a reversal and exactly how it works: the old platform held warm, DNS ready for a fast return, a plan for data captured in between. Most rollback plans are never used, but a migration without one is a bet placed with your revenue.
This sequence is how our own migration engagements run, and it is not theoretical. In our published commerce case, a Gulf D2C fragrance retailer's full catalogue, order history and customer records moved with zero data loss, every historic URL carried a mapped redirect. With search equity intact, the rebuilt store went on to 340% revenue growth in 7 months. Read how the move was sequenced; the discipline above is the part that made the growth possible.
What do you watch after launch?
The migration ends when the graphs settle against the pre-move baseline, not when the new platform serves its first page. Capture that baseline before cutover (traffic, rankings, conversion rate, revenue, error rates, page speed), because after launch it is the only honest way to distinguish 'the move broke something' from 'sales are always slow on Tuesdays'.
The first week is about errors: 404 logs read daily against the redirect map, server errors and response times watched, every payment method and integration exercised with real transactions. The first month is about search: crawl behaviour and indexation of the new URLs, redirect chains caught and flattened, rankings tracked with honest expectations: some volatility in the weeks after a well-run move is normal, and anyone promising none is selling something. Sustained decline beyond that window is a defect to diagnose, and the redirect map is the first place to look; ongoing SEO monitoring exists precisely to catch it early.
Two closing disciplines. Watch conversion separately from traffic: a move that holds visitors but leaks checkouts has a UX or performance regression the traffic graph will never show you. And decommission last. The old platform is your rollback insurance and your reconciliation reference, so it goes dark only when the graphs have settled, the punch list is clear, and nothing still depends on it. Turning it off early to save a month's hosting is the cheapest way to make a small problem unrecoverable.