TSA data migration has one hard deadline: the day the seller shuts the legacy system down. When a Transition Services Agreement (TSA) ends, the acquirer usually loses access to the seller’s legacy HR and payroll system at that same moment. And that’s not just data. Pay histories, benefits elections, signed offer letters, I-9s, personnel files: anything not pulled and archived beforehand is gone, along with the ability to answer for it later.
If you’re part of an Integration Management Office (IMO) running integration on a deal with a TSA attached, you already know the date. What you may not have mapped out is everything that becomes unrecoverable on that date, and what a complete TSA data migration requires to prevent it.
Key Takeaways
- A TSA’s expiration date is a hard cutoff. Once the seller decommissions the legacy system, the acquirer typically loses access for good.
- What’s at risk isn’t just payroll data. Pay history, benefits records, I-9s, offer letters, and personnel files can all become permanently unavailable.
- Post-TSA data requests usually require a new negotiation with the seller, if they’re honored at all. There’s no guarantee of a fallback.
- The fix is extraction and archiving before cutover, done independently of the HRIS the acquirer is moving to.
- Scoping extraction only to the system named in the TSA can miss related data sitting in other legacy platforms. The real data footprint is often wider than the agreement suggests.
What Is a Transition Services Agreement, and Why Does It Have a Hard Expiration Date?
A Transition Services Agreement (TSA) is the contract that lets an acquired entity keep using the seller’s systems. That can mean HR, payroll, IT, and finance systems, for a defined period after close, while the acquirer stands up its own infrastructure or completes integration. TSAs exist because most acquisitions can’t flip every system over on day one. Payroll has to run. Benefits have to stay active. Someone has to answer employment verification calls.
The expiration date is contractual, not flexible. Sellers price TSA services to cover a limited window, not indefinite support. They also have their own reasons to shut systems down on schedule: cost, liability, and their own IT sunset plans among them. Once that date passes, the seller has no obligation to keep the system running. In most deals, it has no obligation to keep your data accessible in it either.
This is why TSA end dates function less like a soft deadline and more like a data cliff. Everything you haven’t extracted by then, you may never see again.
What Employee Data and Documents Disappear When a TSA Ends?
It’s easy to think of this as a payroll problem. It isn’t. It’s a records problem, and the records span far more than compensation history. Depending on the legacy system, what typically sits behind a TSA includes:
- Pay and compensation history: pay stubs, wage adjustments, bonus and commission records, garnishment history
- Benefits records: enrollment elections, plan changes, dependent coverage, COBRA notices
- Employment documentation: offer letters, I-9s (which carry their own federal retention requirement), W-4s, performance reviews, disciplinary records, termination paperwork
- Time and attendance data: clock records, PTO balances, leave-of-absence documentation (FMLA, ADA, state leave)
- Tax records: W-2s, state withholding forms, unemployment filings
None of this data is optional to have on hand. Employment verification requests, wage-and-hour audits, unemployment claims, and litigation discovery can all reach back years. The IRS requires employment tax records to be kept for at least four years after filing, and other document types carry their own retention windows. The ability to answer for any of it doesn’t expire just because the system storing the records did.
Why Can’t Legacy HR Files Be Recovered Once the Seller Decommissions the System?
Because in most deals, the seller has no reason to keep the system alive, and often a contractual reason to shut it down. Once decommissioning happens, a few things tend to be true:
The system itself is gone.
No login, no export, no read-only access. The seller has retired the license, hosting, or hardware behind it.
The seller’s obligation ends with the TSA.
Post-expiration data requests usually require a new negotiation or a new fee. Some simply don’t get honored, since the seller has moved on to their own priorities.
Backups aren’t guaranteed to include what you need.
A seller may retain backups for their own compliance purposes, but those backups aren’t structured for your extraction needs. You may also have no contractual right to request them.
By the time most integration teams realize a gap exists, the system is already offline. There’s no support ticket that fixes a decommissioned server.
How Does TSA Data Migration Work Before Cutover?
A complete TSA data migration is straightforward in concept, even when the execution is not. Extract everything before the TSA clock runs out, and archive it somewhere the acquirer controls and can query independently of any active HRIS.
A few things matter regardless of which system you’re migrating from or to:
Inventory before you extract.
Most integration teams underestimate what’s actually stored in a legacy system until someone goes looking. Before extraction begins, get a full accounting of every data type and document category living in the system. Don’t rely on what payroll or HR assumes is there.
Extract data and documents separately, but completely.
Structured data (pay records, benefits elections, time entries) and unstructured documents (I-9s, signed forms, personnel files) often live in different modules within the same system. A migration plan that only covers one leaves the other behind.
Archive independent of the destination system.
Whatever HRIS the acquirer is moving to, the legacy archive shouldn’t be dependent on it. If the new system changes, gets replaced, or the acquirer later divests the entity, the archived records need to survive that too.
Preserve searchability, not just storage.
A dump of PDFs in a shared drive technically preserves the data but doesn’t make it usable. HR, legal, and compliance teams need to search and retrieve specific employee records on demand. That means for an audit, a subpoena, or a routine verification request, without reconstructing the original system.
Build in time for validation.
Extraction that runs right up against the TSA deadline leaves no room to confirm the data actually came through complete and accurate. Validate against source system counts before the access window closes, not after.
What Does a TSA Data Migration Look Like in Practice?
A global medical device manufacturer needed a TSA data migration for a single acquired entity. The request looked contained: migrate one entity’s payroll data ahead of a TSA deadline. The company brought it to ResNav.
The migration itself surfaced a bigger problem. As the extraction work got underway, it became clear the entity’s legacy data wasn’t isolated to the single system in scope. Related records existed across other platforms the integration team hadn’t fully mapped, with no consistent archiving plan behind any of them. What started as one migration became a company-wide look at legacy data exposure, well beyond the original TSA-driven request.
The lesson for other IMO teams: a TSA deadline on paper often names one system. The actual data footprint of an acquired entity is rarely that contained. Scoping the extraction narrowly to what the TSA explicitly covers can miss those records. Other systems get decommissioned on their own timelines, and by then, the same records are just as unrecoverable.
What Should Be on Your TSA Countdown Checklist?
- Confirm the exact TSA expiration date and work backward from it. Extraction and validation both take longer than expected.
- Inventory every system and data type the acquired entity’s legacy HR/payroll setup touches, not just the one named in the TSA.
- Separate structured data from unstructured documents in your extraction plan. Pay records and I-9s often live in different places.
- Confirm what the seller is and isn’t obligated to provide post-expiration, in writing, before you assume anything is retrievable later.
- Choose an archive that’s independent of your destination HRIS so the records survive future system changes.
- Build in a validation window before the TSA deadline, not after. Reconcile extracted records against source counts while you still have access.
- Loop in legal and compliance early on retention requirements, since what you’re required to keep may outlast what the TSA covers.
IMO Teams Stay Ahead of TSA Deadlines with ResNav
A TSA deadline doesn’t leave room for a second attempt. Once the seller shuts the legacy system down, whatever wasn’t extracted is gone. That gap tends to surface at the worst possible time: when legal, compliance, or a former employee comes asking for a record that no longer exists anywhere.
ResNav handles TSA data migration for IMO and integration teams. We extract and archive employee data and documents ahead of cutover, regardless of which legacy system it’s coming from or where it’s headed. That includes structured payroll and HR data as well as the personnel files and signed documents that often get missed in a narrowly scoped migration plan. The archive stands on its own: searchable, independent of your destination HRIS, and ready to produce a record on demand, long after the TSA has expired.
If you’re working against a TSA deadline, the time to map what’s at risk is before the countdown runs out, not after. Talk to ResNav about a pre-cutover data assessment.
Frequently Asked Questions
A TSA is a contract letting an acquired company keep using the seller’s systems temporarily after close. It has a fixed end date because sellers price and staff these services for a limited window, not indefinite support.
Pay and compensation history, benefits records, employment documentation like I-9s and offer letters, time and attendance data, and tax records can all become inaccessible once the legacy system is decommissioned.
Once the system is retired, there’s typically no login, export, or backup access available, and the seller’s contractual obligation to provide data usually ends with the TSA itself.
Inventory everything in the system, extract structured data and unstructured documents separately, archive independently of the destination HRIS, and validate the extraction before the TSA access window closes.
Confirm the expiration date, inventory all affected systems, separate data types during extraction, clarify the seller’s post-expiration obligations, choose a system-independent archive, and validate before access ends.