One-time IT cost is where deal models become optimistic without anyone changing a number. Separation programs, platform migrations, and security uplifts often get placed in project buckets, while new service desks, cloud bills, licenses, and support teams are left out of the steady-state view.
The reverse error is just as common. Treating every post-close IT expense as run-rate makes the target look permanently expensive, even when part of the cash is for a finite migration or a one-off license true-up.
The decision is not an accounting label. It is:
Which technology costs leave once, which costs repeat, which savings have a real exit condition, and when does the buyer actually own each of them?
That answer changes the purchase-price bridge, the first-year EBITDA case, the funding request, TSA terms, and the date on which an IT synergy can be counted. A credible model has a visible bridge from reported cost to owned run-rate, with one-time cash and timing risk shown separately.
Why the classification changes the deal
The same activity can have three economic effects.
- Data extraction may be one-time cash, but the operating model may need a new data platform and an analyst to operate it every month.
- A tool retirement may create run-rate savings, but only after users move, data is retained, interfaces are removed, and the old contract is terminated.
- A TSA may be recurring while it is active, then disappear when the buyer builds a replacement service. The replacement often creates both a new run-rate and one-time exit cash.
If those effects are collapsed into one “IT investment” line, the model loses the path from close to steady state. Finance cannot tell whether a margin improvement is sustainable. The program team cannot tell what must be delivered before a saving is real. The deal team cannot tell whether a TSA extension is a timing issue or a permanent cost reset.
The core outputs should be kept distinct:
- One-time cash: finite work required to stand up, separate, migrate, remediate, or retire technology.
- Run-rate cost: recurring people, contracts, licenses, hosting, support, and control work required after the program ends.
- Run-rate savings: recurring cost removed after the relevant service, system, contract, or role is actually retired.
- Timing: the month or quarter when each cost or saving starts, ends, or changes.
- Contingency: known uncertainty that has a named trigger, owner, and release rule.
The first four belong in the base model. Contingency belongs in the funding decision even when it does not belong in the EBITDA case yet.
Start with the cost the buyer will own
Reported IT spend is a starting point, not the answer. It may exclude parent services, business-owned applications, contractors, cloud credits, capitalized implementation work, and controls that have been deferred. It may also include group platforms or corporate allocations that will not transfer.
Build the baseline from actual cash and service ownership. Request:
- the last 12 months of IT actuals by vendor, cost center, employee, contractor, and capital or operating classification
- the current forecast and budget with the assumptions that changed between them
- vendor contracts, renewal dates, minimum commitments, user tiers, termination rights, and change-of-control terms
- cloud and SaaS usage, including credits, commitments, non-production environments, and business-owned subscriptions
- parent-provided services and the allocation method for identity, network, security operations, ERP, service desk, hosting, and data platforms
- active projects, deferred remediation, and work being performed by people coded as business, product, or transformation staff
Then label each line by service, not only by accounting code. “Software” is too broad. “ERP support for finance close,” “endpoint management,” and “customer analytics hosting” can be tested against a target operating model. Costs without service owners are not ready for an underwriting decision.
The five tests for every cost line
Run each material line through five tests. They prevent a project label from hiding the cost that survives after go-live.
1. Does the activity repeat?
If the work, invoice, or role recurs after the program ends, it is run-rate even if the first payment is inside a project budget.
Recurring categories include:
- application support after a migration
- security monitoring and identity administration
- cloud compute, storage, backup, and observability
- software subscriptions and recurring vendor support
- data stewardship, reporting operations, and compliance testing
Implementation partner cost is one-time when its statement of work ends at acceptance. Managed services that remain responsible for production support are run-rate. The contract and the target operating model, not the purchase order title, decide the treatment.
2. Does the buyer need the capability after cutover?
If the system changes but the capability remains, the cost has moved rather than disappeared. New ERPs still need functional support. Separate identity tenants still need administrators. Data migration still leaves retention, quality, and access obligations.
This catches false savings. Retiring a parent platform may remove an allocation while adding a smaller vendor, internal roles, and security tooling. Model the replacement before claiming the gross saving.
3. Is there a real exit condition?
One-time treatment needs a finish line that can be evidenced. “Transformation complete” is not a finish line. Use an acceptance condition such as:
- the legal entities operate on the target ERP and the prior instance has no production users
- the old identity tenant has no active accounts or privileged paths
- the TSA service is terminated and the replacement service has passed the agreed control tests
- the legacy contract is terminated, and its data-retention obligation has been recorded
Until the exit condition is met, the cost remains part of the current run-rate or an explicit temporary run-rate. Project plans do not retire services. Invoices, access records, contract notices, or production shutdowns do.
4. Who pays, and who benefits?
Separate buyer-owned cost from seller cost, shared cost, and value-creation investment. Seller funding for data extraction does not change ownership of the new environment. Corporate allocations can absorb a group security platform before close, while a standalone company must pay for it after close.
This test is especially important in a carve-out. The parent allocation is not the buyer’s standalone run-rate, and the TSA fee is not the full exit cost. Show the current allocation, TSA charge, replacement run-rate, and one-time exit work as separate lines.
5. Is the amount fixed or volume-sensitive?
Recurring costs can be variable rather than fixed. Cloud consumption, user-based licenses, transaction fees, storage, and support tiers may change with revenue, headcount, sites, or data volume. Treating these as a flat annual amount creates a false margin improvement when the business grows.
The model should identify the driver and the unit: users, transactions, environments, locations, devices, suppliers, or terabytes. If the driver is not known, call it out as a model gap rather than burying it in contingency.
Build the bridge in five layers
The cleanest model is a bridge from reported cost to target-state ownership. Each layer answers a different question.
Layer 1: reported baseline
Start with actual cash paid and reconcile it to the budget. Explain capitalization, internal allocations, credits, and costs outside IT. This is the evidence layer, not the target-state view.
Layer 2: normalize the current service
Add recurring work that keeps the business operating but sits outside IT: plant systems support, CRM administration, reporting analysts, product infrastructure, contractors, and managed services booked under operations. Remove group services or costs that will not transfer.
The output is a normalized current run-rate. It should explain the services the target consumes today before any deal work starts.
Layer 3: add one-time work packages
Estimate finite work bottom-up. For each package, show scope, deliverable, timing, internal effort, external effort, licenses or hardware, testing, contingency, and an acceptance condition.
Common packages include:
- legal-entity and tenant setup
- identity, network, endpoint, and security separation
- ERP or application extraction, replication, and interface rebuild
- data profiling, cleansing, migration, and reconciliation
- new vendor onboarding and contract exit
- TSA transition and knowledge transfer
- cutover rehearsal, hypercare, and decommissioning
Do not call an entire workstream one-time. Implementation is often one-time; the service it creates is usually not.
Layer 4: target-state run-rate
Price what remains after the work package closes. Use contracts, job descriptions, cloud usage, support volumes, and the target operating model. Include licenses, hosting, managed services, internal FTEs, cyber controls, backup, audit, and data operations.
Where the future service is not selected, model the capability rather than pretending it is free. “New identity platform” should carry administration, support, licensing, logging, and renewal assumptions.
Layer 5: savings, offsets, and stranded cost
Show gross removals and the costs needed to obtain them. Vendor retirement is not a saving until the termination right is exercised and replacement capability is live. Headcount reduction is not a saving if contractors are added to cover the same work. Shared-service removal may strand parent cost that the seller cannot actually eliminate.
The bridge should read as:
normalized current run-rate + target-state run-rate adds − verified retirements = owned steady-state run-rate
one-time work packages + temporary TSA or dual-run cost = funding requirement
Keep the bridge simple enough that the CFO, CIO, and program lead can challenge the same lines in the same meeting.
The cost classifications that usually fail
“All migration cost is one-time”
Migration is finite. The environment created by migration is not. Teams also forget dual-running, reconciliation, user support, and retention. If the old platform remains available for a close cycle or a contractual retention period, model that temporary cost with an explicit end date.
Decision trigger: If the new service has no named owner, support model, or renewal assumption, do not approve a one-time classification. The target state is not defined.
“The TSA is the run-rate”
TSAs are temporary supplier relationships, not necessarily the operating model. They can be below standalone market cost, exclude project work, and escalate after an initial term. Compare TSA cost with replacement run-rate and exit cash.
Decision trigger: If a TSA covers finance, payroll, identity, security, or customer operations beyond the proposed exit date, put its extension cost and seller project support in the base case until an exit gate is funded and tested.
“Synergy starts when the contract is marked for termination”
The saving starts when the contract stops charging, the users are off the service, and the replacement works. Renewal timing can make the saving timing-sensitive. Minimum commitments can make it unavailable for a full term.
Decision trigger: If the saving depends on a renewal or termination window, tie the model start date to the notice period and contract evidence, not the integration milestone.
“Internal people are free capacity”
Internal staff assigned to separation or integration still have a cost. If their operating work is backfilled, the backfill belongs in the one-time package or target run-rate. If they remain permanently responsible for the new platform, they belong in run-rate.
Decision trigger: If a named employee has both a project assignment and a production responsibility, split the capacity and cost. Do not count the same person as free implementation effort and a removed run-rate role.
“Contingency covers bad scope”
Contingency is not a substitute for missing evidence. Use it for a named uncertainty: unconfirmed data volume, unresolved contract transfer, or a test outcome that will be known by a date. Generic percentages make estimates look precise while hiding the decision still outstanding.
Decision gates for the investment case
The model should include gates that determine when a cost changes category or a saving can be recognized.
Gate 1: baseline reconciliation
Finance and IT sign off that actual vendor, people, cloud, and business-owned technology cost reconciles to cash. If the gap cannot be explained, add a downside case and do not use the reported budget as the synergy baseline.
Gate 2: service ownership
The target operating model names the owner, support tier, vendor, contract, and control obligations for every critical service. If a service has no owner, retain its current cost or fund an interim owner.
Gate 3: exit evidence
The old system, contract, or TSA has a measurable shutdown condition. If the condition is not met, the related cost remains active. This is the gate that prevents “planned savings” from appearing in EBITDA before they reach cash.
Gate 4: one-time acceptance
The program lead and service owner accept the work package against test results, data reconciliation, controls, and runbook readiness. If acceptance is partial, split the package and keep the unsupported service in temporary run-rate.
Gate 5: model start date
Finance moves the saving or new run-rate to the month after the exit condition, not the month after the budget approval. This keeps the model linked to operations.
What to do before signing
In the next 10 business days, the deal lead should run one cost bridge session with finance, technology, and the integration or separation lead.
- Reconcile the baseline. Tie 12 months of actual cash to vendors, people, cloud, allocations, and business-owned technology.
- Classify every material line. Mark it as one-time, recurring, temporary, saving, stranded, or unresolved. Add the service owner and evidence source.
- Price the target state. Include replacement services, support, controls, licenses, data operations, and volume drivers.
- Set exit conditions. For each claimed saving or TSA exit, name the test, owner, date, and contract action that makes it real.
- Put the bridge into the IC memo and funding request. Show one-time cash, temporary run-rate, steady-state run-rate, verified savings, and timing separately.
If a line cannot be classified, that is not a reason to force it into one-time cost. It is a reason to assign an owner and a decision date. The deal can carry uncertainty. It should not carry a false steady state.
The right cost model does not predict every invoice. It makes the ownership path visible: what the buyer pays to change, what the buyer pays to operate, what the buyer can retire, and which date permits the model to count the result.