Post-Acquisition Operations Architect Checklist (90-Day Axis Method)

Why This Matters Right Now

Acquisition activity in the lower-middle market ($10M–$100M revenue) has accelerated, and the operational failure rate on integrations is high. Most acquired companies are running a patchwork of tools, undocumented processes, and informal org structures. When two of those companies collide, the chaos does not cancel out. It compounds.

The window between close and the first operational crisis is short. Companies that move into integration without a clear system-level plan spend months firefighting instead of building. The Axis Method is designed for exactly this gap: a defined engagement with a defined end, producing a system your team can run without outside help. If you want to understand the full engagement model before going further, start at the Axis Method overview or review what an Operations Architect engagement covers.

Why Post-Acquisition Checklists Break Before Day 30

Most integration checklists are task lists. They track boxes, not systems. The boxes get checked; the system underneath stays broken. That distinction is not cosmetic. A task list tells you what to do. A system tells you what happens when something goes wrong.

• Two companies running different payroll, CRM, and scheduling stacks do not merge cleanly by adding more tasks to a spreadsheet.
• The failure pattern is predictable: overlapping tools, duplicated headcount costs, and no single source of truth across either company.
• Most checklists have no named system owner. They have a project manager. That is not the same thing.
• The DefaultFail principle says to assume the integration will break on the first stress event and build for that reality from day one, not after it happens.
• The companies that struggle most are the ones that skip Diagnose and jump straight to Automate. That sequence is non-negotiable in the Axis Method.

I have seen integrations where two separate HR platforms were running payroll simultaneously for the same employees for six weeks post-close. Nobody caught it because the checklist said "confirm payroll setup" and someone checked the box on day three. Confirmed does not mean consolidated. That is the gap a task list cannot close.

Understanding what operational waste actually costs in a dual-stack environment is the first step. The cost is not just the redundant software seats. It is the human hours spent reconciling two systems that should have been one.

The Axis Method Applied to Post-Acquisition Integration

The Axis Method is a five-stage Operations Architect engagement. Each stage has a specific output. None of them are optional, and the order matters.

1. Diagnose: Map both operating stacks side by side. Where do they conflict? Where do they overlap? What is missing entirely? No decisions get made until this map exists.
2. Stabilize: Lock down the critical paths that cannot fail first, specifically payroll, fulfillment, and customer communication, before touching anything else. Stable beats elegant in this phase.
3. Document: Every SOP, every decision, every tool gets written in a format the in-house team can own and run without outside help. Documentation is not a bonus deliverable. It is the deliverable.
4. Hand-off: The engagement ends with a functioning, documented system your team operates. Not a dependency on a consultant. If we are still essential at month twelve, we did our job wrong.
5. Compound: Stable systems compound over time. Chaotic ones erode. The gains from months two and three come from the stability locked in during month one.

The Axis Method is not project management. It is system architecture with a built-in exit. Every stage produces something tangible: a map, a stabilized critical path, a set of owned SOPs, a hand-off document, and a compounding baseline your team operates from. Nothing about the engagement is designed to extend itself.

I ran this framework across a decade of enterprise operations at organizations including Amazon, International Paper, Spirit Halloween, Maersk, and Levi Strauss, representing roughly $3B+ in operational impact. (OAG receipt: cedric.career_summary) The principles transfer directly to lower-middle-market integrations. The scale changes; the failure modes do not.

The OIL Framework Pass: Cut Before You Combine

Before you consolidate anything, you run the OIL Framework. The sequence is Interrogate, Delete, Simplify, Automate. That order is non-negotiable. Never automate a process you have not confirmed needs to exist at all.

• Interrogate every tool both companies pay for. One question: does this produce a measurable output that would stop something if it disappeared?
• Delete what does not pass that test. Combining two SaaS stacks without cutting first does not reduce cost. It doubles the waste.
• Simplify what remains to the fewest moving parts that still accomplish the job.
• Automate last. Automation applied to a broken or redundant process just produces broken results faster.

A common find in a dual-stack audit: redundant CRM seats, two HR platforms, and three project management tools running simultaneously with overlapping functions. The CRM redundancy alone can run into thousands of dollars per month before you account for the data reconciliation cost. One OAG client replaced Salesforce Sales Cloud Enterprise (at roughly $2,000/year per seat) with a purpose-built owned system, saving approximately $1,100/year per seat. (OAG receipt: jps.replaced_tool) (OAG receipt: jps.savings) That kind of cut is only possible if you interrogate and delete before you build anything new.

