The replatform nobody calls a replatform
What you hand over, what you get back, and the honest version of a conversation usually had in feature grids.
Third one of these in 18 months: a store that ran on a server we controlled, moving to a platform somebody else runs.
It gets framed as an infrastructure project. Same products, same customers, same brand, we’re just changing where it’s hosted. Nobody says “replatform” because the word sounds expensive and the site is going to look broadly the same at the end.
It is a replatform. I wrote a post about this five years ago from the other direction, a client asking for a look and feel and getting a CMS migration, and this is the same trap with the labels swapped. Then, the visible thing was small and the invisible thing was enormous. Here, the invisible thing is the one being described as small.
What you actually hand over
The trade is not “our server” for “their server.” It’s a specific list, and it’s worth naming because the list is the whole decision.
The checkout. This is the big one and it is nearly always discovered late. On the old stack, checkout was a set of templates like any other, and if the client wanted a field on step two, that was an afternoon. On the new one, checkout is the platform’s, it’s where their liability lives, and what you can change is a set of options and some styling. Any sentence beginning “at checkout we need to” now has to be finished by somebody else’s roadmap.
For most stores this costs nothing, because most stores didn’t need anything there and had a bespoke checkout only because bespoke was the default. For the ones that do, trade pricing, purchase orders, split shipments, an approval step, it’s disqualifying, and finding that out in month three is the most expensive way to find it out.
The database. No more “I’ll just write a query to work out what happened.” Everything comes through an API, which is rate-limited, shaped the way they shaped it, and doesn’t have the table you wanted. Reporting that used to be SQL is now either an app you pay for or a small service you maintain.
Cron. Anything that used to run at 2 am on the box runs somewhere else now, or becomes a webhook, or becomes an app. This is usually the thing nobody has inventoried, and there are always more of them than anybody remembers.
The version. You no longer choose when things change. On the old stack the site could sit on a version from 2018 for years, which is a real risk and also a real form of control. Now the floor moves under you on their schedule, mostly in small ways, occasionally not.
You're not choosing between two hosting arrangements. You're choosing which set of problems you're permitted to solve yourself, and which you have to wait for.
What you get back
I’d be describing this dishonestly if I only listed costs, because the returns are large and they land on people who never appear in the technical conversation.
Nobody is awake at 3 am. Not you, not the client, not a retainer that quietly assumes somebody will be. Patching, certificates, scaling for the day a product goes viral, PCI scope, all of it stops being a thing anybody at either company thinks about.
Upgrades stop being projects. On the old stack, a major version was a quoted piece of work with a risk profile, which is why so many stores are three versions behind: the upgrade keeps losing to the roadmap, and losing is free until it suddenly isn’t.
And the failure mode changes shape. Self-hosted, a bad day is your bad day, and the client is on the phone to you. Hosted, a bad day is everybody’s bad day, there’s a status page, and, this is not nothing, it is visibly not your fault.
The three questions that actually decide it
I’ve stopped opening with platform comparisons. These get to the answer faster.
Does anything unusual have to happen at checkout? If yes, and it’s genuinely required rather than inherited, that mostly settles it.
Who will maintain this in three years, and are they employed here? A client with two developers can own a self-hosted stack. A client with a marketing manager and a retainer cannot, no matter what anybody says at kickoff, and pretending otherwise is how a store ends up on an unsupported version with nobody to call.
What’s the annual cost of the boring work nobody’s costing? Patching, hosting, the upgrade every 18 months, the hour a month somebody spends on certificates. Nobody adds this up, and once it’s added up the platform fee usually stops looking like an increase.
The part I find awkward
Every one of these I’ve done has been the right call for the business and has reduced the amount of interesting work available to me.
I’m aware that’s a factor and I’d rather say so than pretend to a neutrality I don’t have. There’s less to build. The problems that remain are more about arranging things somebody else made than about making them, and I’ve noticed a version of myself that argues for the self-hosted option using words like “flexibility” when what I mean is that it’s more fun.
The corrective is the three questions, which don’t care what I find fun, and the observation that a client whose store is quietly fine for four years is a better outcome than a client with an interesting stack and a support ticket.
Why to say the word out loud
The reason to use “replatform” early, even though it makes the number bigger and the conversation harder, is that everything above happens whether or not anybody named it. Naming it gets you the inventory in week one instead of the discovery in month three.
I’ve never regretted saying it. I’ve twice regretted not saying it, both times in about week nine 😬