Act III: Middle Distance
Architects And Cartographers
The migration plan looked clean on paper. Cycles, story points, a three-month buffer, weekly demos. By week six, the team was waiting on a customs vendor in another time zone, the designers had drawn filters that would each need their own meta object, and the historical product import—supposedly a back-half task—was already reshaping the data model.
The tools weren’t wrong. The discipline was.
This is what happens when a competent project manager runs a custom-build playbook on a Shopify migration. The standups still happen. The tickets still move. The burndown chart still slopes the right way, more or less, if you don’t look at which tickets are moving. The stakeholders are nominally happy. But somewhere underneath, the project has stopped being a build and started being a negotiation with a platform that doesn’t read the calendar.
Naomi Brennan was hired to run Greycott’s migration, and she was hired because she was good. Before Greycott she’d shepherded a healthcare ERP rollout across four regional hospitals—eighteen months, regulatory sign-offs, a data model with patient records in it, the kind of project where a mistake is not a refactor but a deposition. She took the Shopify job in part because, after the ERP, it sounded like a holiday. (It is the people who say this out loud whom the platform comes for first. The ones who say it only to themselves get a few extra weeks.)
She is not the villain of this chapter. She is its protagonist, and she is very good at her job, and that is precisely the problem—because the thing she is good at is the thing that hurts here.
The shift from custom development to Shopify isn’t a question of speed. It’s a question of agency.
On a custom build, the system bends to your decisions. You own the data model, the deploy pipeline, the integration layer, the admin. When something breaks in week ten, you refactor it in week eleven. The cost of being wrong is mostly internal—your team, your time, your tradeoffs—and it is a cost you can pay later, which is a way of saying it barely feels like a cost at all. The whole discipline of running a build is organized around this fact. Keep the work moving. Adjust as reality reveals itself. Missed an integration spec? Add a sprint. Found a performance problem? Refactor it. The system answers to you.
On Shopify, the platform sets the perimeter. The data primitives are what they are. The customer accounts surface is what it is. Markets is what it is. The project manager works inside the perimeter rather than over it, and the difference is not philosophical, however much it sounds it. Architects shape the world. Cartographers read it. The job that used to be about shaping is now, mostly, about reading—reading the terrain accurately enough, and early enough, that you don’t march the team into a canyon the map already showed.
We have watched seasoned project managers treat Shopify as a development environment they expect to bend to fit, and then discover in month four that a customer-accounts decision they’d like to revisit was locked in by primitives chosen in month one. The path from we should change this to actually changing it runs through the platform’s idea of how customer accounts work, not through the team’s idea. The decision wasn’t reversible. It just looked reversible. (You find out the part you can’t refactor is the part you didn’t write.)
So here is the uncomfortable thing, said plainly to the senior project manager reading this and feeling the first prickle of defensiveness: the muscle you have trained the longest is the one that will mislead you the most. Fast course-correction inside a tight feedback loop is the most valuable instinct on a custom build and a liability on this one. It is not that your experience doesn’t transfer. It is that the most transferable part of it—I can fix this in flight—is the part that’s quietly false here, and false in a way that won’t announce itself until the cost of the fix has already compounded. The most experienced people sometimes struggle the most, for exactly this reason. They have the most muscle to unlearn.
If you can’t fix things in flight, the work has to move from triage to anticipation—and anticipation is harder, not because the thinking is harder but because the waiting is. On a custom build the bottleneck is usually inside your team, where you have leverage. On Shopify the bottlenecks are mostly outside it, where you have none. An ERP integrator on a different release calendar. A payments partner with a multi-week onboarding queue. A Shopify app whose roadmap doesn’t bend to your timeline. A platform feature that’s almost-but-not-quite what you need, with the gap filled by somebody else’s quarter. The work itself is no harder. You just can’t unstick it from inside the room, and a project manager whose entire reflex is to unstick things from inside the room will spend a great deal of energy pushing on a wall.
The teams that adjust run a different kind of risk register. Not what could go wrong inside the team’s work but what could go wrong outside it, and how early do we need to know. The further out you can see, the more you can compress the project. The closer to the deadline a surprise lands, the more expensive it is—and on a platform where the lever you’d normally pull doesn’t exist, expensive can mean the launch window itself.
Naomi, to her credit, figured this out faster than most, and the way she figured it out is worth describing because it looks like a personality quirk and is actually the whole job. She kept two timelines—one for the steering committee, made of the dates everyone had agreed to, and one for herself, made of the dates she actually believed. The committee’s timeline was a promise. Hers was a forecast. And because she maintained the forecast honestly, she tended to know the slip two weeks before anyone else did, which gave her two weeks to do the only thing that helps: tell someone outside the team, early, while two weeks was still enough. On the ERP project, that habit had been a hedge. On the migration, it turned out to be the instrument—the thing a cartographer carries instead of a steering wheel. She had spent years building it for the wrong reasons. It was the right tool the whole time.
Anticipation only works if the decisions that need deciding early actually get decided early—and the trap is that several of the most consequential ones look like back-half work. They look deferrable. They are not.
Shopify migrations are more waterfall-shaped than most teams expect, not because waterfall is virtuous but because the order in which decisions land determines the data model, the design system, and the launch surface, and getting the order wrong compounds for the rest of the project. A handful of things belong at the front even when they look like things you’d do later:
The historical data import is the one that surprises teams most. It feels like a migration task—move the old rows into the new system, late, once the new system exists. But the shape of the legacy catalog, the gaps in its attributes, the conventions the merchandising team quietly built around the old platform over six years—all of it bleeds into the data model you’re standing up now. Defer the import and you’ll backfit the model to it later, badly, while every other workstream pulls against the change. This is where the chapter’s quieter truth lives, the one worth carrying into every act that follows: migrate the assumptions, not just the code. The rows are the easy part. The decade of unspoken conventions baked into them is the part that reshapes everything downstream, and it does its reshaping whether or not you scheduled it.
The major external integrations—ERP, OMS, CRM—have their own release calendars and their own onboarding queues, and the earlier you have a real specification, the earlier you learn what’s negotiable and what isn’t. The architectural choices—Markets, customer accounts, headless or stay-in-theme—shape every downstream decision and are not details to revisit but constraints to commit to. And the large custom features, the ones with their own data layer or admin surface, have to be sequenced by what depends on them rather than by when they feel due.
Greycott’s store locator was the example that taught the team this in the small. Greycott has three retail stores and a wholesale arm, and the locator wasn’t a footer afterthought—it surfaced on the homepage, on product pages, in the logic that told a wholesale customer which of the three stores held their account. Every one of those surfaces had to take a dependency on it. Built last, it would have meant rebuilding everything that depended on it once it finally landed. Built first—sequenced by its dependents, not its deadline—it was just infrastructure the rest of the build could stand on. Nobody wanted to ship the store locator in week three. Reading the map, you could see there was no other week to ship it in.
There is an honest limit to all of this, and naming it is part of the job. In an ideal world the data model would never bend to a third-party integration’s schema. In Shopify’s world, sometimes it does—because the cost of fighting the integration is higher than the cost of compromising the model, and a cartographer who pretends otherwise is drawing a coastline where she wishes the water were. Name the tradeoff out loud, with stakeholders, before it bites. The bend you choose deliberately in month one is a decision. The bend you back into in month four is a wound.
The project manager can’t be the only person in the room who can read the terrain. The most expensive mistakes on a Shopify migration are not made by the platform interpreter who knows the constraints; they’re made upstream of her, by people who don’t, in rooms she isn’t in.
A designer who doesn’t know what Shopify will allow draws experiences that engineering then retrofits at high cost. A set of category filters on that opening migration—the ones in the cold open, drawn freely, rich and varied, the kind of filtering that feels modern—would have required a dedicated meta object per filter value to ship as imagined. Which meant Daniel Okafor’s engineering team carried the weight of building the structured-content scaffolding, and the merchandising team inherited a sprawling surface they’d have to maintain by hand every time they added an attribute, forever. The design was beautiful. It aged faster than it should have, the way things age when their upkeep is somebody else’s job and nobody decided whose. The whole thing could have been a different, equally beautiful design, if a thirty-minute briefing had happened before the screen was drawn. It didn’t. (If your designer doesn’t know what a metafield is by week three, that’s a process problem, not a designer problem.)
The fix is unglamorous and rarely happens by default: a short briefing before each design section starts, walking through what the platform supports natively and what it doesn’t. It sounds too obvious to write down. It is skipped on roughly every migration that later wishes it hadn’t been. The broader principle is the one to keep: on Shopify, there is no blank canvas. Every screen is a negotiation with the platform. The teams that win those negotiations early ship less custom code, fewer brittle workarounds, and a store the brand can actually operate for years. The teams that win them late ship a launch and a backlog of regrets.
So the new job description, if anyone were honest enough to write it: the Shopify migration project manager isn’t a slower version of the custom-build project manager. They’re half product manager, half platform interpreter. They translate business intent into what the platform will actually let you ship, and they translate platform constraints back into product decisions stakeholders can act on. The day-to-day looks different, too. Less chasing tickets, more reading the system. Anticipating what’s about to break. Sequencing the next decision before the team needs it. Holding the line, gently, against the part of everyone—themselves included—that still believes this can all be fixed in flight.
There is a reason this lands so often on the operating-model migration we spent the end of the last act describing. The interpreter’s job and the second migration’s job are the same shape: both are about the gap between what the platform does and what the organization assumed it would do, and both get worse the longer nobody names the gap out loud. The infrastructure changes. The bottlenecks don’t—not unless someone whose whole job is reading the system reads that one too.
Naomi got there. Not on the first migration; she’d be the first to tell you she ran the early weeks of Greycott’s the way she’d run the hospital build, pushing on walls, and that the walls did not move. She got there around the week she stopped opening the standup by asking what was blocked and started opening it by asking what we’d know two weeks from now that we don’t know today. That is a small change in a meeting agenda. It is the entire difference between the two jobs. The project managers who get this right are usually the ones who got it wrong on their first migration. The discipline is learnable. It’s just not the one most replatforming projects start with.
She course-corrected for six months. The course was a circle. The seventh month, she stopped steering and started reading, and the project—which had been a build pretending it could outrun the platform—finally became what it had been all along: a negotiation with a map.
Architects ship plans. Cartographers ship in spite of them.