Every mid-market portfolio company has an incumbent MSP. Most of those relationships are underperforming. And most operating partners know it — but the decision to actually replace an MSP rarely happens, because the transition mechanics are opaque and the downside risk feels enormous.
That risk is real. An MSP transition run badly produces credential lockouts, endpoint enrollment gaps, backup migration failures, ticket queues that get dropped, and a 90-day window where a security incident could hit an environment nobody is actively defending. Run correctly, it’s a controlled 60-to-90-day workstream with an obvious ROI.
Almost no one writes about how to do this well. The reason is uncomfortable — the people who understand MSP transitions in detail either work at MSPs (and don’t publicize the playbook), or have done it enough times to know the failure modes but rarely commit them to paper. This article is the playbook, written from the operator side.
The audience is PE operating partners with underperforming MSPs in one or more portfolio companies, and portfolio company CEOs and CFOs who are ready to make the call but need the sequence.
When to Actually Make the Call
Most MSP relationships that are underperforming should have been renegotiated, not replaced. The decision to fire is the right one when three conditions coexist.
Structural misalignment, not fixable performance issues. If the MSP is missing SLAs on ticket response, that’s a performance issue — renegotiable. If the MSP has a revenue model that structurally opposes the portfolio company’s interests (aggressive software licensing markup, hardware pass-through with hidden margin, project quotes 40% above market), that’s misalignment — not renegotiable.
A pattern of MSP behavior around escalations. Watch what happens when a real incident hits — a security event, a major outage, a data recovery scenario. Does the MSP respond with executive attention and clear communication, or with defensive posture and reference to contract language? The second pattern is a fireable offense. It signals that the MSP sees the portfolio company as an account to be managed, not a client to be served.
Loss of confidence at the executive table. When the operating partner or the CEO no longer trusts the MSP’s technical judgment or their reporting, the relationship is over regardless of what the SLA says. Trust cannot be restored through a contract amendment.
If two of the three are present, start preparation. If all three, execute.
If the issue is a specific service delivery gap, or pricing that hasn’t been benchmarked in three years, or an SLA that predates the current scope, renegotiate first. A well-run renegotiation typically produces 15–30% pricing improvement and clearer service definition. That’s often the right outcome, and it costs a fraction of a transition.
The Pre-Notice Phase: 30–45 Days Before Anyone Knows
The single biggest mistake is telling the MSP first. Notice given prematurely — before the transition is prepared — creates a 60-day window where an unhappy MSP has all the leverage. Some MSPs behave professionally in that window. Some do not. Do not test which category yours is in.
Preparation happens quietly, before notice, and covers seven areas.
1. Credential and ownership audit. Every administrative credential for every business-critical system needs to be inventoried, and current ownership needs to be documented. Domain registrar. Email tenant. Cloud infrastructure. Firewall management portal. Endpoint protection console. Backup platform. Financial systems. RMM (remote monitoring and management) platform. In many cases the MSP holds credentials the portfolio company doesn’t know exist. That is what the audit is for.
2. Data ownership review. Contracts vary. Some MSP agreements explicitly grant the client ownership of all configuration data, documentation, and monitoring history. Some are silent, which means ambiguous. Some contain clauses that make the MSP the custodian of certain artifacts with only ninety days of retention after termination. Read the actual contract. If the language is unfavorable, the transition timeline needs to account for it.
3. Contract termination review. Notice period. Auto-renewal date. Wind-down obligations. Data return obligations. Non-solicitation clauses (some MSP contracts prevent the client from hiring MSP staff for a period after termination — which matters if a specific technician has been de facto embedded on the portfolio company account). Termination for convenience vs. termination for cause — the mechanics and cost differ.
4. Documentation extraction. The MSP has network diagrams, system configurations, credential vaults, ticket history, monitoring data, and vendor contacts. Some of this is contractually the client’s. Some is not. Regardless, the extraction happens before notice, because after notice the MSP’s cooperation typically decreases. Requests during the pre-notice phase should look like normal business — routine documentation refresh, security assessment prep, whatever framing fits.
5. Backup MSP evaluation and selection. A competitive selection process with three to five vendors, structured RFP, references from portfolio companies of similar size and complexity, and a technical assessment. The winner should be under contract, with a defined onboarding plan, before the outgoing MSP is notified. Attempting to select a replacement MSP while the incumbent is winding down is how portfolio companies end up with 45-day coverage gaps.
6. Internal communication plan. Who inside the portfolio company knows about the pending change? Typically: CEO, CFO, IT manager (if there is one), and whichever board member represents the fund. The instinct to “give the IT manager a heads up” often backfires — the IT manager frequently has a personal relationship with the MSP’s account team, and information leaks. Communicate on a need-to-know basis until notice is given.
7. Timeline document. A written transition timeline with named owners, milestone dates, and dependencies. This becomes the operating document for the transition. Without it, the transition drifts into “the new MSP is working on it” — which is not a plan.
At the end of the pre-notice phase, three things should be true. The replacement MSP is under contract. The documentation and credentials the portfolio company controls are current. The transition timeline is written, dated, and owned.
The Notice: Day 0
The notice itself is short and unambiguous. Written, delivered by the CEO (not the IT manager), copying the operating partner. It states the termination effective date per the contract, references the wind-down obligations in the contract, and requests a transition meeting within five business days.
What the notice does not do is invite renegotiation. If the intent is renegotiation, that conversation happens before termination is on the table. Once notice is given, the relationship is over — attempting to reopen renegotiation after notice signals weakness and often produces worse terms than the original.
The notice does not litigate performance failures either. This is not the moment to hand the MSP a list of grievances. If a dispute over final invoices or unfinished work will be needed, it will happen through a separate process. The notice is administrative, not confrontational.
The Transition: Days 1–90
The transition breaks into three windows.
Days 1–14: Formal Handoff Planning
Joint transition meeting between outgoing and incoming MSPs, with the portfolio company in the room. Documented handoff plan covering credential transfer, endpoint enrollment migration, RMM tool transition, backup platform migration, monitoring stack transition, ticket queue transition, and vendor contact updates. Each item gets a named owner from both MSPs and a target completion date.
Credentials are the highest-priority workstream. By Day 14, every administrative credential should be either rotated with the new MSP or verified as controlled by the portfolio company directly. Do not accept “we’ll transfer credentials at cutover.” Rotation happens progressively during transition, not in a single event.
Days 15–60: Migration Execution
Endpoint enrollment migrates from the outgoing RMM to the incoming one. Backup jobs migrate to the new platform, with a full restore test performed on the new platform before the outgoing platform is retired. Monitoring alerts route to the new NOC. Ticket queue transfers, with a defined date after which new tickets go to the new MSP.
The most common failure in this window is silent gaps — a system that was monitored by the outgoing MSP is no longer monitored, but nobody notices until it fails. The transition timeline should explicitly list every monitored system and the date its monitoring transferred. If a system doesn’t appear on that list, its monitoring status is unknown, which means it’s unmonitored.
Days 60–90: Reconciliation and Closeout
Final invoice from the outgoing MSP. Confirmation that all data belonging to the portfolio company has been returned or verified as no longer in the outgoing MSP’s possession. Formal offboarding checklist signed by both MSPs and the portfolio company. Post-transition review with the incoming MSP to identify anything that fell through the cracks.
If the contract had a wind-down cooperation clause, this is when it matters. Enforce it. Documentation the outgoing MSP was contractually obligated to produce should be produced. Non-compliance is a final-invoice dispute, not a shrug.
The Four Highest-Risk Categories During Transition
Most transition failures cluster in four categories. Preparation should be disproportionately focused here.
Credentials. The outgoing MSP has administrative access to systems the portfolio company does not fully inventory. Every day that access continues after notice is a day of risk. Rotate progressively. Verify at the end.
Backups. The outgoing MSP’s backup platform will be decommissioned. The incoming MSP’s backup platform is new and unproven for this environment. Between “old backups still recoverable” and “new backups tested and verified,” there is a window where recoverability is uncertain. That window should be as short as possible, and the operating partner should know it exists.
Endpoint enrollment. Devices enrolled in the outgoing MSP’s RMM stop being managed the moment the platform is decommissioned. If the devices are not migrated to the incoming RMM before then, they become invisible. Untracked endpoints are a security incident waiting to happen.
Monitoring and alerting. Alerts routing to the outgoing NOC will not reach anyone once the outgoing MSP disengages. Confirmation that every alert source has been reconfigured — email systems, firewalls, backup jobs, critical applications — is tedious and easy to shortcut. Do not shortcut it.
When the Outgoing MSP Goes Hostile
Most MSPs behave professionally during termination. Some do not. Signals of a difficult transition include delays in documentation delivery, evasive answers about credential inventory, sudden invoice disputes, and — in the worst cases — attempts to solicit portfolio company employees or approach fund contacts directly.
If hostility develops, three responses matter. First, escalate at the MSP’s executive level immediately — not through the account team. Second, involve counsel and reference the contract language. Third, document everything in writing, including declined requests. Verbal exchanges during a hostile transition are worth exactly zero when a dispute reaches a partner call or a demand letter.
The single best protection against a hostile transition is the pre-notice phase. If credentials and documentation were captured before notice, the MSP has significantly less leverage to create trouble.
Common Failures the Playbook Prevents
Across MSP transitions, the same failures recur. All of them are preventable.
- Fired too fast, no backup MSP in place. The transition happens in a vacuum, and coverage gaps materialize immediately.
- Auto-renewal missed by 30 days. The contract renewed while the transition was being planned. Another year of the incumbent locked in.
- Domain registrar controlled by outgoing MSP. After notice, the MSP is unresponsive to registrar-related requests. The portfolio company cannot change DNS records. This has produced real, prolonged operational damage in cases the author has observed.
- Documentation extraction skipped. After notice, the MSP declines to produce documentation beyond contractually required minimums. The incoming MSP starts from zero.
- Endpoint enrollment not migrated in time. Devices go untracked. Discovered later when a compromised device shows up in a security event.
- Backup restoration not tested on new platform. The first real recovery attempt on the new platform reveals configuration gaps. This is discovered during an incident, not during transition.
- Financial systems credentials not rotated. The outgoing MSP retains access to accounting systems and financial platforms. Rarely misused, but always inappropriate.
- MSP portal access to security tools not revoked. The outgoing MSP’s account team retains dashboards for firewalls, endpoint protection, and identity providers. These accounts are frequently missed during offboarding.
Each of these has been observed in real transitions. Each is preventable with a written offboarding checklist and disciplined enforcement.
When to Keep Them Instead
A significant fraction of transitions started should have been renegotiations. If the underlying issue is pricing, scope, or SLA rather than trust or structural misalignment, a renegotiation typically produces:
- 15–30% pricing reduction on the current scope
- SLA terms rewritten to match current expectations
- Executive accountability structure (named MSP executive sponsor, quarterly business review cadence)
- Clarified scope, with add-on services priced separately rather than bundled ambiguously
- Client-side termination-for-convenience language with reasonable notice
A well-run renegotiation is faster, cheaper, and less risky than replacement. The trigger for renegotiation vs. replacement is the trust question: is there a version of this relationship that produces the outcome the portfolio company needs? If yes, renegotiate. If no, the transition is coming regardless — better to run it deliberately.
Why This Requires Executive-Level Leadership
MSP transitions are typically run by the IT manager or the CFO’s office. Both are wrong. The IT manager has a working relationship with the incumbent MSP and often personal loyalty to specific technicians — the psychology of the transition produces slippage. The CFO’s office runs the contract terms competently but does not have the operational technology knowledge to sequence the migration workstreams correctly.
The transition needs an operator with executive standing, technology depth, and vendor management experience — someone who has selected, managed, terminated, and replaced MSPs before. That is a fractional CTO, or a technology operating partner within the fund. It is not the incumbent IT manager, not the CFO, and — most importantly — not the incoming MSP running the transition unilaterally. The incoming MSP has an incentive to appear capable and comprehensive; they do not have the standing to enforce contract obligations against the outgoing MSP.
Vertex CTO Advisory runs MSP transitions as a defined engagement — typically ninety days, scoped to the pre-notice phase, transition execution, and closeout. The engagement includes RFP support for the replacement MSP, credential and documentation audit, transition timeline ownership, and executive representation to both MSPs. What we don’t do is become the new MSP. The intent is to install the right MSP with the right SLA and the right accountability, not to substitute one vendor relationship for another.
Learn how Vertex covers MSP transitions and vendor governance →