Why the freeze exists, and what it hides
The four-week freeze is almost always a tell. It says that the data migration is one-shot, that the integrations cannot run in parallel and that the test plan needs the codebase to stand still for the QA team to catch up. None of those are launch problems. They are architecture problems being deferred to the last month of the project.
Once the freeze is in the plan, it becomes load-bearing. Marketing campaigns get scheduled around it. The ops team accepts that a category rebalance will have to wait. Engineering stops merging anything that is not strictly migration work. The cost of all of that is invisible until you try to remove it, at which point everyone in the room has built a contingency that depends on it.
Continuous migration, in practical terms
Continuous migration means three things, and you need all three.
First, data sync runs in both directions for as long as you need it to. Catalogue, customers, prices, orders and stock move across the boundary on a schedule the operations team can verify. Most teams build this badly because they treat it as a launch tool rather than an operating tool. Build it as if it has to run for six months, because it probably will.
Second, the new front end is deployable independently of the platform launch. Routes are switched at the CDN, not at the database. That means the new storefront can serve a category, a brand or a single product before the wider switch. It also means you can roll back at the route level, which is the only kind of rollback anyone trusts during launch week.
Third, the test plan is automated against the parallel environments. Order placement, account creation, contract pricing and stock reservation all run on a synthetic schedule against both platforms. When the numbers diverge you find out on a Tuesday morning, not in the launch retrospective.
"A freeze does not pause risk. It stores it up and hands it to the launch team in one piece."
Phased launch, in the order it actually happens
A phased launch is not a soft launch. It is a deliberate sequence of small switches, each one reversible, each one with an owner.
Start with the lowest-risk traffic. Internal users, a single small brand, or a region that the business can afford to be wrong about for a day. Move trade accounts last, because trade accounts are the hardest to roll back without a phone call to a finance team you would rather not make.
Hold the order-management launch until the storefront has been stable for at least two full operating cycles. The order book is the part of the system finance cares about, and the part that is hardest to reconcile if anything goes sideways.
What to negotiate with the business now
The conversation to have with the steering committee is not whether to freeze. It is what the business is willing to commit to for the migration to be continuous. That usually means accepting a slower feature cadence during the run-in, agreeing a single owner for the parallel data plane, and giving engineering the authority to refuse changes that put either platform out of sync.
Most projects fail this conversation because it happens too late, after the freeze has already been priced in. Have it at the start. If the business will not agree to it, the four-week freeze is the right answer, and you have at least chosen it rather than inherited it.
