Day-1 readiness is a joint operating proof, not parallel checklists. A system may be available while users lack access, required data is incomplete, or no one can resolve an incident. The business is ready only when the path from person to system to data to transaction has an owner, evidence, and a fallback.

Manage the close plan accordingly. The integration or separation lead should not ask whether the ERP, identity platform, or reporting environment is “ready” in isolation. Ask whether a named role can complete a defined outcome with the right data under the Day-1 control model, while another named person can recover it if it fails.

Day-1 defects cross domains. A missing employee record becomes an access failure; an access failure can prevent payroll approval. A data-extraction gap may appear only when an order, invoice, or close report depends on a missing record. Gates must test those connections before operations depend on them.

Use a dependency chain, not domain sign-offs

Systems, people, and data owners often sign off their own workstreams. That does not prove the business flow. The readiness lead should model each critical outcome as a chain:

role -> identity and device -> application -> interface or batch -> data -> business control -> support

The chain is only as strong as its weakest link. A role may authenticate without approval permission; an application may accept a transaction but fail to send the bank file; support may see an alert without authority to correct it.

For each link, capture four facts:

  • Dependency: what must be available or true before the next step can work?
  • Provider: which party controls it at the point of use: buyer, seller, NewCo, vendor, or a shared service?
  • Evidence: what artifact or test proves the dependency is available under the Day-1 model?
  • Fallback: what controlled action preserves the business result if the dependency fails?

This view also exposes dependencies outside the technology plan. A bank mandate, tax registration, vendor consent, or transferred employee record can be as important as a server or interface. The responsible owner belongs in the chain even when the action sits with finance, legal, HR, procurement, or operations.

Five gates for joint readiness

Gate 1: Boundary and ownership are explicit

Before testing a process, determine who owns each asset and decision at close. Map legal entities, applications, environments, cloud accounts, identity tenants, endpoints, integrations, data stores, vendor contracts, procedures, and support teams.

Shared services need more detail. A TSA may provide the service, but it does not transfer control of the outcome. Record the seller service owner, buyer accountable owner, access rights, service hours, escalation path, data handoff, and exit condition. If the service remains on a parent platform, identify what the buyer can observe, administer, change, and recover.

Pass condition: every Day-1 outcome has one accountable owner and every dependency has a provider, control boundary, and escalation route.

Fallback: if ownership is unresolved, narrow the operating scope to the path that can be controlled, add a named interim owner with an explicit end date, or treat the gap as a closing condition. Do not mark the item green because a person is “expected” to take it later.

Gate 2: Access works for roles, service accounts, and support

User login tests are not enough. Test the roles that create, approve, release, reconcile, and support critical transactions. Include federated identity, multi-factor authentication, device posture, network access, privileged access, break-glass access, service accounts, certificates, API keys, and batch credentials.

The test should run under the post-close identity and endpoint model. A seller administrator using a pre-close account does not prove that the buyer’s finance approver or support analyst can operate after close. Test joiner, mover, and leaver actions that affect Day-1 control, especially for transferring employees and temporary TSA users.

For every credential or privileged role, record the owner, rotation method, expiry, monitoring, and recovery path. If a service account has no accountable owner, its process is not ready even if the current job succeeds.

Pass condition: critical roles and machine identities complete their required actions, access changes follow the Day-1 approval path, and support can diagnose an access failure.

Fallback: retain a controlled seller-operated path under a documented TSA, establish a named break-glass procedure with review, or use a pre-approved manual transaction route. A shared emergency credential without logging is not a fallback; it removes evidence while the business is under pressure.

Gate 3: People capacity and decision rights are real

An organization chart does not show readiness. The plan must show who performs the work, who approves it, who supports the system, and who decides when a fallback is invoked. Include operators, technology support, security, data owners, vendor contacts, and people who understand local exceptions.

Test capacity against the close calendar. A finance lead may be the right accountable owner but unavailable during close. A seller subject-matter expert may know the process but have no obligation to support the buyer after the TSA starts. A buyer support team may have the skills but no access to logs or vendor cases.

Use a simple ownership pattern for each critical outcome:

  • Accountable owner: accepts the readiness evidence and the residual risk.
  • Operating owner: performs the process after close.
  • Technical owner: keeps the system, integration, or control available.
  • Data owner: approves source, quality, retention, and reconciliation.
  • Fallback owner: has authority to switch to the alternate path.

One person may hold more than one role in a small operating model, but expose the concentration. A person who owns payroll operation, identity administration, and the fallback decision creates a capacity and control risk that needs coverage.

Pass condition: named owners are available during the close window, have the required access, and have rehearsed the decision path for incidents and degraded service.

Fallback: add cross-training, seller coverage, a managed service, or an approved manual procedure for the bounded period. If no qualified owner can cover a must-work outcome, escalate the readiness decision rather than accepting an unowned risk.

Gate 4: Data is complete enough to operate and control

Day-1 data readiness has two tests: can the business use the required records, and can it explain the numbers produced from them?

The first test covers active customers, suppliers, employees, products, open orders, inventory, receivables, payables, contracts, bank details, tax attributes, and other records needed for the selected operating scope. Define the set by business use, not by whichever tables are easiest to export.

