TSA Exit Acceleration
Exit on evidence, not on a date.
Senior operators on day one. Fixed-fee engagements. The first conversation is always free.
TSA data migration validation is the work of proving that data moved off the seller's systems completely and correctly before you switch the service off. Skip it and you discover the gaps in production, on Day One, with no fallback. It is the least glamorous and most decisive control in any TSA exit strategy.
Every TSA exit that touches data rests on one question: did the data actually move, all of it, correctly. It is easy to copy records from a seller system to yours. It is hard to prove that every record arrived, that none were corrupted, and that the data means the same thing in the target as it did in the source. Validation is the discipline that answers that question with evidence rather than optimism.
The reason it matters so much is the asymmetry of failure. A migration that is ninety nine percent correct sounds excellent and is operationally a disaster, because the missing one percent is customer balances, open orders, or payroll records that surface as broken processes the moment you go live. There is no partial credit for a data migration. It either supports the business on Day One or it does not.
Validation is also your last clean exit point. Once you cut the seller's service, the source of truth is gone or frozen, and fixing a discovered gap means going back to a counterparty you have just left. Proving correctness while the seller system is still live, and still your fallback, is the difference between a controlled exit and a crisis. The work belongs before the cut, not after.
Validation needs a framework, not ad hoc spot checks. The framework defines, for every data set in scope, what correct means: how many records should move, what totals must match, which fields are critical, and what tolerance, if any, is acceptable. Without that definition stated in advance, validation becomes a matter of opinion after the fact.
Work at more than one level. Count reconciliation confirms that the number of records in the target matches the source. Value reconciliation confirms that totals, balances, and sums agree. Field level checks confirm that critical attributes carried over intact rather than arriving truncated, reformatted, or mapped to the wrong column. Each level catches a different class of error, and a migration can pass one while failing another.
Define the framework before the migration, not after. Agreeing the reconciliation rules up front forces the hard conversations about what the data means and what correct looks like while there is still time to act on them. It also turns validation from a subjective review into an objective test the migration either passes or fails, which is exactly what you want standing between you and a service cut.
Timing is the heart of good validation. The only safe moment to prove a migration is while the seller system is still running, because that system is both your source of truth and your fallback. Validation done after the cut is not validation, it is incident response. The plan must build in a window where data is in the target, the seller service is still live, and the reconciliation runs against both.
Use that window deliberately. Run the full reconciliation framework against the migrated data, investigate every exception, and confirm that critical processes work on the target with real data before anything is switched off. A parallel period, where both systems run and outputs are compared, gives the strongest assurance for high stakes data such as finance and payroll, where a silent error is intolerable.
Only cut when the evidence supports it. The decision to switch off the seller service should rest on a completed reconciliation, resolved exceptions, and tested processes, not on a date in a plan. If validation is not clean, the right move is to hold the seller service and fix the data, even at the cost of an extension fee. The fee is cheaper than a broken Day One.
Certain data failures recur across carve-outs, and they share a habit of hiding until production. Records filtered out by a mapping rule that was slightly wrong. Fields silently truncated because the target column was shorter. Encodings that turned valid characters into nonsense. Duplicate records created when a migration ran twice. None announce themselves. All surface as broken business processes later.
The most dangerous failures are the ones that pass a naive check. Counts can match while values are wrong. Totals can agree while individual records are scrambled. A migration can look clean at the summary level and be broken in the detail, which is why layered reconciliation matters and why someone has to look below the headline numbers at the data that actually drives operations.
Reference and configuration data deserve special suspicion. Teams focus on the obvious transactional records and overlook the lookup tables, mappings, and settings that make those records meaningful. A perfectly migrated transaction is useless if the reference data that interprets it did not come across. Validate the supporting data with the same rigor as the headline data, because the business depends on both.
Validation has to end in a decision, and that decision belongs in a formal gate. Before any service is cut, a defined owner reviews the reconciliation results, the exception log, and the process tests, and signs off that the data is complete and correct enough to operate on. That sign off is the record that the cut was made on evidence, not on schedule pressure.
Make the gate honest by giving it the power to say no. A gate that always approves because the date has arrived is theater. The reviewer must be able to hold the cut, keep the seller service running, and send the data back for correction when the evidence is not there. Protecting that authority is what makes the whole validation effort mean something.
Keep the evidence after the cut as well. The reconciliation outputs and sign off form the proof that the migration was sound, which matters when a question surfaces weeks later or an auditor asks how you knew the data was right. A buyer who validates rigorously and records the result exits with confidence. Building that gate into the plan is central to our TSA Exit Acceleration approach.
It is the work of proving, with evidence, that data moved off the seller's systems completely and correctly before you switch the seller service off. It combines count, value, and field level reconciliation with process testing, and it happens while the seller system is still live so that system remains your fallback if the data is not right.
Because the seller system is both your source of truth and your fallback. Once it is switched off, fixing a discovered gap means returning to a counterparty you have just left, with the original data gone or frozen. Validating while the service is still live lets you hold the cut and correct the data, turning a potential crisis into a controlled decision.
The ones that pass a naive check: counts that match while values are wrong, fields silently truncated, encodings corrupted, duplicates from a migration that ran twice, and reference or configuration data left behind. Summary numbers can look clean while the detail is broken, which is why layered reconciliation and a look below the headline totals are essential.
A review of the reconciliation results, the exception log, and the process tests, ending in a sign off by a defined owner that the data is complete and correct enough to operate on. The gate must have the authority to hold the cut and keep the seller service running if the evidence is not there. Keep the evidence afterward as proof the migration was sound.
Scripting the reconciliations and reports that slow an exit.
Read the article →Where machine assistance compresses a separation, and where it does not.
Read the article →Transferring security controls cleanly as the TSA ends.
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 →
Senior operators on day one. Fixed-fee engagements. 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.
One tactic, one benchmark, or one pattern from a recent buyer-side engagement. Short. Signal heavy. Free.
Subscribe to The Day One Letter →