Replatforms Are Political Projects · The Reluctant Guide to Shopify Migrations

Priya Shah, Greycott & Co.’s Director of Operations, has a binder. The binder lives in the second drawer of her desk in Charleston, and the binder contains seventeen weekly spreadsheets. She has been running these spreadsheets every Monday for nine years.

The first spreadsheet—she opens it from memory now, doesn’t even glance at the binder—is the wholesale invoicing reconciliation. The second is the retail forecast. The third is what she calls “the QuickBooks thing,” which is what happens when the warehouse’s inventory feed disagrees with finance’s. The fourth through the seventeenth are smaller, but they are all hers.

The new platform is going to make most of them obsolete.

Nobody has told her this. They don’t need to. She already knows.

Priya is not the antagonist of this chapter. Fear is.

Most agencies walk into a replatform expecting a clean org chart. There is a product owner on the brand side—a single person who gathers requirements, makes decisions, serves as the central point of contact. The agency talks to that person, that person talks to everyone else, and the diagram works.

The diagram never works.

At enterprise scale, the product owner is a generalist in an organization full of specialists. They can tell you what the e-commerce team wants. They cannot tell you how the warehouse processes returns, because they have never processed a return. They cannot tell you why finance needs a particular field at checkout, because they have never reconciled a chargeback. They can tell you that the content team has a workflow. They cannot tell you what the workflow is, because they have never been the person clicking through it at 11pm on a Sunday before a product drop. Funneling every conversation through them creates a bottleneck that slows the project, but more importantly, the bottleneck filters out the details, and the details are where this kind of project either works or doesn’t.

The deeper problem is that the diagram treats the brand as a monolith—one organization, one set of requirements. Enterprise organizations are not monoliths. They are collections of teams who have, between them, the agendas that get printed on the project charter:

A long conference table viewed from above, surrounded by mismatched chairs all angled differently, with overlapping calendar pages lying face-down on the table surface. — Every chair in the room has a different reason for being there.

The CFO wants the cost savings that justified the project.
Marketing wants campaign autonomy without filing dev tickets.
The content team wants a CMS that doesn’t make them want to be a forklift operator instead.

These agendas overlap in places and directly conflict in others. The project charter prints the conflict-free version. The project does not get the conflict-free version. (Ask us how we know.)

The agenda you can read in the project charter is the easy half.

A Field Guide To Fear.

Fear, on a replatform, is a field. Fear is taxonomic. Fear has subspecies. We have spent enough years on enterprise migrations to compile a partial catalog, which we offer here with the mock-academic confidence of a person who has been bitten by every specimen.

Genus: Operational. Species: The Process-Gap Fear. The fear that the new platform will expose an inefficiency the team has been quietly absorbing for years. The seventeen-spreadsheet workflow is not, on inspection, the cleanest way to do wholesale invoicing—there is a way to do it in the system, natively, in two screens. Priya knows this. Priya also knows that the existence of those seventeen spreadsheets is what has, over nine years, made her load-bearing. The new platform does not threaten her job. The new platform threatens her uniqueness, which is a more personal threat and harder to name.

Genus: Executive. Species: The Original-Choice Fear. Somewhere in this organization is the executive who, six years ago, championed the platform you are now leaving. They are not on the steering committee by accident. They are on the steering committee because their original judgment is, by implication, on trial. They will not say this. They will, instead, ask a great many sharp questions about the new vendor’s roadmap and the integration partner’s track record. They are not being obstructive. They are being defensive, which is a thing that looks like obstruction from twenty feet away.

Genus: Workaround. Species: The Institutional-Knowledge Fear. The senior engineer who has, over five years, accumulated a kind of folk knowledge about why certain things in the old platform behave the way they do. The folk knowledge is real. The folk knowledge is also tied to a system that is going away. The senior engineer is not, technically, going away—but the version of themselves that mattered (the one who knew where the bodies were buried) is. They will tell you, in the second week of discovery, that something can’t be migrated. What they mean is that they are not sure whether the version of them that knew how it worked will exist after it is.

