The First Four Weeks · The Reluctant Guide to Shopify Migrations

Week one. The team meets every morning at nine, and the meetings are short, and almost nothing is decided in them. This confuses the new VP, who joined two weeks before launch and assumed a daily standup was where a launch gets run. It isn’t. The dashboards are already green by nine; somebody has looked at them since six. The standup exists for a different reason, and the reason is this: if something needs to be decided today, it gets decided today, in this room, by these people, before they scatter back into the day. The meeting is not a status update. It is a standing offer. It is the team holding the door open for the one problem that has not surfaced yet, so that when it does, there is already a room for it to walk into.

The dashboards say things are fine. The dashboards have been wrong before—you spent an entire chapter earlier in this act on the specific dishonesty of a green screen—so the team treats fine as a thing to be verified daily rather than a thing to be believed. Nobody on this team confuses a quiet morning for a safe one. They have been told, by people they trust, the sentence that this whole stretch of the book has been walking toward, and they are about to find out how true it is.

Launch is the beginning.

That is the sentence. We are not going to dress it up, because you have earned a plain one, and because the work of the next several weeks is mostly the work of believing it after the adrenaline has worn off.

Here is what makes it hard to believe. For months—for a year, on a big migration—launch day has been the day. The plan pointed at it. The freeze led up to it. The runbook existed for it. Every person on the project has, somewhere in the back of their head, been treating launch as the finish line, no matter how many times they nodded along when someone said it wasn’t. And then launch happens, and it mostly works, and the natural shape of the human nervous system is to exhale and to start looking for the exit. The deferred backlog can wait. The monitoring can run on autopilot. The agency can roll off. We did it.

You did do it. You did the hard, rehearsed, frightening thing, and it held. And the move you are now tempted to make—to declare it finished—is the single most expensive mistake available to you in the entire post-launch period, because the problems you deferred did not go away. You deferred them. They are sitting in a queue with a timestamp, and the timestamp is now.

So the first discipline is a cadence, and the cadence is the most boring thing in this chapter and also the one most worth getting right.

Daily for the first two weeks. The whole team, briefly, every morning, in the not-deciding-but-ready-to-decide way described above. Then, when the system has gone a few days without surprising anyone, weekly. Then, when weekly starts to feel like theater, biweekly, and then it folds into whatever your normal operating rhythm is going to be, and you are no longer running a launch—you are running a store.

The mistake is not in the cadence. The mistake is in reducing it too fast. Two clean days are not evidence that the danger has passed; they are evidence that whatever was going to break today has not broken yet today. The pull to drop from daily to weekly in the first week is enormous, because daily meetings are expensive and everyone is tired and the dashboards are green and surely we can give people their mornings back. Resist it for the full two weeks anyway. The cost of a daily standup that turns out to be unnecessary is forty-five minutes and some mild resentment. The cost of having stood down the day before the conversion number quietly cratered is a week of reconstruction and a meeting with someone who outranks everyone in the room. Reduce the cadence as the system earns it, not as your fatigue demands it.

Now, the thing the cadence is for. You are watching, and the question is what.

The instinct is to watch uptime, because uptime is the number that screams. Watch it, of course—but understand that uptime is the easy failure, the one that announces itself, the one that pages someone at three in the morning and gets fixed by breakfast. The failures that actually hurt a migrated store in its first month are the quiet ones, the ones that keep the site up and serving and merely wrong, and you will only find those if you go looking with a specific list and not a general sense of vigilance.

A fishing net strung between two wooden posts, mostly intact but with several small holes and one larger tear near the center; a few small fish lie on the ground beneath the gaps while the bulk of the catch remains held. — The site is up. The net is holding. Most of it.

Conversion delta, broken out—by template, by market, by device. A topline conversion number that looks healthy can be hiding a checkout that broke on exactly one device class, or a single market whose payment method silently stopped rendering, drowned out by every other market behaving. The blended number is the number that lies. Split it the way the previous-to-this material taught you to split traffic, for the same reason.

Search relevance. Your old platform’s search was tuned over years, by people, against real queries, and the new one is doing its honest best against a catalog it met last week. A customer who searches for the thing they came to buy and does not find it does not file a bug. They leave. Watch the searches that return nothing, and watch the searches that return the wrong thing first, because the second category is invisible in every metric except revenue.

Tracking attribution. Somewhere a layer of your tracking stack—and an earlier chapter has already warned you there are three of them—may have come across the migration subtly wrong, so that conversions are firing but landing in the wrong bucket, and the marketing team is about to make a budget decision off a channel report that has quietly gone fictional.

SEO crawl errors, and here the previous danger-zone material is not a callback, it is a live instruction: the first four-to-six weeks are when the search engine recrawls and re-decides what you are, and the damage done on launch day arrives in the numbers now, three and four weeks later, on a delay precisely long enough to let you relax first. And when you read those numbers—watch non-brand first. Brand traffic is loyal and slow and will keep arriving long after the floor has gone out from under everything else, which means it masks the wound. The half of your traffic that can actually hurt you is the half made of people who did not already know your name. Look there first, every time.

