Launch Planning

Even when the pilot succeeds, moving to full volume in one step is risky. A phased launch, starting with a small percentage of traffic and increasing it in stages, both shows you how the system behaves under real load and limits the damage if something goes wrong.

A concrete example: a phased launch schedule usually runs like this. Ten percent of traffic in the first week; thirty percent in the second week if the agreed criteria are met; one hundred percent across the third and fourth weeks. The critical point is that moving to the next stage depends on criteria rather than the calendar. Is the error rate below the agreed threshold, is the escalation rate stable, are customer complaints not rising? If the answer to those questions is not yes, you do not move to the next stage. You stay at the current percentage.

A launch plan has to define two things clearly and in writing. First, who makes which decision: who is responsible, who approves, who is consulted, who is informed. That distribution of ownership is usually written as a RACI. Second, how quickly the rollback process will run when something goes wrong. "We've gone live, we'll look at it if there's a problem" is not acceptable at enterprise scale. The rollback plan has to be as clear as the plan to move forward, and it has to have been tested beforehand.

A common mistake: tying progress to time rather than to data. "A week has passed and nothing major has gone wrong, let's continue" does not show that the criteria were met. It may only show that nothing has been noticed yet. A healthy launch moves on the question "which thresholds were met" rather than "how much time has passed".