The second test covers lineage and control. Record the source of truth, transformation, owner, permitted use, retention, reconciliation rule, and reporting definition for each critical data set. Shared ERP or HR data may require filtered extracts, controlled access, historical read-only access, or a reconciliation bridge rather than a full copy. Data that cannot move may still need to remain accessible under the TSA.

Run a representative reconciliation for every critical outcome. Compare counts, balances, statuses, and key identifiers between the source and Day-1 destination or reporting layer. Test inactive records, duplicates, missing attributes, open transactions, local formats, and restricted records. A clean total can hide an unusable subset.

Pass condition: process owners confirm that required records are available, data owners approve the boundary, and the reconciliation identifies how exceptions will be controlled.

Fallback: reduce the Day-1 data scope with written approval, retain read-only access to the source, use a controlled manual bridge, or delay the dependent process. Do not allow a spreadsheet to become an unowned system of record; give it a custodian, access controls, reconciliation, and an expiry date.

Gate 5: The end-to-end path and recovery have been rehearsed

The final gate should prove the full chain, not repeat component demonstrations. Use test transactions and operational scenarios that cross the systems, people, and data boundaries. Include a normal case, an exception, an access failure, an interface or batch delay, and a support escalation.

The rehearsal should answer:

  • Can the operator complete the transaction with the Day-1 role and device?
  • Does the application use the intended master and transactional data?
  • Do interfaces, notifications, approvals, and downstream reports complete?
  • Can the support team see the failure and route it to the right provider?
  • Who authorizes the fallback, and how is the transaction reconciled afterward?
  • What evidence is retained for audit, close, payroll, customer service, and security?

Define a go/no-go rule before the rehearsal. A failed non-negotiable test blocks the relevant scope unless the accountable business owner accepts a time-limited fallback. An enhancement defect should not block Day-1 by default. Treating every defect alike either delays useful scope or hides operational risk.

Fallbacks should preserve control, not just activity

Fallback design is often reduced to “do it manually.” That is incomplete. A fallback must preserve the business result and the controls around it. For each alternate path, specify:

  1. the trigger that activates it
  2. the authorized decision maker
  3. the procedure and input data
  4. the segregation-of-duties or approval control
  5. the reconciliation back to the system of record
  6. the support route and end date

Fallback patterns include a defined TSA service, a delayed batch with a known cutoff, restricted transaction scope, a read-only source with controlled intake, dual entry for a bounded reconciliation period, or a postponed cutover. The right choice depends on the outcome and failure mechanism.

Avoid fallbacks that silently create permanent work. A manual invoice log can protect continuity for a short window but creates revenue, tax, and receivables risk if it has no reconciliation owner. A temporary access exception can unblock a role but weakens security without expiry, approval, and review. Track fallback use as a live risk, not a closed task.

Make the evidence review decision-ready

The readiness scorecard should show more than red, amber, and green. For each outcome, record the evidence date, test result, open defects, dependency owner, accountable approver, fallback, expiry, and next decision. Distinguish four states:

State Meaning Required action
Proven End-to-end test passed under the Day-1 operating model Maintain monitoring and sign-off
Conditional A bounded exception has an approved owner and expiry Track the condition to closure
Unproven Evidence is missing or only a component test exists Schedule the test or escalate the gap
Not viable The outcome cannot be delivered with the current design Change scope, add a service, or move the date

Hold the review with the people who own the result, not only the workstream leads. The CFO or finance process owner should accept close and payment evidence. HR should accept payroll evidence. Security should accept identity, privileged access, and incident evidence. Operations should accept order, service, and fulfillment evidence. The technology lead should confirm system and integration behavior, but should not accept business risk alone.

The two-week readiness close

In the next 10 business days, the deal lead, readiness lead, process owners, and technology owners can make the plan actionable:

  1. Day 1–2: define the must-work outcomes. Name the business result, scope, owner, data condition, and no-go rule for each one.
  2. Day 3–4: draw the dependency chains. Mark every seller, buyer, vendor, data, contract, and people dependency. Assign a provider and fallback owner.
  3. Day 5–6: close ownership gaps. Confirm roles, service accounts, support coverage, TSA rights, data custodians, and approval authority during the close window.
  4. Day 7–8: run focused end-to-end tests. Use representative transactions and include one failure scenario for each critical chain.
  5. Day 9–10: hold the evidence review. Accept proven scope, time-box conditional scope, schedule unproven tests, and change or delay any not-viable outcome.

The deliverable is not a larger tracker. It is a short set of signed operating decisions: what must work, how it will be proved, who acts when it fails, and when the temporary path ends.

Day-1 readiness means the business can operate inside its new boundary with known controls and named accountability. Systems, people, and data are one chain. Test it, price the dependencies, and make the fallback explicit before close.

Primary reference

NIST’s contingency planning guide provides a useful baseline for business-impact analysis, recovery priorities, contingency procedures, and testing. The Day-1 scorecard adds transaction-specific ownership, data-boundary, and TSA evidence.