Genus: Career. Species: The Public-Failure Fear. The Head of E-Commerce who lobbied for this migration in last year’s strategic offsite, secured the budget, and put their name on the business case. If it works, they are a hero. If it does not work, they are the person who burned eighteen months and three million dollars on a project the board had to be talked into. They will, at every status meeting, ask whether things are on track. They are not asking for a status update. They are asking whether they are still safe.

There are others. Vendor fear (next subsection). Warehouse fear (a chapter of its own, later). Designer fear, which is a kind of imposter fear that surfaces when somebody first mentions the word metafield.

The catalog is partial. The catalog is also, on reflection, tender. Every one of these fears is a person being asked to walk into a room they cannot see the floor of. We do not write the catalog to make sport of them. We write it because if you cannot name a fear, you cannot work with the person carrying it. You can only label them resistant and move on, which is the thing most replatforms do, which is one of the reasons most replatforms hurt.

Your vendors are afraid too. Different fears, but the same field.

A vendor whose contract is up for renewal around the same time as your migration is a different vendor than one with a multi-year agreement still on the books. A vendor who is being replaced as part of the migration has, mathematically, a zero-percent incentive to help you migrate away from their product. A vendor who sees the migration as an opportunity to upsell you on additional services will be eager to help, but their helpfulness will arrive shaped like an additional service.

None of this makes vendors adversarial. It makes them stakeholders, with the same kind of stated-versus-unstated agendas the brand-side teams have. Treat them that way. Ask, early, what each vendor’s renewal cycle looks like. Ask, early, what their dedicated-migration support looks like—your logistics provider may have migrated forty clients to Shopify already and can configure their side of the integration with one short call. Ask, early, what they need from you and by when; vendor lead times are the thing most likely to cause a last-minute scramble, because the vendor’s calendar is not your calendar and nobody warned you of that.

The vendor up for renewal during your launch window is the stakeholder hiding in plain sight. (Ask us how we know.)

So: you have an organization full of stated agendas, unstated agendas, and a partial catalog of fear. The conflicts are coming. The question is whether you have a process for them or whether each one becomes an ad hoc political negotiation.

A structured process does two things at once. First, it forces the relevant operators into the room—not just the executive who owns the budget, but the warehouse manager who will use the logistics tool fifty times a day. The decision the executive makes in a vacuum is the decision that, six months later, generates the all-hands rant about the new system. Second, the structured process depersonalizes the conversation. You document each option with its pros, its cons, and its concrete business impact. The conversation stops being Priya’s opinion versus Owen’s opinion and becomes option A reduces operational overhead by an estimated four hours a week but adds three weeks to the timeline; option B ships in the original timeline but requires a manual reconciliation step we’ll have to revisit in Q3. People can still disagree. They will be disagreeing about the same facts, which is the only kind of disagreement that produces a decision rather than a grudge.

Once the decision is made—with the operators in the room, with the options on paper—you apply disagree and commit. Everyone moves forward. Including, especially, the people whose preferred option lost. The person who advocated hardest for option A does not get to relitigate option A in week eleven. They get to surface new information if it appears. They do not get to surface the original argument because they have had time to think of new ways to phrase it. Relitigation is one of the fastest ways to bleed a migration to death; the rest of this book is largely a catalog of the others.

The further you get into a replatform, the easier it is to lose the thread. Sprints fill. Integration issues multiply. The day-to-day mechanics start to crowd out the original goals, and at some point your team is delivering—tickets closed, features shipped, milestones hit—without anyone checking whether the things being delivered are still the things the business needed when the budget was approved. This is how a project arrives at launch having done everything on the plan and still feeling like a disappointment. You have, in this scenario, successfully executed a plan that stopped describing the right project around month four.

The antidote is a cadence with senior stakeholders that operates at a different altitude than your sprint reviews. Not a report on what got done last week. Not a list of risks color-coded green-yellow-red. An honest, sentence-level conversation that asks: is this project still pointed in the right direction. Are the ground-level trade-offs accumulating in ways nobody has explicitly acknowledged? Has the business case quietly drifted out of sync with the work?

This conversation is hard to schedule and easy to skip. Schedule it anyway. The senior stakeholder is the person best positioned to hold the original vision and senior enough to unblock things when the project drifts. They can only play that role if you tell them the truth, and the instinct in a difficult moment is to soften the truth on the way up, the way you might soften it for a relative who has been sick. Resist this. Soft truth is the most expensive thing you can deliver to a steering committee. It is the line item that does not show up in the project plan and shows up, in full, in the change-order document later.

