A big-bang cutover has a specific shape: months or years of build, a single scheduled weekend, and then the old system goes dark while the new one takes every transaction the business has. There is no fallback window worth the name, because "fallback" on a big-bang plan means re-pointing the entire enterprise back to a system that was just decommissioned, its interfaces unwound, its batch schedules stood down, its operators reassigned. The plan calls this go-live. What it actually is is a single roll of the dice, made once, for the whole business, after the vendor has already been paid most of the contract value.
The alternative — running old and new in parallel, cutting over module by module or population segment by segment, keeping a real rollback path alive until parity is proven in production — is slower and looks less impressive on a project timeline. It is also the only structure where a mistake costs a bounded amount instead of the whole company's operating capacity for a day, a week, or the month it takes to reconstruct what happened. Big-bang cutover isn't chosen because it's safer. It's chosen because it's cheaper to build and easier to sell as a milestone: one date, one press release, one line in the vendor's case study.
Who actually holds the risk
The asymmetry is the part that doesn't make it into the statement of work. The vendor's risk on cutover weekend is reputational and, at most, contractual — a penalty clause, a bad reference, a renegotiation. The buyer's risk is operational and immediate: payroll that doesn't run, claims that don't pay, settlements that don't clear, a call center with no working case history, on a Monday morning with customers, regulators, or both watching. The vendor walks away from a failed cutover with a war story. The buyer walks away from a failed cutover with an incident report, possibly a breach of a service obligation to its own customers, and a board asking why the fallback plan was "revert to the old system" when the old system had already been dismantled.
This is why the sales conversation almost never surfaces the real question, which is: when this goes wrong at 2am on cutover weekend, whose problem is it, and for how long? A vendor confident enough to answer that question honestly, with a specific rollback mechanism and a specific time-boxed decision point, is worth listening to. A vendor whose answer is some version of "it won't come to that, we've done this before" is telling you they haven't priced the tail risk, because they don't carry it.
What a bounded cutover actually looks like
The engineering discipline underneath a safer cutover isn't exotic. It requires that the new system's behavior on a given population segment has already been proven, byte-for-byte, against production data before that segment is switched — not demoed against sample data months earlier, proven against the specific records that will be live the moment the switch flips. It requires a genuine rollback path: the old system kept operable, its batch and interface schedules intact, for a defined window after each incremental cutover, so reverting a segment is a decision that can be made and executed in hours, not a hypothetical nobody actually tested. And it requires cutting over in pieces small enough that a bad piece is a bounded incident, not an enterprise-wide one — one product line, one region, one population segment at a time, each one validated before the next one moves.
None of that is a novel idea. It's how any competent systems migration has always been run when the people running it were the ones who'd answer for a failure. Big-bang cutover reappears specifically on projects where the party proposing the timeline isn't the party who inherits the outage.
The question that exposes a cutover plan isn't "when do we go live." It's "what happens at 2am when the numbers don't match, and who is on the hook for the next twelve hours."
What to ask before you agree to a date
A buyer evaluating a cutover plan should ask for the rollback mechanism in writing, with a specific time limit on the decision to revert, before agreeing to a single go-live date for anything that can't be un-done in hours. Ask whether the old system stays operable, and for how long, after each cutover step — if the answer is that it's decommissioned on go-live day, the plan has no fallback, whatever the deck calls it. Ask how the population being cut over was chosen, and whether that segment's data has already been proven against the new system on real production bytes, not synthetic test cases. And ask, plainly, what the vendor's exposure is if the cutover fails versus what the buyer's exposure is — if those two answers aren't close to symmetric, the vendor priced this cutover for their own risk, not yours.
A phased cutover with a real rollback path costs more calendar time and more coordination effort than a single weekend event. It also converts an enterprise-wide bet into a series of smaller, provable, reversible ones — which is the entire point of demanding proof before commitment instead of a promise with someone else's name on the risk.