Act II: The Antechamber
Big Bang Or Phased (Or: How To Pick A Doorway)
Week ten.
The conference room had a printed timeline pinned to the wall—A3, color-coded, signed off in the kickoff. The cutover date sat at the right edge of the timeline in a bold red bar. Underneath the bar, someone had written, in the same red marker, D-Day. It had been a joke. It was no longer.
Greycott & Co. had committed to a big bang Magento → Shopify cutover. The dual-run option had been on the table during the proposal phase. We had estimated it. We had priced it. Everyone agreed it was the safer route. Everyone also agreed it was too expensive. Building and maintaining the integration layer between Magento and Shopify—order mirroring across DTC and wholesale and the three retail POS systems, inventory propagation in both directions, customer records consistent across channels—had a number attached to it that the CFO took home and read twice and brought back the following Monday with the word no written in pencil next to it. We respected the no. We moved on to big bang.
The reason we are telling this story is that, in week ten, someone in the room said, calmly, without anyone raising their voice: we need to reopen the dual-run conversation.
What had changed was not the math. The math was the same. What had changed was that the integration landscape had revealed itself.
Greycott’s Magento stack had been integrated, over the better part of a decade, with NetSuite for ERP, a 3PL for DTC fulfillment, a separate wholesale order management system that a contractor had bolted to the side of NetSuite in 2019 and that nobody had touched since, a marketing automation platform, a tax engine that handled sales tax across forty-three states, a label-printing service for the wholesale arm, and the POS at the three retail stores—each of which had been onboarded under a slightly different version of the POS software, and now expected slightly different webhook payloads. None of these integrations were exotic. Each of them, individually, was reasonable. The problem was that you could not cleanly cut over to Shopify without rebuilding all of them on the new platform on the same day. And rebuilding them, in parallel, with hard launch deadlines, against vendors who took two weeks to respond to a support ticket—this was the part the proposal phase had under-modeled.
Big bang is concentration of risk. We had said that in the proposal. We had not, in week one, understood the shape of the concentration. We did, in week ten.
The dual-run conversation came back. The CFO did the math again. The number was still big. The number was no longer the largest number on the table.
The plan changed.
It changed without anyone raising their voice. It was not a panic. It was the team having had the conversation about phased once already, in the proposal—knowing the alternative existed in the architecture, having held flexibility in reserve precisely so that this week-ten conversation could happen without the project being rebuilt from scratch.
Daniel Okafor was in the room when the plan changed. He was being very polite about it.
We will tell you why in a minute.
It is, in particular, about the fact that most brands never make the call we just described.
Most brands make this call by default rather than by design, usually because their agency only knows how to do it one way. The agency runs big bangs because the last three projects were big bangs, the team is good at big bangs, and the case studies on the website are about big bangs. Or the agency runs phased rollouts because they bill more hours on phased rollouts. Either way, the answer is the answer they were going to give before they met you.
That is the failure mode we want to head off. Not big bang. Not phased. Defaulting.
So we are going to walk through both, with the costs visible, the risks named, and the questions you should be asking in week one—not week ten.
Big bang is exactly what it sounds like. You build the new platform, flip the switch on launch day, and retire the old system. Everything moves at once.
This is a legitimate strategy. There are brands for whom it is the better strategy. The conditions look like this. You only want to maintain one platform at a time, which lowers infrastructure cost and removes the cognitive overhead of running two admins, two reporting surfaces, two source-of-truth conversations. You have a minimal integration layer—a payment provider, a shipping carrier, maybe one ERP webhook—and rebuilding those on the new platform is a contained workstream, not a project of its own. Your tech stack is straightforward. Single market. Single channel. A catalog that is not exotic. A checkout that has not accreted custom logic over several years. Your order volume is moderate enough that a worst-case launch hiccup—a degraded day, a few hundred orders to reconcile by hand—is a problem you can absorb without filing it as a board-level incident.
When those conditions hold, big bang is the most efficient route to Shopify. Phased migrations have real engineering costs—we will get to them—and paying those costs when you do not have to is its own failure mode.
The trouble is the downside, which is concentration of risk. When everything goes live at once, everything can break at once. If your data migration has edge cases you didn’t catch in testing—and there are edge cases you did not catch in testing; this is a statement about the world, not about your team—you discover them on the day when the stakes are highest. If a third-party integration behaves differently under production load than it did under staging load, you discover that on the same day. If your customer service team has not yet internalized which platform is the source of truth for refunds, you discover that on the same day, while a queue of refund tickets accumulates.
Rollback is often impossible. The moment you start taking orders on the new system, your customer and order data diverges from the old one. The two databases are no longer the same database. Reverting the cutover means choosing which set of records to keep and which to throw away, and the answer to that question is neither, please, but neither is not an option.
For a brand doing two hundred thousand dollars in daily revenue, even a few hours of downtime or degraded performance during a botched cutover translates into hundreds of thousands of dollars in lost sales—plus the operational chaos of reconciling orders and inventory and customers across two systems that were never designed to run in parallel, plus the customer trust hit, plus the team-morale hit, plus the board call. The numbers compound.
This is what we mean by concentration of risk. Big bang takes every risk in your migration and stacks them on the same hour.
A phased migration takes the opposite approach. Instead of moving everything at once, you migrate incrementally, validating each step before expanding scope. The goal is to shrink the blast radius of any single failure—so that when something goes wrong, and something will, it affects a small, contained segment of your business rather than the whole operation.
There are three common ways to phase, and the right one depends less on preference than on the shape of your business.
The first is market by market. The most common approach for brands with international operations. You launch Shopify in a low-volume market, run it alongside the legacy platform, and roll out additional markets as you build confidence. Your highest-volume market goes last. Useful when your business is sliced naturally by geography.
The second is channel by channel. The same principle, sliced by sales channel rather than geography. A wholesale portal goes first. Or a secondary brand. Or a B2B storefront that runs at lower volume and serves a more tolerant customer base. Your flagship DTC storefront—the one that generates the headline revenue and the headline scrutiny—stays on the legacy platform until the second-tier channels have proven the new one.
The third is feature by feature. The technically complex option, and one we will spend an entire later chapter changing our minds about. Feature-by-feature only makes sense in a headless architecture, where the frontend is decoupled from the commerce backend and individual pages can be migrated to Shopify’s APIs while the rest of the experience continues to run on the legacy system. (The list of brands that can responsibly phase feature-by-feature is short, and we have things to say about why it is short. Later.)
These are not mutually exclusive, by the way. A brand can phase by market on the storefront while phasing by channel on the wholesale side. The shape can be hybrid. The point is to choose the shape that maps to your risk surface, not the shape that maps to your agency’s preferred slide template.
Greycott’s pivot, in week ten, was from big bang to channel-by-channel. Market-by-market would not have worked—Greycott sells in one market, with a slow trickle into Canada that is small enough not to count. Feature-by-feature would not have worked either; the storefront was migrating to a standard Shopify-hosted setup, not a headless one. The natural cleavage was the channels themselves, which had been operationally distinct for years and which carried very different risk profiles.
The phasing order, when it landed, was: wholesale first, retail second, DTC last.
Wholesale was first because the customer base was the most forgiving. A buyer at a regional grocery chain who reorders the same SKUs every six weeks tolerates a clunky checkout the first time around in a way that a DTC customer choosing a holiday gift set will not. Wholesale orders also moved through a separate fulfillment workflow at the 3PL, which meant the integration surface area for the wholesale channel was contained: one fulfillment endpoint, one tax flow, one customer-account model. The cost of getting wholesale wrong was a week of frustrated phone calls and a few delayed reorders. The cost of getting DTC wrong was every part of the story we were trying to avoid.
Retail came second. The POS integration was the most operationally fraught—inventory had to sync between Shopify and the three retail stores in near real time, and the staff at those stores had to be retrained on a new POS UI without anyone abandoning the muscle memory of the old one. But retail volume was modest relative to DTC, and the risk surface was visible: if the inventory sync broke, you could see it break at the register, immediately, and pull the lever. (Compare this to a silent DTC API failure, which you discover three days later in a Slack channel nobody was watching.)
DTC came last, because DTC was the channel where catastrophic failure was catastrophic.
Running Magento and Shopify in parallel—for the period between the first channel going live and the last channel cutting over—required, at minimum, the following. Every wholesale order placed on Shopify needed to be mirrored to Magento so that the fulfillment and accounting processes already tied to Magento continued to function. Orders did not arrive in two systems simultaneously by accident; they arrived because the integration layer made them. Every inventory update from the 3PL and the retail stores needed to propagate to both platforms. If a case of olive oil went out the door, both platforms needed to know—and to know it quickly enough that the next DTC customer to land on the product page did not see stock that no longer existed. Every customer record needed to stay consistent. Wholesale customers with net-30 terms had to be recognizable across channels. DTC customers with loyalty points had to have those points respected if they walked into a retail store and presented their phone at the counter. (If you have ever wondered why customer data modeling shows up in a migration scope before anyone has touched the storefront, this is why.)
This is not abstract integration work. It is webhooks, direct API calls, normalization tools, monitoring dashboards, on-call rotations for the integration layer itself, and a list of known divergences we will reconcile manually each Friday that grew and then shrank and then grew again over the course of the rollout.
There is also a less technical layer that nobody warns you about, which is the organizational complexity. The team needed to understand which platform was authoritative for which data in which channel. Support staff had to learn two admin interfaces and the rules for when to use which one. Reporting got harder, because revenue lived in two systems and the consolidation logic had to be built (and reviewed quarterly, and corrected in week seven of that quarter when someone noticed the numbers were off). The finance team kept a small spreadsheet, separate from the BI tool, that nobody had asked them to keep. They had built it the second week of the rollout. They had not turned it off after the rollout ended.
None of this was free. It cost real money and real attention.
It also meant that when problems surfaced—and they did, throughout—they affected one channel rather than the entire business. The team learned Shopify’s workflows in a real production environment, with real customers, real orders, real edge cases, months before the highest-stakes channel went live. By the time DTC cut over, the team had run hundreds of real production days on Shopify in wholesale and retail. The DTC cutover was a logistical event, not a leap of faith.
The point of telling it here is narrower: this is what phased costs, and this is what phased buys you, and the two are worth modeling in week one against the alternative.
The most common objection to phased migration is cost. Yes—building and maintaining an integration layer between two platforms adds to the project budget. There is a number attached to it. The number is real.
The relevant question is compared to what?
The cost of a phased migration is visible and predictable. The cost of a big bang migration gone wrong is invisible until it happens, and then it’s enormous.
You can scope the integration work. You can estimate the additional infrastructure. You can plan for the extended timeline. The number on the proposal is the number, give or take a defensible margin. It is a number you can put on a slide and defend to a CFO who reads slides for a living.
The cost of big bang going wrong is not a slide. It is a postmortem.
If you are processing two hundred thousand dollars in daily revenue and a botched cutover costs you twelve hours of downtime plus a week of degraded operations, the financial impact dwarfs the integration layer. The dual-run line item that looked expensive in the proposal looks small next to the line item for the day we took our checkout offline during the December push because the tax engine was firing on a stale config. The first cost is line-itemized in the project. The second cost is line-itemized in an apology to the board.
We say this carefully, because cost modeling for catastrophic risk is one of those things organizations do badly. By badly, we mean: they do it by not doing it. The downside of big bang is a tail risk, and tail risks have the property of being easy to ignore until the day they aren’t. The job of the migration plan is to put a number on that tail risk and put it on the same page as the dual-run cost, so that the two numbers can be compared on the page they will actually be compared on, which is the steering committee’s.
When the comparison is done honestly, phased often comes out ahead at enterprise scale. Not always. Often.
And there is a benefit to phased that is easy to overlook because it does not appear on the cost side at all. Phased migrations have earlier time-to-value. Because you are launching Shopify in a real channel early in the project, your team starts learning the platform, iterating on the experience, and capturing some of the upside that motivated the migration months before a big bang launch would go live. Every day you’re partially on Shopify is a day you’re capturing some of the value that motivated the migration in the first place. This compounds, both financially and in team capability. It is rarely modeled. It should be.
Now we can answer the question we left at the end of the cold open. Why was Daniel being polite about the week-ten pivot.
The question of big bang versus phased had reached him in week three.
Daniel is Greycott’s Lead Engineer. He inherited the Magento stack from the agency that built it in 2018 and the engineer who maintained it until 2024. He knows where every workaround lives. He had spent the first two weeks of the project nodding politely while we walked the steering committee through our default plan, which was big bang, with a confidence we have since learned to be slightly wary of when it comes unprompted in ourselves.
In week three, he asked the question. Could we model both?
We said yes, of course, that was fine—although the implication in the room, if we are honest, was that we had already modeled both, and that big bang was clearly the right answer, and that doing this exercise was a formality.
Daniel did the modeling anyway. He built a spreadsheet himself. It had two tabs. The first tab estimated the cost of the integration layer for a channel-by-channel rollout—DTC, wholesale, the three retail stores, the integration surface area sketched out honestly across all of them. The second tab estimated the cost of a botched big bang. He used three scenarios—best case, expected case, tail case—and he attached a probability to each. He did not invent the probabilities; he based them on what we had said about our last four projects during the proposal, which Daniel had been writing down in a notebook.
He brought the spreadsheet to the next steering committee meeting. Our project lead glanced at the second tab, glanced again, and asked to take it home and look at it more carefully.
The plan did not change.
We came back the following week with a counter-model that put more weight on the integration cost and less weight on the tail risk, and the steering committee—who, between you and us, had already decided what they wanted to do—went with big bang. We had said the right things. We had also said them in a way that did not unsettle the room. (Ask us how we know.)
Daniel did not push back hard. He had said his piece. He had built the model. He had handed it over. If he had been a louder kind of engineer, he might have insisted, and the chapter would now be about him insisting. He was not that kind of engineer. He was the kind of engineer who said the true thing once, calmly, and then went back to doing the work. He filed his spreadsheet in a folder called migration/planning/scenarios and went on with his week.
Then week ten happened, and the steering committee reversed itself, and the dual-run conversation came back, and Daniel was in the room when it did. He was being polite about it because the people reversing the decision were the same people who had not taken his model seriously in week three—and one of those people, we should admit, was us.
He was, of course, not entirely vindicated. The week-ten pivot was a reasonable call. Whether it was the right call for Greycott—whether all of it worked out the way Daniel’s model said it would—you will find out later in the book. All of it is doing some work in that sentence.
What we can tell you, here, is that the modeling exercise itself was the move. The choice between big bang and phased is not a coin flip; it is a calculation. The calculation requires that someone with standing in the room insist that both options be modeled—and, when the model says something inconvenient, that someone with standing read the model again rather than counter-model it.
Daniel was the first someone at Greycott. We learned to be the second.
The book is, in part, an argument that every migration needs both people. If you are reading this and you do not yet know which one you are, it is probably both.
The right migration strategy depends on your scale, your integration complexity, your team’s capacity, and your appetite for risk. Big bang works for brands with simpler stacks and lower volume. Phased earns its cost when you are operating at scale, have a complex integration surface, or cannot absorb the concentrated risk of a single cutover.
The decision should be grounded in numbers, not instinct—and certainly not in whichever option your agency walked into the room already preferring. The exercise is three steps. Estimate the cost of phased: the integration layer, the dual infrastructure, the extended timeline, the organizational complexity, the things you will discover halfway through that nobody warned you about. Estimate the cost of big bang risk: potential downtime, data errors, delayed time-to-value, team disruption, the postmortem you do not want to write. Compare them honestly. The answers will be different for every brand. At least you will be choosing with open eyes rather than defaulting to whichever approach your agency pitched first.
The goal, again, is to shrink the blast radius of any single failure. That is the motto. It does not tell you which path to pick. It tells you which question to hold in your head while you are picking.
Greycott’s pivot, in week ten, was not a crisis. It was the product of having held the conversation open early—having priced the dual-run option, having understood its shape, having reserved enough flexibility in the architecture to make the change without rebuilding the project from scratch.
The pivot existed because the question had been asked early.
The question is the chapter.