Taking over a client from another MSP

Most of the trouble in a takeover happens in the gap between the contract and the control. The client has signed with you, and as far as they are concerned you are their IT provider now. The outgoing provider still holds the domain registrar login, the firewall password, and the global admin account, and has no particular reason to hurry.

You own the outcome during that gap without owning the systems. What follows is how to get through it: what to do before anyone is notified, exactly what to ask for, how to verify it, the order to rotate it in, and what your options are when the other provider goes quiet.For the general first-thirty-days sequence that applies whether or not another provider is involved, see the MSP client onboarding checklist.

Read the outgoing contract first

Ask the client for their agreement with the current provider and read it yourself. Clients rarely know what is in it.

Four things to look for:

• Notice period. Thirty days is common and sixty is not unusual. The clock usually starts on written notice, not on the conversation the client already had.
• Auto-renewal date. If notice lands after it, the client may owe another full term.
• Data and credential return. Some agreements spell out what the provider has to hand back and how long they have to do it. If yours does, quote the clause in the notification letter.
• Equipment ownership. Firewalls, switches, and access points are sometimes leased through the provider or bought under their agreement. If the hardware leaves with them, your rollout plan changes and so does your price.

Set the disconnection date yourself, working backward from what you need to get done. If you let the outgoing provider set it, it will land on the last day of their contract and not a day earlier.

The client sends the notification

The letter goes out on the client's letterhead, from whoever signs contracts there, addressed to the provider's account manager. You draft it and the client sends it. A termination notice arriving from the incoming MSP invites a slower response and sometimes a hostile one.

Keep it short and put four things in it:

• The termination date and a reference to the notice clause.
• A named point of contact for the transition, which is you, with an email and a phone number.
• A request for full return of credentials and documentation, with a deadline at least two weeks before the termination date.
• A line asking them to confirm receipt.

Ask the client to copy you so you have the timestamp. Two weeks of buffer sounds generous, and it is not. The first list you get back will be incomplete, and you will need the rest of that time to chase what is missing.

What to ask for

Send one list, in writing, with a date on it. Piecemeal requests get piecemeal answers, and they let the other provider treat every item as its own negotiation. Group it the way you will work through it.

That last group is the one most likely to be refused. Documentation is often treated as the provider's own property, and depending on the agreement they may be right about that. Ask anyway. How they answer tells you how the rest of the transition is going to go.

Verify before you trust

A credential is not access until you have logged in with it. Work down the list, test each one, and record who tested it and when.

You are looking for three failure modes:

• Passwords that are simply wrong, usually because they were rotated after the list was written.
• Accounts that work but do not carry the rights you were told they have. A global admin that turns out to be a user admin. A firewall login that turns out to be read-only.
• Accounts that work today and are tied to the outgoing provider's own identity, which will stop working the moment they tidy up their systems. Anything with their domain in the username belongs in this category.

Test the backup restore yourself rather than accepting a report. Pick one file and one virtual machine, restore them somewhere harmless, and confirm the data is real. A backup that has never been restored is a claim.

The lockout

Rotation order matters. Close the doors that let someone back in before you touch anything else.

1. Domain registrar. Change the registrant email to an address the client controls. Most registrars lock a domain against transfer for sixty days after a registrant change, so if you also plan to move the domain to your own account, move it first and change contacts afterward.
2. Tenant global admin. Create your own break-glass account with a long unique password, store it offline, exclude it from conditional access, and confirm it works before you disable anything else.
3. Delegated admin and partner relationships. This is the step that gets skipped. In Microsoft 365 a granular delegated admin relationship gives the outgoing provider standing access to the tenant, and it survives every password change you make. Remove it explicitly from the partner relationships page, and check the partner of record on the subscriptions while you are there.
4. Firewall, VPN, and remote access. Rotate the admin account, then go through the user list and remove accounts belonging to the outgoing provider's staff.
5. Domain admin and local admin accounts, then the DSRM password on each domain controller.
6. Service accounts, one at a time, restarting and verifying the service after each. This is the slowest part of the job and the part most likely to break something at two in the morning if you rush it.
7. Backup console and encryption keys. Rotating a backup encryption key can orphan existing restore points, so find out what your platform does before you change it.
8. Everything else. Line of business apps, vendor portals, ISP, VoIP, copier.

Then sweep for the access that is not a password:

• Their RMM agent, monitoring agent, and backup agent. Removing these often needs an uninstall key that only they have, which is why it belongs on the request list.
• Scheduled tasks and scripts running under their accounts.
• SSH keys and API tokens.
• Inbound firewall rules that exist so their tools can reach in.
• Alert destinations and notification emails still pointing at their helpdesk.
• Mailbox forwarding rules and mailbox delegation.

Record every rotation with a timestamp. When the client asks in six months whether the old provider can still get in, you want to answer with dates rather than a recollection.

When they will not cooperate

Sometimes the list comes back empty, and sometimes it does not come back at all. Before this turns into a legal question, work out how much of it you can do without them. It is more than most people expect.

• Domain. If the client controls the registrant email address, they can recover the registrar account directly. If they do not, registrars have a dispute process a company can use to reclaim a domain registered on its behalf, and it runs on company documents rather than the old provider's permission.
• Microsoft 365. If you can prove control of the domain by adding a DNS TXT record, Microsoft has an admin takeover process built for exactly this situation. It is slow and it is tedious, and it does not require the outgoing provider.
• Network hardware. A factory reset and a rebuild costs you a maintenance window and a long night. Sometimes that is cheaper than three more weeks of unanswered email.
• Backups. Start a fresh backup chain on your own platform, and keep the old retention alive only for as long as the client's compliance obligations actually require.

Escalate through the client rather than around them. A note from the client's owner to the outgoing provider's owner, citing the return clause in the agreement, moves things that your emails will not. Keep your own messages factual and free of grievance. You will run into these people again, and in a few years one of them may be handing you a client.

Set a walk-away date on each open item. If the firewall password has not arrived by a fixed date, you reset the firewall. Deciding that in advance is what stops the whole transition from stalling on one unanswered request.

Tell the users what is happening

The technical work can be flawless and the takeover can still be judged a failure, because the only thing most of the client's staff experience is that something changed and nobody told them.

Before the cutover, one page from the client's leadership covering:

• Who to call, and what changes about how they get help
• What will happen on their machines, and roughly when
• What will need their attention, such as signing in again or restarting
• What is not changing

After the cutover, a short note confirming it is done and repeating the support contact is worth more than it costs to write.

Closing it out

Get written confirmation from the outgoing provider that their access is removed and their agents are uninstalled. It will not always arrive, and on its own it proves nothing, but it puts the question on the record.

Then check it yourself. Sign-in logs, remote access logs, and the endpoint list are more convincing than an email. Reconcile the final invoice with the client while you are at it, because overlap billing is common and usually resolvable.

At thirty days, sit down with the client and go through what you found. Every takeover surfaces something nobody knew about: a server nobody could patch, an expired warranty, a backup that had not run since spring, a licensing gap. That conversation is where a transition turns into a relationship, and it is a much easier conversation to have if you kept a record while you were working.