Most Day-1 checklists are a hundred-day plan crushed into a single date. That is why they fail. A checklist built around continuity and control, not integration, is the one that survives close.

Almost every acquisition of any size arrives at close with a document labeled "Day 1 readiness." Few of those documents describe Day 1. They describe the integration everyone wants by month four: merged directories, single sign-on across both companies, one email domain, a consolidated finance system. None of that can happen on the day the deal closes, and most of it should not be attempted for weeks. We have watched integration teams treat legal close as the finish line for technology work when it is the starting gun, and the gap between those two framings is where Day-1 incidents come from.

The core mistake is a category error. Day 1 is not an integration event. It is a continuity-and-control event. The combined company has to be able to operate legally at 12:01 AM, and nothing that worked the day before should break. That is the whole job. The integration, the part that makes "one company" true at the systems level, starts on Day 2 and runs for the next year.

Why the day-1 checklist gets written backwards

The integration management office builds the Day-1 list, and it builds it from the deal thesis. The thesis promises cost savings, so the list fills with savings actions: merge the identity providers, retire the duplicate customer relationship management tool, combine the two data lakes. Each item gets an owner and the same due date, close.

A legal reason explains why none of it can happen that fast, and it deserves stating because technology teams routinely forget it. Until the deal legally closes, the two companies are competitors, and antitrust law forbids the acquirer from operating or integrating the target's systems. This is the gun-jumping rule the FTC's premerger notification program enforces, and it means the acquirer usually cannot log into the target's production systems, inventory them directly, or stage a migration inside them before close. Day 1 is therefore a cold start. The first hour the acquirer may lawfully touch the target's estate is the same hour the checklist claims the integration is done. Written that way, the checklist is a promise no one can keep.

The counter-take we offer is blunt. A good Day-1 checklist is mostly a list of things you will deliberately not do on Day 1. It scopes down, not up. The measure of a strong list is how much integration work it explicitly defers, not how much it crams into the close window.

The three buckets that actually belong on day 1

We organize every Day-1 checklist into three buckets, and we hold the line that an item earns a place only if it belongs in one of them.

Tree diagram routing a Day-1 candidate item to three buckets: must work at close (payroll, first-close consolidation, delegated authority, customer money systems), must not break (close monitoring/backup/security gaps, revoke seller admin access), and deliberately deferred (directory consolidation and single sign-on, application rationalization, email domain merge and data model reconciliation).
Figure 1. Every candidate Day-1 item sorts into one of three buckets; real integration work belongs in the deferred bucket, not the close window.

The first bucket is must work at close: the things the combined company legally and operationally cannot open for business without. Payroll has to run for the acquired employees on the next cycle, which for many deals is within 14 days of close, so payroll data and banking connections are a Day-1 item even though nobody thinks of them as integration. The acquired entity's financials have to consolidate into the parent's reporting for the first close after the deal, which drives a chart-of-accounts mapping and a data feed, not a full enterprise resource planning migration. Delegated authority has to be live so the right people can approve spend and sign contracts under the new ownership. Customer-facing systems, order intake, payment processing, support, have to keep taking money.

The second bucket is must not break: the do-no-harm list. On close, the seller's IT organization loses the right to administer systems it may still be hosting, and the acquirer's team inherits an estate it has never had hands-on access to. Two failure modes dominate here. The first is a gap: monitoring, backup, or security coverage that the seller was providing silently stops, and nobody notices until an incident. The second is a lingering thread: the seller's administrators keep privileged access they should no longer have. We treat revoking or re-scoping the seller's administrative and vendor access as a same-day action, because a former parent with domain admin is a control failure a week after you own the company.

The third bucket is deliberately deferred: everything that is real integration work. Directory consolidation, single sign-on between the estates, application rationalization, email domain merges, data model reconciliation. These are the items that make the deal thesis true, and not one of them is a Day-1 item. Putting them on the Day-1 list does not make them happen faster. It makes the list dishonest and buries the handful of things that genuinely cannot slip.

Connective tissue, kept intentionally thin

Two companies that just became one need a way to talk to each other on Day 1. This is the only place where a Day-1 checklist touches anything that looks like integration, and the discipline is to keep it thin.

Two needs each split into a Day-1 choice and a deferred choice. Email: do now a cross-tenant address list and guest access; schedule later a tenant-to-tenant mailbox migration. Network: do now a single reviewed firewalled interconnect; schedule later flattening the networks into one routable space.
Figure 3. The only Day-1 integration is thin connective tissue: a cross-tenant address list and one firewalled interconnect, with the migrations they resemble deferred.

