Key takeaways
- Protect customer-critical and cash-critical continuity before changing systems, roles or local procedures.
- Use the seller-overlap window to observe real work and exceptions; do not spend it only on status meetings and software tours.
- Standardize definitions and evidence before centralizing execution. Shared numbers are unreliable when each branch means something different.
- Treat day 30, 60 and 100 as decision reviews, not universal deadlines. Every major change needs an owner, test, stop rule and recovery path.
Day 1 protects continuity and makes uncertainty visible
Broad integration playbooks coordinate workstreams, owners and dependencies. Your operating layer needs a shorter list: which recurring outcomes cannot wait, who owns them now, what source proves their state, and where an unresolved exception goes.
Freeze avoidable destructive changes until access, backups, active commitments and open exceptions are visible. NIST's contingency guidance is system-focused, but the operating discipline transfers: define alternate paths and recovery before disruption.
| Outcome | Current owner | Source of truth | Fallback |
|---|---|---|---|
| Customer-critical service | Named local lead | Live queue and commitment record | Escalation owner and response clock |
| Cash-critical routine | Qualified accountable owner | Approved source system | Manual reviewed path; no autonomous money action |
| Access incident | System owner | Identity and access record | Approved recovery channel |
| Open exception | Case owner | Exception ledger | Named decision authority |
Use four review windows without pretending every company shares a clock
- 01Close through early continuityHuman approvalConfirm owners, access, open commitments, incident routes and the seller's agreed availability. Keep scope inside the actual agreement.
- 02Observe and reconcileTriggerWatch high-frequency normal and imperfect cases. Compare branch definitions, source records and seller corrections.
- 03Reverse-shadow and testHuman approvalThe successor runs selected work. Test the normal route, a known exception and recovery with the seller unavailable.
- 04Approve bounded changesCodeOnly after stable evidence exists, decide what stays local, moves to shared services or becomes controlled execution. Use a release and rollback plan.
A review can happen near day 30, 60 or 100, but the page does not promise those dates fit every deal. Regulated duties, employee changes, customer commitments, system risk and the agreement can change the order.
Keep three ledgers so a green workstream cannot hide an unstable process
| Ledger | Question | Exit evidence |
|---|---|---|
| Integration workstream | Was the planned change assigned, decided and accepted? | Owner, decision, dependency and accepted deliverable |
| Recurring process | Can one live case reach the intended state? | Trigger, inputs, rules, exception, approval and verified effect |
| Control change | Can the new path fail safely and be reversed? | Test population, stop rule, recovery owner and rollback result |
Use the acquisition process inventory to select the first process. It keeps transition attention separate from definition strength, so urgency cannot masquerade as readiness.
Northline delays one standardization and accelerates another
Northline is a fictional home-services acquisition. Two branches use different labels for “completed job.” The central team wants one rule immediately, but one branch includes customer sign-off and another records sign-off separately.
The team first standardizes the reporting definition and preserves the local source fields. It delays the operational change until both branches run live cases and reconcile the final state. Weekly reporting, whose definitions and sources now agree, moves to a reusable skeleton sooner.
No timing, savings, integration or customer outcome is claimed. The example shows why different processes can cross the same calendar boundary at different maturity.
Ask five questions at every review boundary
- Which customer-critical or cash-critical outcome is still exposed?
- Which definition or source mismatch prevents a shared view?
- What did the seller or local expert correct in a real case?
- Which successor-run test failed, and what record changed because of it?
- Which proposed change has an owner, acceptance test, stop rule and recovery path?
Limitations and when not to use this
- This is an adaptable operating framework, not legal, tax, accounting, employment, cybersecurity, valuation, investment or transaction advice.
- There is no universal first-100-days sequence. Use the actual company, agreement, obligations and qualified advisers.
- Do not use a calendar milestone as permission to centralize or automate a process that lacks evidence, authority, exception ownership and recovery.
- Northline and all figures are simulated. No customer outcome, system integration or guaranteed timeline is claimed.
Sources
- The First 90 Days After an HVAC Business Acquisition — Homestead Service Partners Accessed 9 August 2026
- M&A Integration Playbook — DealRoom Accessed 9 August 2026
- Contingency Planning Guide for Federal Information Systems — NIST Accessed 9 August 2026
Build the process inventory
Choose which recurring work enters the first operating review window.
Build the process inventoryUli Prantz
Builds and operates all-agents
Uli Prantz builds all-agents, the process-automation platform this site documents. He writes about the operational side of automating recurring business work: where deterministic code beats model judgment, where it does not, and where a human still has to approve.