Now: Priya.

You have an organization full of fear, an inventory of stated and unstated agendas, a structured way of resolving conflicts, and a senior-stakeholder cadence that holds the vision. There is one more thing.

Put the platform in their hands.

Not in a slide deck. Not in a workshop. Not in a screenshare with the project manager narrating. In their actual hands. Give them a login. Give them the staging environment. Tell them which tasks they can try and let them try them. Tell them which corners are still under construction and that those will be ready later.

What happens, almost every time, is this. The team member who was indifferent about the migration—or quietly hostile to it—performs, on the new platform, a task that used to take them fifteen minutes. The task takes them two clicks. They sit, for a moment, with the two clicks. They click them again to make sure. They do it a third time, because the first two felt like a trick.

Two hands hovering just above a laptop keyboard in a frozen, disbelieving posture, the laptop screen turned away from the viewer. — They clicked it a third time. The first two felt like a trick.

Then something turns. Passive tolerance turns into active advocacy. The person who was dragging their feet on UAT last month is, this month, asking when the next module is going to be ready, because they have ideas about how their team should be trained on it. The person who feared the new system as a referendum on their old choice is, this month, asking whether the new system can do something the old one couldn’t. The fear has not disappeared. The fear has been answered—concretely, by experience, in their own hands, on their own time. You cannot reason a person out of a fear they cannot test against. Once they can test against it, the reasoning takes care of itself.

This is also the only way to avoid the launch-week UAT crunch. A massive UAT phase at the end of a project is where timelines go to die. Continuous, in-the-hands validation throughout the project surfaces issues in month two, which are fixable problems; the same issues surfaced in launch week are crises. The difference is not which issues exist. The difference is which week you find them.

Head of Digital Whose Board Approved This Last Tuesday: Priya is not your problem. Priya is your colleague. The system that produced Priya’s seventeen spreadsheets did so because, nine years ago, Greycott did not have the platform to handle wholesale invoicing natively, and Priya stepped in. She did the job the company needed done. That she did it well enough, for long enough, to become indispensable is not Priya’s fault. It is a story about institutional adaptation, and the migration is the next chapter of that story, and Priya is, in that next chapter, going to do another version of the same thing—she will figure out how the new platform fits her workflows, then her team’s, then the warehouse’s, and then she will become indispensable again, in a different way. Her job is not at risk. Her uniqueness is changing shape. Tell her that. Out loud. Soon.

Operations Director Reading This Late In The Day Because Sleep Has Been Difficult Lately: we see you. We have been with people in your role through six versions of this story. The fear is real. The fear is also temporary. The thing on the other side of it—the version of you who knows the new platform deeply enough to be the person other people ask—that person exists already. You have not met them yet.

E-Commerce Director Whose Project Charter Has The Phrase “Single Product Owner” In It: delete that phrase. We are not going to ask you why it is there. We are going to ask you to delete it. Replace it with an embedded working group with operators in the room. It will not change the structure of the project—it will describe the structure the project is going to take anyway, which is half the battle. The other half is convincing procurement that the working group is not a billing problem.

Priya’s binder is still in the drawer. We have not done anything about the binder yet.

By month nine of the migration, three of the seventeen spreadsheets are gone—absorbed into native platform reports she can run without leaving the admin. By month twelve, eleven of them are gone. By the time the team writes the post-launch retrospective, Priya is the person who runs the training sessions for the wholesale team on how to use the new reporting dashboard. She has, in writing it, written herself a new job description. Nobody at the company asked her to.

The binder is still in the drawer. Priya keeps it there. She has not opened it in fourteen months. It is, by now, more of a totem than a tool—a record of a previous version of the job, kept by the person who carried it.

We bring it up because if you do this right, somebody at your company will have a binder too. They will have it for the same reason. And the question of what happens to that binder—whether it gets thrown out or kept on a shelf or absorbed into something new—is, in a real sense, the question of whether you have actually migrated, or only moved.

Most replatforms move.

This one, we hope, migrates.