We do not install. We do not add. We cut. Then we simplify. Then, and only then, we automate. If you want a self-serve starting point for running this audit on your own current stack, the StackOS Framework PDF is $29 and walks through the audit sequence step by step.

The Stack Audit: One Operating System by Day 60

The goal by day 60 is one operating system. One payroll layer, one CRM, one scheduling layer, one document system. Not two of each in a truce. One.

• Run a full StackOS Audit on both companies in week one. Every tool, its monthly cost, and its owned alternative gets documented.
• Target state by day 60: one payroll system, one CRM, one scheduling layer, one document system, owned where possible.
• The StackOS default stack runs on Cloudflare Workers, Supabase, R2, KV, Resend, and Stripe at roughly $75/month and replaces several rented enterprise tools.
• For a 500-person workforce, that stack replaces $48,000–$96,000/year in UKG, ADP, Dayforce, or Kronos licensing. (OAG receipt: spirit_halloween.system_cost)
• The audit itself takes one session. The decision about what to keep takes discipline, not more data.

I run Obsidian Axis Group on $74/month total, end to end. (OAG receipt: oag.monthly_run_cost) That is not a flex. It is proof that the stack works. The same principles that keep OAG's own infrastructure lean apply directly to a post-acquisition consolidation. The tools are different; the logic is identical.

The table above is not a pitch for custom software in every case. Some rented tools make sense. The point is that combining two rented stacks without first running the OIL Framework pass guarantees that you are paying for waste at scale. The audit tells you what to keep. Then you decide what to own.

The 90-Day Hand-Off Timeline

The engagement is scoped to 90 days. That is not a marketing claim. It is the design. Here is how the timeline breaks down.

1. Days 1 to 30: Diagnose and Stabilize. No new tools, no new hires, no major structural decisions until the current state is fully mapped. The output of this phase is a complete operating stack map for both companies and a stabilized set of critical paths.
2. Days 31 to 60: Document. Every critical path gets an SOP. Every SOP gets a named owner inside your company, not inside OAG. If there is no named internal owner, that is a hiring signal, not a reason to extend the engagement.
3. Days 61 to 90: Hand-off. The test is simple: does the system run without an Operations Architect in the room? If yes, the engagement closes. If no, something in the Document phase was incomplete and we fix that, not extend the timeline indefinitely.

The engagement runs $3,000–$7,500/month and is scoped to end. It is not structured to extend. The Compound stage is what happens after we leave: the stable system produces gains month over month because the foundation holds. That compounding belongs to your team, not to us. See the full Axis Method glossary entry for stage-by-stage detail on what each phase produces.

Operations Architect vs. Full-Time Hire Post-Acquisition

The instinct after a close is to hire. That instinct makes sense. You feel the operational gap and you want to fill it permanently. But a full-time COO hire post-acquisition costs $180,000–$300,000/year plus equity before the operating system is even defined. You are paying to define the job while the person is in the seat.

• A full-time COO hire at that salary range requires a defined operating system to manage. Post-acquisition, that system does not exist yet.
• An Operations Architect engagement runs $3,000–$7,500/month for the duration of the integration and then exits with a documented hand-off.
• You do not need a permanent head of operations before you know what the operations actually are. Define the system first.
• The StackOS Framework PDF at $29 is a self-serve starting point if a full engagement is premature and you need to audit your current stack alone.
• The engagement ends. The documentation stays. Your team runs it. That is the model.

Here is the honest framing: if the operating system is undocumented and split across two companies, a full-time COO hire inherits chaos and spends their first six months doing what the Axis Method does in 90 days. That is an expensive way to get to the same place. Define the system first, then hire the person to run it. See how the Operations Architect role compares to a traditional COO hire for a fuller breakdown.

The OAG blog also covers the hiring sequence question in more depth for operators who are weighing a full-time hire against an engagement before integration is complete.

Sources

OAG receipts cited

• cedric.career_summary
• oag.monthly_run_cost
• spirit_halloween.headcount
• spirit_halloween.system_cost
• jps.replaced_tool
• jps.savings
• mobile_mechanic.replaced_tool
• mobile_mechanic.savings