Run the seller's IT off your stack. Without losing your stride.

Why a buyer ends up providing IT. The acquired stack ran the seller too.

Reverse IT shows up most often when the buyer acquires a business unit whose IT platform also served the seller's other divisions. The platform, the identity store, the warehouse, the file shares, the support desk, all of it sat inside the carved-out perimeter. The seller cannot rip the platform out of the buyer's environment because the seller never had a separate copy. The only way to give the seller continuity is for the buyer to keep providing the services until the seller stands up its own.

This is the moment most buyers underprice. The deal team assumes the seller will move quickly to its own infrastructure. The reality is that seller IT projects slip. Without a priced extension mechanism and a defined catalog, the buyer carries the seller's IT for longer than planned, at the original price, with no compensation for the operational drag.

The buyer side advisor treats the reverse IT scope as a commercial product, not a favor. Each service in the catalog has a price, a service level, an exit milestone, and an extension fee curve. The buyer's IT organization becomes a temporary internal vendor to the seller with terms that protect Newco capacity.

The TSA needs to make this explicit before signing. Sellers will resist explicit pricing for reverse services because the seller wants flexibility on duration. The buyer holds the line because the alternative is unbounded operational exposure. The pre signing window is the only place this gets fixed cleanly. The work pairs with the reverse TSA primer.

The five service categories. Catalog the scope before pricing it.

Reverse IT scope falls into five categories. First, infrastructure hosting. Buyer runs the data center, cloud tenancy, or hybrid environment that hosts the seller's residual workloads. Second, identity and access. Buyer maintains accounts, directory entries, and federation for seller users who still touch buyer systems. Third, applications. Buyer continues to operate specific systems (ERP, CRM, data warehouse, BI) on behalf of the seller until the seller cuts over. Fourth, end user support. Buyer's help desk fields seller tickets where the user community spans both entities. Fifth, network and security. Buyer provides connectivity, monitoring, and incident response for shared paths.

Each category has a different risk profile. Infrastructure hosting is the easiest to price because the underlying costs are well documented. Application services are the hardest because the operational burden depends on the application's stability, the user volume, and the seller's appetite for change. The catalog needs to call each one out separately so the price and the exit milestone reflect the actual work.

The catalog should also distinguish between maintenance and enhancement. The buyer commits to operating the existing scope. The buyer does not commit to adding features, deploying new releases, or supporting new user populations the seller introduces during the reverse TSA period. The boundary is documented in the catalog so the buyer can decline scope creep without renegotiating the entire agreement.

The buyer side advisor walks the seller through the catalog line by line during pre signing. Where the seller wants a service that the buyer cannot reliably deliver, the catalog calls it out as excluded. Where the seller wants a service the buyer can deliver but at significant cost, the catalog prices it specifically. The work pairs with reverse TSA service catalog design.

Pricing reverse IT. Cost plus, with the right mark-up.

Reverse IT pricing follows the same cost-plus framework as a normal IT TSA, with the direction reversed. The buyer documents the fully loaded cost of the service. Direct headcount, third-party licenses, allocated infrastructure, and a defensible share of overhead. The mark-up sits on top of that base.

Market mark-up ranges for reverse IT typically run 5 to 15 percent. Routine hosting and support land near the low end. Specialist application operations and scarce technical capacity land higher. Anything above 15 percent should be reserved for services where the buyer is genuinely diverting strategic capacity (key engineers, dedicated platform teams) and where the documentation supports the higher rate.

Pass-through is the cleaner mechanism for third-party costs (software licenses, cloud spend, vendor support contracts). The buyer charges actual cost without mark-up. The seller pays the underlying invoice through the buyer. The buyer side advisor structures pass-through with clear audit rights so the seller can verify the costs match the actual third-party billing.

The pricing schedule should anticipate volume sensitivity. Some IT services scale linearly with users or workloads. Others are step functions where capacity has to be reserved regardless of utilization. The schedule should specify whether pricing flexes with volume or stays fixed across the term. The work pairs with reverse TSA pricing models.