People need to find and reach colleagues on the other side. That is a shared address book and a way to send calendar invites and messages across the two tenants, not a merged identity system. Microsoft's cross-tenant collaboration guidance describes exactly this pattern: business-to-business guest access and a synchronized global address list let two Entra ID tenants collaborate while remaining separate, which is the correct Day-1 posture and a wrong Day-100 one. The mistake we see is teams attempting a tenant-to-tenant mailbox migration in the close window because someone wrote "unify email" on the Day-1 list. A migration is a month of work at minimum for any estate above 5,000 users. A cross-tenant address list and guest access is a Day-1 configuration. Choose the second on Day 1 and schedule the first for later.

Network connectivity between the two estates is the other thin thread. Some shared services, a consolidated finance feed, a security operations sensor, need a path between the networks. A single reviewed, firewalled interconnect for named flows is a Day-1 item. Flattening the two networks into one routable space is not, and doing it early is how one company's ransomware becomes both companies' ransomware.

Security is visibility on day 1, not remediation

The single most misunderstood Day-1 item is security. The acquirer inherits an attack surface it has never assessed, often one that was not maintained to the acquirer's standard while the target was preparing to sell. The instinct is to start fixing it. That instinct is wrong for Day 1.

On Day 1 the security job is visibility and containment, not remediation. Get the acquired estate's logs flowing into a place the acquirer's security operations center can watch. Confirm endpoint detection is running and reporting. Establish an incident response path that spans both estates, because the guidance in NIST's computer security incident handling guide assumes you can see an event before you can respond to it, and on Day 1 of most acquisitions you cannot yet see the new half of the company. Only after the estate is visible does remediation get a schedule. We have seen teams spend close week hardening a firewall rule on a system they had no monitoring for, which is effort spent on the wrong end of the problem. First you watch. Then you fix.

Left-to-right sequence: get acquired logs into the security operations center, confirm endpoint detection is running, establish a joint incident response path, rotate privileged credentials, then remediation scheduled after close.
Figure 2. On Day 1, security is visibility and containment first; remediation is scheduled for after close, not attempted during it.

One specific control belongs on the same-day list: assume the target's credentials are compromised until proven otherwise. Rotating the most privileged credentials and forcing re-authentication on critical systems is cheap, and it closes the window where a pre-close compromise or a departing insider still has a working key.

How to measure a day-1 that went well

The wrong metric is how complete the integration is. On a correctly scoped Day 1 that number sits near zero by design, and reporting it invites exactly the pressure that corrupts the checklist. We measure Day 1 on two things instead.

The first is continuity incidents: how many things that worked the day before close stopped working. The target is zero, and every incident gets a same-day owner. The second is legal-and-operational readiness: can the combined company run payroll, consolidate its financials, approve spend, and take customer orders under the new ownership. That is a yes-or-no checklist, not a percentage, and it is the only completion number that matters at close.

A useful leading indicator in the 30 days before close is how many items the team has moved off the Day-1 list into the deferred bucket. In our experience the first draft of a Day-1 checklist has 40% to 60% more items than belong there, almost all of them integration work that migrated onto the wrong date. A shrinking list in the final weeks is a healthy sign. A growing one means the deal thesis is leaking into the close window again.

Where to start

The teams that reach close without a bad night are not the ones with the longest checklist. They are the ones whose checklist was honest about what Day 1 is for. The sequence we recommend:

  1. Sort every candidate Day-1 item into must-work, must-not-break, or deferred, and move anything that is real integration work into the deferred bucket before you circulate the list.
  2. Confirm the legally mandatory items first: payroll on the next cycle, first-close financial consolidation, delegated authority, and continuity of any system that takes customer money.
  3. Build the do-no-harm list around gaps and lingering threads, and put revoking the seller's administrative access on the same day you take ownership.
  4. Stand up thin connective tissue, a cross-tenant address list and one reviewed network interconnect, and refuse the mailbox and directory migrations that pretend to be Day-1 items.
  5. Make Day-1 security a visibility program: logs flowing, detection confirmed, a joint incident path, and privileged credentials rotated, with remediation scheduled for after close, not during it.
  6. Report Day 1 as continuity incidents and a yes-or-no readiness checklist, and keep integration-completion scores off the close-week dashboard entirely.

Day 1 is the one milestone in an acquisition where doing less is doing it right. The integration has a hundred days and then a year. The close window has one job, twice stated: everything the law requires has to work, and nothing that worked yesterday can break. A checklist that holds that line is the one we would sign.