Act I: The Trouble With Books About Replatforms
The Migration You Forgot To Plan
Marketing was at her desk on a Tuesday morning when she found the new button.
It was small. It said something like Generate with AI. She clicked it. She had a campaign brief on her desktop—three lines about a new olive-oil gift set, the launch date, the hero image. She fed those three lines into the box. Forty seconds later she had a complete page section: headline, subhead, image placement, a layout that did approximately what she had been about to file a ticket for.
She sat with it for a beat. She edited two words. She published it.
Across the office, the content team had found the same button about an hour earlier. They had been quietly excited about it. They had spent the morning prototyping landing pages for a holiday gift guide that wasn’t due for another month, the way you sometimes spend a morning at a job that has been frustrating for a long time when somebody hands you a tool that makes the frustrating part go away. By Tuesday afternoon, three new sections were live. By Wednesday, two more. By Friday, the homepage had five AI-generated sections on it that nobody at the agency had been told about.
Each section was about 80% right.
This is the worst possible percentage for a content section to be. Twenty percent wrong is wrong enough that you notice—the brand voice is almost right, the typography is close to the system, the image crop is nearly on the grid. But it isn’t wrong enough that anybody flagged it on the way out the door, because the people clicking publish were the people who, six months earlier, were not allowed near the homepage at all. They were thrilled. They had earned the right to be thrilled. Nobody had told them that earning the right to ship is not the same as having the system for shipping.
The performance dashboard noticed first.
The cleanup took the better part of three weeks. A handoff process was assembled, under pressure, after the damage was done—generate freely, finalize in review, ship through a gate that did not exist when the button was first clicked. The process worked. The process should have existed in week one. It existed in week six because that was the week it was needed.
We are telling this story with affection. These were not stupid people. The marketing team had not, in any meaningful sense, misbehaved. They had been given a tool. They had used the tool. The system around the tool—the rule that says what counts as a finished section and who decides and when—had not been built yet, because the building of that system had not been part of the migration project. The migration project had been about getting onto Shopify. The system that decided what shipped was somebody else’s problem, on somebody else’s timeline, in somebody else’s quarter.
This is the chapter where we tell you that those are the same problem.
Every enterprise brand that migrates to Shopify has been quietly running on years of operational muscle memory. They know how to manage a platform. They know how to ship. They have processes, approval chains, and engineering workflows that have been refined over the kind of long, painful institutional learning that produces—eventually—competence. None of this was a mistake. Magento and Salesforce Commerce Cloud rewarded exactly this kind of organizational discipline. Customization was how you stayed competitive. Central control was how you stayed stable. The operating model that grew up around those platforms wasn’t a misunderstanding; it was a rational response to the environment.
Shopify is a different environment, and it pulls almost exactly the opposite direction. It rewards configuration over customization, autonomy over control, and distributed ownership over centralized gatekeeping. For a brand that has spent six years optimizing in the other direction, that’s not a gentle nudge. It is a genuine collision of two coherent but incompatible logics—and the migration is the moment when the collision becomes impossible to ignore.
There are two migrations inside every Shopify migration. There is the technology migration: the data, the integrations, the theme, the cutover. This is the migration the project plan describes. And there is the operating-model migration: the workflows, the ownership boundaries, the moments where the organization has to decide that something that used to take three weeks is now allowed to take three hours. This is the migration the project plan does not describe.
If you do one without the other, you arrive at launch on the new platform with the same organization.
There are two organizational instincts that served you well on Magento and will work against you on Shopify. Both of them are, locally, rational. Both of them will arrive at the migration intact, unannounced, and load-bearing. Neither of them will identify itself in the project plan.
The customization instinct. On a legacy platform, custom development was the default answer to almost every problem. When the platform couldn’t do something natively, you built it. Over time, the organization wired itself around that assumption: engineering teams grew to support it, procurement got fluent in the language of scoped builds, and the idea that you owned and controlled every layer of the stack became part of how leadership thought about competitive advantage. None of this was unreasonable. SFCC and Magento were flexible precisely because they expected you to build on top of them. The custom build was the right tool because the platform was the right shape for the custom build.
Shopify inverts that logic. The platform has strong opinions about how things should work, and fighting those opinions is always expensive—in development time, in maintenance burden, and in the technical debt that accumulates every time you bend the platform away from its intended shape. Custom development does not disappear; you will have requirements that genuinely warrant a bespoke build, and we will spend several later chapters telling you exactly which ones. But the default question has to change. Not how do we build this? The new question is: does Shopify get us 90% of the way there?
That sounds simple. In practice, it requires active sponsorship from leadership, because the engineers who have spent years on Magento will, absent that sponsorship, drift back to custom solutions. They are not being obstructive. They are being themselves, which is a thing that looks like obstruction from a distance and is, on inspection, just the trained muscle doing what it was trained to do.
The control instinct. On the old platform, content changes required code. Deployments required coordination. Non-technical teams learned to work around this by:
- Filing a ticket.
- Waiting for prioritization.
- Waiting for development and QA.
- Planning the next campaign around however long all of that took.
The system was slow. The system was frustrating. The system was also stable, in the sense that a poorly considered content change could not, by itself, take down the homepage. For platforms where breaking the homepage was a real possibility on a Tuesday afternoon, that level of control was not unreasonable.
Shopify removes most of the technical barriers that made the control instinct necessary. But removing the barrier does not, by itself, remove the behavior. Teams that have spent years filing tickets do not spontaneously self-serve when the tool appears in their hands. The reflex runs deeper than the tool. And it is reinforced—this is the part most migration plans do not budget for—by a reasonable fear.
The cumulative effect of the customization instinct and the control instinct, multiplied across an enterprise organization, is a Shopify migration that lands on the new platform and then runs it like the old one. Engineering still owns content. Custom builds still live where configuration would have done. Flow automations are written in long, brittle scripts because nobody on the operations side has been given the keys to compose their own. The theme editor sits—mostly used, partly used—in the way a treadmill sits in the spare bedroom of a person who has, technically, joined a gym.
Brands in this position get somewhere between two-thirds and a half of the practical value of the platform. They have paid for the whole platform. They are running on a slice of it. The slice they are running on is, by any honest measure, better than what they had before—Shopify is a faster, more modern, more reliable platform than the one they migrated from, even when used poorly. So the migration succeeds. It succeeds in the sense that the dashboards turn green, the launch goes out, the press release reads cleanly. It also leaves, on the floor of the room, a substantial fraction of the reason the migration was approved.
The thing left on the floor is what the next eighteen months of your roadmap was going to be paid for with.
Owen Caldwell, Greycott’s Head of E-Commerce, sent his agency a note in the third week of discovery that read, in full: We’re going to need to think about training, right? Like, what the content team actually does with the new editor on the morning we hand it to them.
This is the kind of email an agency does not usually get in the third week of discovery. (We usually get it in the third week after launch, written in a register that is much less collegial.) Owen had been reading. Owen had been reading specifically about the failure mode in which the content team is given access to the new system and then, three weeks in, is discovered to have changed nothing. Owen wanted to head that off. Owen’s instinct was correct.
Across the hall—figuratively; Greycott’s office is, in fact, a fairly small converted warehouse near the Charleston waterfront, and Priya’s desk is sixty feet from Owen’s—Priya Shah was running her own version of the same calculation, in the privacy of her head, on her own timeline. Seventeen spreadsheets, Priya observed, to nobody in particular, will not migrate themselves. And then, having said this only to herself: And nobody has asked me which of them should.
Priya was right. Nobody had asked her. The migration plan listed operations under the column labeled post-launch onboarding, with a date set for the second month after the cutover. By that date, the migration would have decided—in code, in configuration, in Flow automations written by the integration team—which of Priya’s seventeen workflows the new platform would absorb natively and which it would not. Priya would arrive at her post-launch onboarding and discover that fourteen of the decisions had already been made on her behalf, by people who had never opened the binder.
These are two different versions of the same realization. Owen has arrived at his early. Priya has arrived at hers without anyone noticing she had arrived. Both of them are telling the agency, in their separate registers, the same thing: the migration you have planned is not the only migration that needs to happen, and the second one is mine.
If you only have a project plan for the first migration, the second one happens to you. If you have a plan for both, the second one happens with you. The difference is the difference between an organization that operates the platform and an organization that watches it operate.
The most common mistake is to treat the operating-model migration as something to figure out after the technology migration ships. It feels logical. Get the platform live, then sort out the workflows. In practice, it means arriving at go-live with a capable platform and an organization that does not know how to use it, and then trying to retrofit governance onto a system that is already in production, while every team that was promised they would finally have autonomy watches you build the new ticket queue with their own eyes.
There are three pieces of work that have to happen during the migration itself, not after. We will name them once and then talk about them across the rest of the book.
The first is the workflow audit. Before the build is underway, you sit down with the teams who currently route everything through engineering—content, marketing, operations, customer service—and ask them, workflow by workflow, which of these does Shopify push back to you, and which of these does it leave with engineering? This is a small project. It takes a week and a half. It is the single highest-leverage week and a half in the entire migration, and it is the one most often skipped because it does not produce a diagram anybody wants to put in a status update.
The second is participation in the build. The teams who will operate the platform should be touching the platform during construction. Not as observers. Not as the people who sign off on a Friday. As operators, hands on the staging environment, building real pages, breaking things in a sandbox that is allowed to break. The participation does two things at once: it produces operators who arrive at launch with genuine confidence rather than theoretical training, and it lets you build the guardrails into the architecture as you discover where the guardrails need to be. The Magento brand that did this—the contrast case to the AI-section-generation story, the same kind of organization a year earlier—rebuilt their entire homepage with the content team in the room. By launch, the content team was not capable of operating independently. They were operating independently. They had been for two months. Launch day was, for them, a Tuesday.
The third is active leadership sponsorship of the cultural shift, particularly around the customization instinct. If leadership is not in meetings saying, out loud, we are going to use Shopify the way Shopify wants to be used, and the burden of proof is on the custom build, not on the configuration, the engineering team will fill the vacuum with the habits it already has. The engineering team is not being uncooperative. It has not been told to do anything different. The habits are the default. Sponsorship is what changes the default.
None of this is complicated work. It is, however, real work, and it has to be scoped, budgeted, and staffed alongside the technology migration. The brands that treat it as an afterthought tend to complete their migrations on time and then spend the following year slowly discovering how much value they left behind.
Act I has told you, in various ways, that this book is not a checklist book. The reasons for that have been accumulating. The mid-market math doesn’t survive the jump. The project is two projects in a trench coat. The agency proposal is a document mostly about itself. The politics of the migration are the migration. And now this: the system you are migrating is not the only system that has to migrate.
The technology migration gets you onto Shopify. The operating model migration is what determines how much of Shopify you actually use. Brands that conflate the two arrive on a faster, more modern, more reliable platform—running on the same organizational assumptions that made their old one frustrating. The infrastructure changes. The bottlenecks don’t.
The rest of the book is, in one way or another, the second migration. Act II is what you do before anyone moves anything—discovery, sequencing, the wine retailer who anchored the lesson, phased versus big-bang, the data modeling decisions that lock in your shape for the next decade. Act III is how to run the project—cycles inside a waterfall, the steering committee and the task force, project management as cartography. Act IV is the technical core, the surfaces—apps as governance, custom builds, middleware, Markets, search, checkout. Daniel Okafor’s name is on most of it. Act V is the things that look done from the outside but aren’t—compliance, accessibility, tracking, SEO, testing, staging. Act VI is the cutover, the first four weeks, and the operating-model gap that surfaces only after launch. Each act is, on inspection, also the second migration. We will keep saying so. You will, by the time we are done, be a little tired of it. That will be the right amount of tired.
The early-adopter brand from our intro is fine, by the way. The cleanup worked. The handoff process held. The next campaign shipped without incident, and the marketing team kept using the AI tool—with the guardrail in place—and built genuinely good pages with it. The damage was real, but it was repairable. Nothing about the story is a tragedy. The only waste in it is that the handoff process existed, in everybody’s head, in the third week of the project. It just hadn’t been written down, because nobody had decided whose job that was.
The migration you forgot to plan is the one that decides what the platform is for.
Plan it.