Service levels and operational defense. Buyer commits to documented levels only.

The buyer commits to the service levels the seller actually experienced before close. Not to higher levels the seller wishes it had. The catalog should document the historical service levels for each line and bind the reverse TSA commitment to those same numbers. Where the seller wants better than historical, the cost-plus mechanism prices the uplift explicitly.

Service credits in a reverse TSA are usually capped at a percentage of monthly fees. The buyer side advisor caps the seller's remedy because the buyer's operational exposure cannot scale without limit. The cap is typically 10 to 20 percent of the affected month's fees. Anything material beyond that runs through the dispute mechanism rather than the service credit mechanism.

The buyer should reserve the right to operational priority for Newco's own workloads. If a system the buyer is providing to the seller fails simultaneously with a buyer workload, the buyer's incident response addresses Newco first. The catalog documents this priority so the seller cannot claim service breach when the buyer's own operations took precedence during a multi system incident.

Change windows and maintenance schedules should also align with Newco's operating cadence, not the seller's. The buyer is the host. The seller adapts to the buyer's maintenance windows. The catalog should explicitly note this. The work pairs with reverse TSA risk allocation.

Identity, data, and the security boundary. The cleanest boundary wins.

Reverse IT raises a security boundary problem on Day One. The seller's users may still authenticate against the buyer's identity store. The seller's data may still sit on the buyer's storage. The seller's traffic may still cross the buyer's network. Each of these creates a vector where a seller event becomes a buyer problem. The catalog needs to document where the boundary sits and how it is enforced.

The buyer should aim to migrate the seller off shared identity within the first 90 days where feasible. Joint authentication is operationally convenient but legally messy. A breach on the seller side that propagates through shared accounts becomes a buyer liability. The catalog should specify the migration path and the date by which shared identity ends.

Data separation is similar. Where the seller's data sits on buyer storage, the catalog should specify the encryption, access controls, and audit logging that protect the boundary. The seller's data should be logically separated from Newco's data even where physical separation is impractical. The buyer side advisor pressure-tests the separation during scoping because retrofitting controls after Day One is hard.

Network paths between buyer and seller environments should be minimized. The catalog should list every active path, the purpose, and the planned termination date. Open ended cross network connectivity is the most common source of post close security findings. The buyer side advisor closes paths aggressively as the seller stands up its own connectivity. The work pairs with the Day One cybersecurity playbook.

Exit milestones for reverse IT. The schedule has to be enforceable.

Reverse IT services should have explicit exit milestones in the catalog. Identity off by month 3. Application services off by month 9. Infrastructure off by month 12. Network paths terminated by month 15. The schedule sets the expectation and gives the buyer something to enforce through the extension fee curve and the hard exit date.

Each milestone should specify the technical artifacts that prove completion. Migration certificates from the seller's new identity provider. Confirmation that seller workloads have been removed from buyer infrastructure. Network audit showing severed connections. The catalog needs to define what done looks like so completion is verifiable rather than asserted.

The buyer should also reserve the right to enforce the milestones through service degradation. After the milestone date, the buyer can stop providing the service even if the seller has not completed its migration. The right is calibrated. Aggressive enforcement risks operational disruption to the seller and a counter claim. Reasonable enforcement preserves the buyer's schedule. The buyer side advisor drafts the right with notice periods and escalation gates so enforcement is defensible.

Reverse IT work is delivered under a Fixed Fee or Portfolio Retainer engagement. The Fixed Fee engagement covers a single reverse TSA from pre signing through Day One. The Portfolio Retainer covers PE platforms running multiple reverse IT arrangements across their portfolio. The buyer side advisor scopes the work during diligence and delivers a fixed-fee proposal within 48 hours of intake. The work pairs with reverse TSA exit strategy.

More on reverse TSA.

The TSA negotiation pillar covers the clause and pricing mechanics behind every reverse TSA. Corporate buyers face the same dynamics from the provider side.