Acquisition Risk Modeling for MSPs: What I Learned by Getting It Wrong

 

In 2008, my MSP was in a strong position. Evolve was a generalist IT services provider — servers, infrastructure, the bread and butter of that pre-cloud, pre-security era. Business was solid, and when the opportunity came to acquire a smaller MSP, I jumped. New clients, new recurring revenue, a shortcut to organic growth.

Within four months, I'd lost nearly every contract I acquired. I was running the company on credit cards and watching the business I'd built before the deal start to buckle.

Here's what went wrong — framed around the risk modeling I should have done before I ever signed.

Risk 1: Unverified Revenue Quality

My entire acquisition thesis lived in Excel. I saw a client list, saw revenue numbers, and built a model that showed what Evolve would look like with those contracts bolted on. What I didn't do was look behind the numbers.

I didn't verify financials with any rigor. I didn't assess client quality — their engagement, satisfaction, or likelihood of surviving a transition. I didn't fully understand whether the contracts were even transferable. I had lawyers and advisors giving me checklists and guidance, and I skipped most of it because I thought the deal was simple.

The reality: most of the acquired clients were low quality, loosely attached, and had zero loyalty to a new provider, and most important, not interested in our standards. When the transition wasn't identical, they cancelled.

The model should have included: Client quality scoring, contract transferability review, and churn scenarios at 20%, 40%, and 60%.

Risk 2: Key-Person Dependency

The single worst blow came from what I thought was a crown jewel account. The technician I'd inherited convinced that client to hire him directly, cutting us out entirely. He walked out the door and took the revenue with him.

The model should have included: Identification of key-person dependencies, non-compete and non-solicitation provisions, and a client relationship transition plan that reduced single points of failure.

Risk 3: Staffing Exposure

I'd taken on the acquired company's staff as part of the deal. As contracts evaporated, I was suddenly overstaffed with no way to support payroll. The deal structure itself was actually sound — a small amount down with payouts tied to retained contracts — so the purchase price didn't bury me. But the operational cost of carrying a larger team through a collapsing client base was devastating.

The model should have included: Staffing cost scenarios tied to revenue retention thresholds, with defined triggers for restructuring if contract volume dropped below break-even.

Risk 4: Distraction Cost to the Core Business

This is the risk nobody talks about. As things spiraled with acquired clients, every ounce of energy went into triage — saving contracts, fixing service gaps, onboarding properly. All reactive, all urgent. Meanwhile, our existing Evolve clients started getting less attention. Response times slipped. Proactive work stalled. They noticed.

It took over a year to stabilize. The financial hole was real, but the distraction cost to existing client relationships was worse.

The model should have included: A capacity plan that ring-fenced service delivery for existing clients, with dedicated resources for integration work that didn't cannibalize the core business.

The Framework I Wish I'd Used

If I distill this down to a single failure, it's that I never modeled the downside. Every assumption was optimistic. There was no Plan B.

Before closing any MSP acquisition, stress-test your model against these questions:

• What happens if 30–60% of acquired clients churn in 90 days?
• Which accounts depend on a single technician relationship, and how do you mitigate that?
• At what revenue retention level does your staffing become unsustainable, and what's the trigger plan?
• How do you protect service quality for your existing clients during integration?
• What's your worst-case financial exposure, and can you survive it without jeopardizing the core business?

If you can't answer these clearly, you're not ready to close.

This Isn't Just Acquisition Advice

Here's the thing — every one of these risks exists in your MSP right now, whether you're acquiring another company or not.

You have clients on your books today whose revenue looks solid in your PSA but who are disengaged, underserved, or one bad experience away from leaving. You have technicians whose departure would take key accounts with them. You have staffing costs that assume current revenue holds steady. And you've almost certainly taken on a major initiative — a new service line, a platform migration, a big project — and watched it quietly erode the attention your existing clients were getting.

The same discipline applies. Score your client quality regularly. Identify where single points of failure exist in your client relationships. Know your break-even staffing number and what triggers a change. Protect the core business whenever you take on something new.

Most MSPs run on optimistic assumptions every day. We plan for growth, not for contraction. We assume clients will stay, staff will remain, and revenue will hold. The acquisition just compressed all of those unexamined risks into a few brutal months and made them impossible to ignore.

The Bottom Line

Whether you're evaluating an acquisition or just running your MSP on a Tuesday, the discipline is the same: model what happens when things go wrong. Build the plan that assumes some clients leave, some key people move on, and some initiatives don't land the way you expected.

Work the process. Listen to your advisors. Stress-test your assumptions. And be brutally honest about the downside — because that's where the real risk lives.

I learned this the hard way. Hopefully you don't have to.

War story of your own? I do appreciate feedback.