Multi TSA Portfolio
A cutover that runs to plan.
Fixed-fee proposal in 48 hours. Senior team on day one. The first conversation is always free.
A TSA cutover runbook is the step by step plan that runs the exit on the day, with every action owned, timed, and validated. The buyer who builds and rehearses a real runbook executes a cutover that has already been proven, rather than discovering the gaps live at two in the morning. The runbook is where day one readiness turns from a plan on paper into a sequence the team can actually run.
The cutover is the moment a TSA exit becomes real: the seller's service goes off, the buyer's replacement goes on, and the operation has to keep running across the seam. It usually happens in a narrow window, often overnight or over a weekend, with little room for error and no appetite for improvisation. The runbook exists so that nobody on the team has to think on their feet during that window. Every decision that can be made in advance has been made.
A runbook is not a project plan and not a checklist. A project plan tracks the weeks of preparation. A checklist is a flat list of things to confirm. The runbook is the choreography of the cutover itself: an ordered sequence of actions with owners, times, dependencies, and validations, written at a level of detail where a competent operator could execute it without needing to ask what comes next. The detail is the point, because detail is what removes improvisation.
The runbook also serves as the single source of truth during the cutover. When a dozen people across several workstreams are acting in parallel under time pressure, the runbook is what keeps them coordinated: each person knows their steps, their timing, and what must finish before they begin. Without that shared script, a cutover becomes a series of phone calls asking whether it is safe to proceed, and those calls are where the window gets lost.
A runbook step is more than an instruction. Each step carries a clear action stated as a single thing to do, a single named owner who performs it, a planned start time and an expected duration, and the step or steps it depends on. Without the owner, a step belongs to everyone and therefore to no one. Without the timing, the team cannot tell whether the cutover is on schedule or quietly slipping toward the end of the window.
The element teams most often omit is the validation: the explicit check that confirms a step actually worked before the next step depends on it. A step that switches a feed over should be followed by a step that confirms data is flowing through the new feed, not an assumption that it must be. A step without a validation can fail silently, and the failure surfaces hours later as a downstream problem whose cause is now buried under everything done since. Validations catch the failure where it happened.
Write the steps in the order they must run and make the dependencies explicit, because the sequence is where cutovers go wrong. A step that depends on a migration finishing cannot be scheduled before the migration's validation passes, and recording that link stops the team starting a step whose predecessor is not yet done. The dependency mapping done earlier in the program feeds directly into this ordering, so the runbook should reflect the same critical path the rest of the plan was built on.
A runbook that has never been rehearsed is a hypothesis. The rehearsal, a dry run of the cutover against a test environment or a walkthrough of every step with the people who will run it, is where the runbook earns trust. Rehearsal finds the steps that are wrong, the steps that are missing, and the steps that are in the wrong order, and it finds them while the cost of finding them is a revision rather than an outage.
The most valuable thing a rehearsal reveals is timing. On paper a cutover always fits the window. In rehearsal the team discovers that a migration step takes three hours rather than the assumed one, and that the sequence as written runs past the deadline. Finding that in rehearsal lets the team re sequence, parallelize, or negotiate a longer window before the live event. Finding it live means choosing between an unfinished cutover and a service that comes back up late.
Treat the rehearsal as a gate in its own right. A successful dry run is strong evidence at the readiness gate that the cutover can be executed, and a failed dry run is exactly the signal the program wants before committing to the live date. Update the runbook from what the rehearsal teaches, then rehearse the changed sections again if they were significant, so the version executed on the day is the version that has actually been proven to work.
Every cutover runbook needs a rollback plan, because some cutovers fail and the operation still has to be working on Monday morning. The rollback is its own set of steps that returns the operation to the pre cutover state, and it deserves the same owners, timing, and validations as the forward plan. A rollback sketched as a one line intention is not a rollback; it is a hope that nothing goes badly enough to need one.
The rollback hinges on a decision point with a deadline. At a defined moment in the window the team must decide whether the cutover is succeeding well enough to go forward or whether it must back out, and that decision has to be made with enough time left to execute the rollback before the service has to be live again. A rollback decided too late is no rollback at all, because the window to reverse has already closed and the team is committed to a cutover that is not working.
Name who makes the go forward or back out call before the cutover starts, and base it on the validations rather than on nerve. The decision should rest on objective criteria: which steps passed their checks, which failed, and whether the failures are recoverable in the time remaining. Deciding this in advance, against the runbook's own evidence, keeps the most consequential moment of the cutover from being made on adrenaline at the worst possible time.
On the day, run the cutover from the runbook and track progress against it in real time. A cutover lead works the runbook step by step, confirming each validation and recording the actual time against the plan so the team can see whether they are ahead or behind. That live tracking is what lets the lead spot a slip early enough to act, and it feeds directly into the go forward decision when the decision point arrives.
Hand the runbook off cleanly into the support window that follows. The cutover ends but the operation is new and fragile, and the hypercare team needs to know exactly what was done, what was validated, and what was left for follow up. The completed runbook, annotated with actual times and any deviations, is the record that tells the support team where to look first when something behaves oddly in the days after go live.
Keep the runbook as a reusable asset rather than discarding it after the cutover. The structure, the validations, and the rollback approach are transferable to the next service exit and the next carve-out, and a portfolio that builds each runbook from the last one starts further ahead every time. Feeding the lessons from each cutover back into the template is how a buyer turns a one time scramble into a repeatable operating capability.
It is the detailed, step by step plan that runs a TSA exit cutover. Each step has an owner, a start and end time, a predecessor, and a way to confirm it succeeded. The runbook turns a cutover from an improvised scramble into a sequence the team executes and tracks.
A clear action, a single owner, a planned time and duration, the step it depends on, and a validation that confirms it worked before the next step starts. A step without a validation is a step that can fail silently and surface as a problem hours later.
Because a rehearsal finds the steps that are wrong, missing, or in the wrong order while the cost of finding them is low. A dry run exposes timing that does not fit the window and dependencies the team missed, so the live cutover executes a plan that has already been proven rather than one being tested for the first time.
The rollback plan is the part of the runbook that returns the operation to a working state if the cutover fails. It needs its own steps, its own decision point, and a deadline by which the team must commit to going forward or backing out, because a rollback decided too late is no rollback at all.
The sequence the runbook has to honor, step by step.
Read the article →How the call to run the cutover gets made before the runbook starts.
Read the article →Where the completed runbook hands off after go live.
Read the article →The 90-day governance, IT, finance, HR and procurement separation plan we run on live carve-outs. Get the playbook plus the bi-weekly Day One Letter — short, signal-heavy, buyer-side.
No spam. Unsubscribe in one click. · Read the overview first →
Fixed-fee proposal in 48 hours. Senior team on day one. The first conversation is always free.
Seven buyer-side moves to exit a Transition Services Agreement on time and below budget. The mark-up, the extension-fee curve, exit sequencing, and the 11-month calendar.
A representative $48M-revenue carve-out lists fourteen services in its TSA. When the catalog is vague — scope by reference, exclusions unstated, exit terms set only at the master-agreement level — the same estate drifts to $6.8M over twelve months. Pinned to the per-service template below, it runs to $5.1M in nine.
One tactic, one benchmark, or one pattern from a recent buyer-side engagement. Short. Signal heavy. Free.
Subscribe to The Day One Letter →