+1 (877) 438-5566
info@fullonconsulting.com
Acquirer's target architecture for integrating a newly acquired company

Before You Buy Your Next Company, Know Where It Will Land

Every acquisition brings its technical debt and security risk with it. Here's how mid-market acquirers use a target architecture and a repeatable integration playbook to absorb deals safely.

By Donald D. Hook — Former CTO & CIO | Founder, Full On Consulting | Central Florida
Published

Deal season is busy in the mid-market. Owners want to close before year-end, private equity firms are stacking add-ons, and family businesses across Central Florida are selling to strategic buyers.

Most buyers do some level of due diligence. Far fewer can answer a simpler question before they sign: where will this company's technology land after closing?

When you buy a company, you get everything it has. That includes its customers and its people, and also its aging servers, its unsupported ERP, its shared admin passwords and the laptop nobody patched. On the day you close, all of that becomes your technical debt and your security risk.

You Inherit Everything

In a mid-market acquisition, I typically find some combination of:

  • •A different ERP, often older and heavily customized, plus spreadsheets that run critical processes.
  • •Overlapping applications, such as two CRMs, three file-sharing tools and duplicate licenses.
  • •Security gaps: no MFA on remote access, local admin rights everywhere, former employees who still have accounts, and backups nobody has tested.
  • •Key-person dependence: one IT manager or one outside vendor who knows how everything works.

None of this has to kill a deal. It does need a destination and a plan.

Start With a Target Architecture

A target architecture is your answer, decided before the deal, to the question "what does an integrated company look like?" For a mid-market acquirer, it doesn't need to be a 60-page document. It needs to settle a few things:

  • •The core platform. Pick one ERP, one finance process and one source of master data (customers, products, vendors) for every acquisition. Bain calls this the "systems spine."
  • •The standard stack. Identity and email, endpoint security, collaboration, CRM, and the help desk model.
  • •Where you allow exceptions. A specialty tool that sets the acquired company apart may be worth keeping. A third accounting system is not.
  • •The rules for disposition. For every inherited system, decide early whether to adopt it, migrate it, keep it temporarily or retire it.

Bain's research found that the weakest integrators run four to five times as many applications as the best performers and spend two to three times as much on IT as a share of revenue. Each new deal makes that complexity, and the cost of the next deal, worse.

Gate the Security Risk Before You Connect

The fastest way to turn a good deal into a bad week is to connect the acquired network to yours on Day 1. Security leaders are warning buyers about exactly this: the target's unpatched systems and monitoring gaps become yours at close.

  • •Treat the acquired environment as untrusted until it's proven otherwise. Connect the networks only after the security gate is passed.
  • •Day 1 essentials: MFA on email and remote access, disable stale and shared accounts, deploy your endpoint detection, and confirm backups can be restored.
  • •Before you connect: Run a vulnerability scan, review admin access, check that your cyber insurance covers the acquired entity, and run a reporting test.
  • •Give it an owner. One named person owns security for the acquired company from closing day.

Turn It Into a Repeatable Playbook

The companies that get good at acquisitions treat integration as a capability, not a one-time project:

  • •A standard sequence: security gate first, then identity and email, then finance and ERP, then operations, then retiring the old systems.
  • •Templates: data mapping for customers, products, pricing and vendors; cutover checklists; training plans.
  • •A budget per deal: Add integration cost to the deal model up front, not after closing.
  • •A team that has done it before, internal or fractional, so each deal starts from the last one's lessons.

When I led the onboarding of an acquired regional distributor and new locations onto SAP, 11 warehouses and stores in total, we did it with an internal team instead of outside implementers and saved $444,000. The bigger payoff was that the company ended up on one platform with one set of processes, ready for the next deal.

In a post-merger rationalization we led for a $16B manufacturer, the portfolio had more than 2,000 applications. Consolidating them identified $16 million in savings, and the first phase delivered $6 million a year. The work is far easier when the target architecture comes first.

What to Do Next: A Checklist

  • ☐Write a one-page target architecture: core platform, standard stack, allowed exceptions.
  • ☐Define the disposition rules: adopt, migrate, keep temporarily or retire.
  • ☐Set a security gate the acquired network must pass before it connects to yours.
  • ☐Assign a security owner for every acquired company on Day 1.
  • ☐Build integration templates: data mapping, cutover and training.
  • ☐Put integration cost and timeline into the deal model before the LOI.
  • ☐Link diligence findings directly to the integration plan.
  • ☐Review the playbook after every deal and update it.

Not sure what to look for before the deal? Here's what technology due diligence has to cover now.

Frequently Asked Questions

What is a target architecture for acquisitions?

It is the acquirer's answer, decided before the deal, to what an integrated company looks like: one core ERP, finance process and source of master data, a standard technology stack, the exceptions you allow, and rules for whether each inherited system is adopted, migrated, kept temporarily or retired.

When should we connect an acquired company's network to ours?

Only after it passes a security gate. Treat the acquired environment as untrusted at close: put MFA on email and remote access, disable stale and shared accounts, deploy your endpoint detection, test backups, scan for vulnerabilities and review admin access. Then connect.

How is integration planning different from IT due diligence?

Due diligence tells you what you are buying: the target's systems, risks and costs. Integration planning tells you where it goes: the platform it moves onto, the sequence, the budget and who owns each step. The two should be linked, with diligence findings feeding directly into the integration plan.

Let's Talk

If you're growing by acquisition and you don't have a CIO to own the platform and the playbook, that's where I come in.

I bring hands-on experience leading acquisition integrations, from ERP onboarding to integrating an entire engineering organization. I help Central Florida companies and private equity firms build the target architecture, set the security gate and run the first 100 days. Learn about our M&A IT due diligence and integration services.

Schedule a Strategy Call

Related Reading

Keep Reading

Copyright © 2026 Full On Consulting
info@fullonconsulting.com
Privacy Policy
 
Free CIO Assessment Tool
Schedule a Free Consultation