First 100 Days After Acquisition: An MSP Handover Plan

Who Do You Tell First: Clients, Staff, or Vendors?

On day one, tell your own staff first, then clients, then vendors. Tell staff in the morning, before they hear it from a client or a competitor. Then, by noon, send a joint announcement from you and the acquired owner to every client. The message should answer three questions: does my contract change, does my support change, and who do I call?

Keep the announcement short. One page. Say that pricing and support hours stay the same for the first ninety days, and that the same people still answer the phone. Co-sign it with the acquired owner if you can. A joint signature signals continuity.

Confirm what you can say before you send anything. The purchase agreement and local law may constrain day-one communications, so check the contract and talk to a lawyer before you promise anything about pricing, contracts, or roles.

Then schedule follow-up calls within the first week for your top 20% of clients by revenue. Those calls aren't a formality. My view is that they're your best early chance to hear objections while you can still act on them. My read is that what clients worry about most is rarely the tools; it's whether their favorite technician is staying.

If you can't get the client list on day one, use the acquired owner's personal outreach to at least the top clients before any public announcement. And if there's no formal client list, run a quick data export from their PSA or CRM before close. You need those contacts from the first hour.

How Do You Keep the Staff Who Actually Know the Tools?

In the first two weeks, the priority is the people who carry the client relationships and the tooling knowledge. Map every acquired client to a named engineer or service desk lead, and assign a knowledge-capture owner, likely the acquired company's service manager or lead tech.

Create a knowledge capture process: walk-throughs, documentation, or recorded sessions for the tools and processes that staff alone know how to run. Record an experienced technician doing familiar work and have someone else turn that into written instructions, rather than asking the technician to produce a polished document. Use whatever you have; a shared drive with a structured folder and a simple template beats a fancy tool that nobody opens. Protect the time. Tell the team that documentation time isn't interrupted by new client demands. My read is that documentation fails when it's treated as optional extra work, so make it a scheduled, named task.

Give staff a clear path for their role and any changes to pay or hours. My view is that uncertainty about those terms unsettles people more than the change itself. Tell them on day one whether their role, pay, and on-call terms stay the same for the first quarter, and be honest if changes are coming.

Before you promise anything about pay, hours, or on-call terms, check local employment law. What you commit to on day one binds you, and a promise you can't keep is worse than a hard conversation.

Knowledge capture must be completed before you migrate the tools those staff run. If you move the backup platform before you know where the offsite copies are, you lose the ability to troubleshoot mid-transition. That is the moment the whole deal turns into a fire drill.

What Moves First: Backup, PSA, or RMM?

Move monitoring and backup first, because they protect against disasters. Then the PSA or helpdesk, because it's the daily workflow. Finally the RMM, because it touches every endpoint and is the riskiest to change. Before each migration goes live across all clients, run a dry-run with staff. Never skip the dry-run to save time. That is how a migration breaks a critical client environment.

Say you're migrating backup to your standard tool. Do it with a pilot client first, test a restore, confirm the acquired staff can run it, then roll it out to the rest. Then move the PSA over a weekend, with the old tool in read-only mode for a week. Only then switch the RMM, with a pilot group of five clients before the rest.

For every tool, have a rollback plan: a backup of the configuration, access to the previous version, and a named person who owns the migration. If a tool is end-of-life or unsupported, consider replacing it with your standard tool rather than migrating, but do that after knowledge capture, not before.

If you're forced to migrate all tools at once because a vendor contract expires, extend the overlap period and run the old tool in read-only mode for a week. That buys you a fallback if the new tool doesn't behave.

When Does This Whole Plan Fall Apart?

The plan fails if you can't get the client list on day one, if staff are too overloaded to document, or if you're forced to move all tools at once. Each of those conditions should slow or stop the plan, not push it faster. Build a one-week buffer into each sequence, and be ready to pause when the service desk is overwhelmed. A week of overlap costs money; a lost client costs more.

Picture this: you discover the acquired company's PSA export is incomplete, so the client list has gaps. Don't delay the announcement waiting for a perfect export. Use a manual spreadsheet from the seller's laptop and send the message on time. Sending it on time is what stops a client hearing about the deal from a vendor or a competitor first.

And if staff are so buried in tickets that they can't take two hours for a walk-through, don't push the documentation. Clear the queue first, even if that means you take tickets yourself for a day. The knowledge capture is the asset you bought; the tickets are the noise.

What Do You Do on Monday Morning?

Pull the client contact list and the staff list. Lock the announcement to be sent by noon. Schedule the first knowledge-capture session for the following day. That is the plan in motion before the week ends.

Finalize the client message with the acquired owner. Contact the key clients individually and book the first operational walkthrough with the backup administrator.