And support tickets—not just the count, but the shape. A spike in tickets is information, but the type of spike is the actual message. A wave of “I can’t find my order” is a data or account-linking problem and it is urgent and it is fixable and it is probably not on fire. A wave of “checkout is broken” is a different animal entirely and it means someone in the war room should already be standing up. The volume tells you something is happening. The taxonomy tells you what.

There is a thing that happens to the bug list in the first two weeks that nobody warns the engineering lead about, and it is worth saying plainly so that it does not feel like failure when it arrives.

The bug list grows before it shrinks.

This is not a sign that the launch went badly. It is a sign that the launch is being operated—that real people are now using the thing in the tens of thousands of small unrehearsable ways that no staging environment and no dress rehearsal could have produced, and every one of those people is a fuzzer you did not have to pay. The list climbing in week one is the system telling you it is finally under real load. The teams that panic at a growing bug list make bad decisions—they start hot-fixing in production at midnight, reintroducing exactly the instability the freeze was designed to prevent, on the theory that a long list is an emergency. It usually isn’t. The discipline is to stockpile and prioritize: catch everything, write everything down, and then triage with a cool head into fix now, fix this week, and this is real but it can wait. A bug list is not a measure of how bad things are. It is a measure of how much you are seeing, and seeing more is good, even when it does not feel good.

Overhead view of a desk covered in overlapping blank sticky notes in various states of crumple and flatness, with one hand holding a pen poised mid-sort over the pile, and a cold coffee mug at the edge of the frame. — The list grows before it shrinks. Write everything down anyway.

Which brings us, at last, to the queue you have been so disciplined about not touching.

All through this book we have been telling you no. No to the wishlist that wanted to be a loyalty program. No to fixing the taxonomy on launch day. No to the while we’re at it that turns every migration into two migrations. The freeze, the change-as-few-things-as-possible, the park-it-in-the-backlog—the entire spine of the project’s discipline has been a long, patient series of deferrals, each one accompanied by a promise that the deferred thing would get its turn. The first weeks after launch are when that promise comes due, and keeping it is both a reward and a hazard.

The reward is obvious: you finally get to build the things you wanted to build, on a platform that is now stable enough to read what each change actually does. The hazard is subtler. The thing that made deferral safe was that you changed as few things as possible while the ground was moving. The ground is now mostly still—but “mostly” is the operative word in week one, and the temptation, having held the line so long, is to release the whole backlog at once the moment launch clears, which is just the old mistake wearing a party hat. You earned the right to make changes. You did not earn the right to stop watching what they do. So you let the backlog out slowly, one deliberate change at a time, each one shipped into a system stable enough that you can actually tell whether it helped—which is the entire reason you waited. What you defer matters as much as what you fix. What you un-defer, and how fast, matters just as much again.

There is one more transition in these weeks, and it is the one most likely to be fumbled, because it is organizational rather than technical and the engineers running the launch are not the people who own it.

At some point the people who built the thing have to hand it to the people who will run it. If the agency or the build team simply evaporates the week after launch—rolls off the contract, returns the laptops, sends a nice email—you have handed a live, month-old, still-settling system to a team that has never operated it, in the exact window when it is most likely to surprise them, and you have done it for the worst possible reason, which is that the calendar said the project was over. And if the agency stays forever, you have built a dependency that quietly guarantees the in-house team will never actually learn the system, because there is always someone else to ask.

Neither extreme is the answer, and the answer is the one this book keeps arriving at from every direction: the team that will operate the thing has to be brought inside the thing while it is still warm. Plan a graduated handoff—not week one, when everyone is too busy keeping the lights on to teach anyone anything, and not month six, when the knowledge has calcified into the heads of the people about to leave, but across the weeks in between, deliberately, with the in-house team taking the wheel on progressively larger pieces while the people who built it are still in the room to catch the swerve. This is the same lesson as the one about migrating the assumptions and not just the code, pointed at people instead of data. A system handed over without the understanding of how it works is a system that will be operated by superstition within the quarter. The handoff is not a date. It is a curriculum.

So here, at the end, is the part for one specific person.

You are the engineering lead. It is the second week. You are looking at the bug list, and the bug list is longer than it was on launch day, and a small cold voice in the back of your skull is wondering whether the whole thing was a mistake—whether you missed something fundamental, whether the green dashboards are lying the way the staging store lied, whether you are about to be the story someone tells in a later chapter of someone else’s book. You are tired in the specific way that only comes after months of pointing yourself at a single immovable date. And you are reading this paragraph at an hour you should not be awake.

Here is the only thing worth saying to you, and it is true: this is normal, and you will get through it. The list grows before it shrinks. The quiet failures surface on a delay because that is what quiet failures do, not because you failed to catch them. The standups feel like overkill right up until the morning one of them saves you. The exhaustion is real and it is also temporary, and the system you built is, right now, while you doubt it, quietly working—taking orders, serving pages, doing the unremarkable thing it will do every day from here forward until it is simply the store and no one remembers there was ever another one.

You did not reach the finish line. There wasn’t one. You reached the beginning, which is harder and better and the only place worth getting to. Launch is the beginning. Now go to sleep, and come back in the morning, because the standup is at nine and there might be something to decide.