# What Day-1 really means for IT

> Define Day-1 as a minimum viable operating state—with pass/fail tests and fallbacks—so you don’t learn your dependencies at 9:00 a.m. after close.

Chapter 27 of 60 in the [M&A Playbook](https://elbantli.com/insights/), section “Day-1 readiness and transition services”. By [Naoufal El Bantli](https://elbantli.com/), Tech & IT M&A practitioner. Published 2026-01-20, updated 2026-10-05. 7 min read. Source: https://elbantli.com/insights/what-day-1-really-means-for-it/

## Day-1 is a business contract, not an IT milestone

Day-1 and “go-live” are different events. In many deals, nothing goes live on Day-1. You might run on TSAs, stand up only a thin layer of independence, or connect lightly to the buyer.

But the business still expects a contract to hold:

- People can do their jobs.
- Money moves (orders, invoices, payroll, close).
- Data is trustworthy enough to operate and report.
- Someone can support and secure the environment.

If those statements aren’t true, your Day-1 plan is still only a project plan.

## What Day-1 really means for IT: four “must be true” outcomes

Define Day-1 in outcomes first, then design the systems and TSAs to make those outcomes true.

### 1) Access works (for humans and machines)

[Day-1 fails quietly](https://elbantli.com/insights/common-day-1-failures-how-to-avoid-them/) when identity is treated as “just SSO.” In reality it is:

- authentication (MFA, conditional access)
- authorization (roles, entitlements, SoD)
- service accounts, certificates, API keys, batch credentials
- joiner/mover/leaver processes
- privileged access and “break glass” controls

**What goes wrong:** the seller rotates keys, changes federation settings, tightens firewall rules, or restricts admin access post-close. Users can’t log in—or worse, the wrong users can.

**What good looks like:** a Day-1 access checklist that is testable:

- “All Day-1 roles can authenticate with MFA and reach their core apps from corporate endpoints.”
- “All critical service accounts are owned, rotated, and tested under the Day-1 operating model.”
- “Privileged access works with named admins, and break-glass is documented and monitored.”

**Decision trigger:** _If you can’t name the owner for every critical service account and integration credential, you’re not Day-1 ready—because your batch jobs aren’t Day-1 ready._

### 2) Transactions run end-to-end (not just screens)

Day-1 stability depends on the invisible paths behind the user interface:

- order entry → fulfillment → invoice → cash application
- procure-to-pay approvals and vendor onboarding
- [payroll inputs, time capture, and tax interfaces](https://elbantli.com/insights/payroll-hr-systems-global-separations/)
- month-end close feeds and reporting extracts

**What goes wrong:** teams test logins and “happy path” workflows but miss the overnight batch jobs, EDI/SFTP transfers, and system-to-system calls that actually move money. The business finds out at the worst times: daily invoicing runs, payroll cutoff, month-end close.

**What good looks like:** a Day-1 “money flow” test script that proves transactions, not tasks:

- one order through to invoice
- one vendor invoice through to payment
- one payroll run through to payslip and bank file
- one close-critical report produced from the Day-1 data sources

**Decision trigger:** _If the first close after Day-1 requires manual spreadsheet bridges for more than a small subset of accounts, you have a Day-1 finance risk, not an integration inconvenience._

### 3) Data boundaries are clear enough to run the business

Day-1 data issues are usually boundary issues rather than “bad data”:

- which system is the source of truth for customer, product, vendor, employee
- what data can legally be shared across the boundary (especially in carve-outs)
- how master data changes propagate during the TSA period
- what KPIs mean now that you’re independent (even if systems are shared)

**What goes wrong:** a parent-controlled shared master or silently diverging reporting definitions can leave the business debating numbers instead of executing the plan.

**What good looks like:** explicit Day-1 data ownership statements:

- “Customer master changes are owned by X; downstream systems consume via Y interface.”
- “These fields are out of scope due to legal constraints; here is the workaround.”
- “KPI definitions for revenue, gross margin, and backlog are locked for Day-1 to Day-30.”

**Decision trigger:** _If you can’t reconcile revenue and receivables to the Day-1 reporting layer within the first reporting cycle, stop expanding scope and fix the data boundary. Everything else will move slower until you do._

### 4) Support and security can operate on Day-1

Day-1 is also the first day the seller’s incentives shift. They want you out, they want fewer tickets, and they will [follow the TSA contract](https://elbantli.com/insights/designing-negotiating-tsas-that-actually-work/)—not your urgency.

**What goes wrong:** there is no on-call model, no monitoring, no incident process that spans seller + buyer + NewCo. An outage becomes a three-way argument about responsibility.

**What good looks like:** a Day-1 operating model that includes:

- a single control room with named decision maker
- ticketing, monitoring, and escalation paths (including seller TSA contacts)
- incident severity definitions and response SLAs
- cyber controls that match the new boundary (logging, endpoint protection, privileged access)

**Decision trigger:** _If your “support plan” is a list of contacts, what you have is a phone tree._

## Choose your Day-1 design explicitly (and price the trade-offs)

There are three common Day-1 designs. Problems start when the deal says it picked one, but the technical reality behaves like another.

### Pattern 1: TSA-heavy Day-1 (minimum change)

You keep the business on seller systems and [rely on TSAs for continuity](https://elbantli.com/insights/tsa-strategy-why-most-deals-get-it-wrong/). This can be the right call when speed matters more than control.

**Hidden cost:** you are outsourcing your Day-1 stability to a party whose incentives change on Day-1.

**If/then triggers:**

- _If the TSA term is under 9–12 months and identity/network access is shared,_ plan independence work immediately. Waiting makes the exit harder, not easier.
- _If the seller won’t grant admin-level access for systems you must operate,_ assume delays and build fallbacks (manual invoicing paths, offline procedures, alternate reporting).

### Pattern 2: Minimum viable independence (stand up the control plane)

You stand up a thin layer that gives NewCo control even if apps stay on the parent: identity, endpoints, network segmentation, logging, ticketing, and a few critical integrations.

This is often the best “risk-adjusted” [Day-1 posture for carve-outs](https://elbantli.com/insights/tech-implications-carve-out-vs-full-acquisition-deals/): short of a full separation, with enough control to run without begging.

**If/then triggers:**

- _If you’re inheriting regulated data or strict customer SLAs,_ independence of logging and access control is Day-1 scope, not Day-100 scope.
- _If the business depends on always-on integrations (EDI, API partners),_ stand up monitoring and alerting inside NewCo, even if the interface endpoints remain on the parent.

### Pattern 3: Integrated Day-1 (connect to buyer platforms)

In some acquisitions, you move fast to the buyer’s identity, endpoints, network, and selected shared services.

**The trap:** buyer readiness becomes the critical path. If the buyer’s identity, device management, and security controls can’t scale quickly, “integrated Day-1” becomes “partial access and weeks of exceptions.”

**If/then triggers:**

- _If the buyer cannot onboard the target’s users and endpoints end-to-end before close (identity, device, access, support),_ don’t make it Day-1 scope. Use an interim model and phase the integration.

## Make Day-1 testable

Most Day-1 plans are task trackers. They have owners and dates, but they lack decision logic and [pass/fail criteria](https://elbantli.com/insights/day-1-readiness-systems-people-data/).

Create two artifacts that force clarity.

### Artifact 1: the Day-1 definition (one page)

Write Day-1 as a business contract with three columns:

1. **Non-negotiables:** “must work” outcomes (payroll, order entry, invoice run, customer support access).
2. **Degraded acceptable:** what can be slower or manual for a bounded period (manual reporting bridge, limited self-service, temporary approval workarounds).
3. **Not Day-1 scope:** explicitly deferred items (platform replacement, app rationalization, major data migration).

Every line needs an owner and a fallback.

### Artifact 2: the Day-1 scorecard (tested, signed-off)

For each non-negotiable, define:

- **test** (what proves it works)
- **owner** (who signs off)
- **dependency** (TSA/system/party)
- **fallback** (what happens if the test fails)

Then run it like a product release: rehearse the full flow, including failures, and make the go/no-go call based on the scorecard—not optimism.

## Primary reference

[NIST's contingency planning guide](https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final) is a useful baseline for business-impact analysis, recovery priorities, contingency plans, and testing. A transaction still needs deal-specific pass/fail gates across the buyer, seller, and NewCo operating model.

## Define and test the Day-1 contract

If you’re inside 30–60 days to close, these actions reduce Day-1 risk fast:

1. **Write the Day-1 definition page (deal lead + COO + CIO).** Non-negotiables, degraded acceptable, not in scope. Get it signed.
2. **Lock the identity strategy (CIO + security lead).** Federation, MFA, privileged access, break-glass, and service account ownership. Test the top roles and the top integrations.
3. **Prove the money flows (CFO + IT lead).** Run a mini end-to-end script for order-to-cash, procure-to-pay, and payroll using the Day-1 operating model.
4. **Turn TSAs into readiness gates (separation lead).** For each TSA service, document what “available on Day-1” means in practical terms (permissions, hours, escalation, project work).
5. **Stand up the Day-1 operating model (PMO lead).** Control room, incident process, monitoring, ticketing, and named decision rights across buyer/seller/NewCo.

Day-1 is the first day the business expects you to operate with new constraints and real accountability. Define it as an operating state and test it like a release so dependencies are exposed before operations rely on them.

---

**About the author.** Naoufal El Bantli has delivered multiple IT carve-outs and IT post-merger integrations for private equity and corporate clients. His work spans IT due diligence, separation and integration strategy, ERP transformation, and Day-1 to Day-100 execution. Decision thresholds in this chapter are practical heuristics unless a source is linked. [Connect on LinkedIn](https://www.linkedin.com/in/elbantli/)

Topics: [Day-1](https://elbantli.com/insights/tags/day-1/), [Deal execution](https://elbantli.com/insights/tags/deal-execution/), [Carve-outs](https://elbantli.com/insights/tags/carve-outs/)

## Related chapters

- [Day-1 readiness: systems, people, and data](https://elbantli.com/insights/day-1-readiness-systems-people-data/): Day-1 readiness means proving that systems, people, and data work together at close, with evidence-based gates, accountable owners, and fallbacks.
- [Designing and negotiating TSAs that actually work](https://elbantli.com/insights/designing-negotiating-tsas-that-actually-work/): Translate the exit plan into service schedules, measurable rights, commercial controls, and acceptance gates that keep a TSA temporary and operable.
- [Managing TSA dependencies and exit risks](https://elbantli.com/insights/managing-tsa-dependencies-exit-risks/): Control post-close TSA dependencies with evidence-based exit waves, buyer capability gates, and cost decisions tied to value timing.

Previous: [Tech implications of carve-out vs full acquisition deals](https://elbantli.com/insights/tech-implications-carve-out-vs-full-acquisition-deals/) · Next: [Day-1 readiness: systems, people, and data](https://elbantli.com/insights/day-1-readiness-systems-people-data/)