The hardest moment in any business relationship is the breakup. The IT version of that breakup is worse than most because the outgoing vendor often holds the keys to your environment. Microsoft 365 Global Administrator credentials. Domain registrar logins. DNS control panel access. RMM agents on every endpoint. License billing as the partner of record. None of this is necessarily malicious. It is just how MSP relationships are usually structured, and it becomes a problem the day the relationship goes south.
This is the article I wish every Salinas small business owner had access to before deciding to switch IT providers. I have helped a number of local businesses through this transition. The good news: a clean switch is straightforward if you do it in the right order. The bad news: the wrong order can cost you a week of downtime, a few thousand dollars in license recovery work, or in the worst cases, a tenant lockout that takes a lawyer to resolve.
Below is the playbook. It applies whether you are switching to Ghosxt, to one of the other Salinas-area MSPs, or to an in-house IT person.
How to know it's actually time to switch
Switching MSPs is disruptive. It takes 30 to 60 days of attention from someone in your business who does not have spare time. You should not do it for a single bad week. You should also not avoid doing it when the pattern is clear. Five signals that come up almost universally in the businesses we have helped switch:
1. Response times are slipping past the SLA without explanation
Your contract probably specifies a response time on critical, high, normal, and low priority tickets. If "critical" tickets are taking four hours to acknowledge and the SLA says fifteen minutes, that is informative. If you cannot find your SLA in writing because the contract never specified one, that is also informative.
2. No monthly reporting, or generic reporting
A real MSP should send you a monthly summary: what was patched, what was caught by the security stack, what is recommended next, what is in the backup logs. If you have not received one in months, or if the reports look identical every month with no real content, the MSP is either not doing the work or not measuring the work.
3. Surprise project bills for work that should have been included
Routine items that should be inside the monthly contract (a printer driver update, a Microsoft 365 administrative change, a user onboarding) are showing up as separate project invoices. This is the slow form of MSP price-creep, and once it starts, it usually accelerates.
4. Repeated security or backup misses
An endpoint without EDR for three months. A backup that has not run in two weeks. A user without MFA enabled. None of these is unique on its own. All of them happening repeatedly is a pattern that the MSP either does not have the operational discipline to catch or is not actually doing the security work the contract describes.
5. The MSP is reactive instead of proactive
You hear from your MSP only when you call them. They do not call you with recommendations. They have not done a strategic review in over a year. They cannot answer "what should we be doing differently in the next twelve months." Reactive MSPs are technically functional but they leave the strategic work to you, which is the work most small business owners cannot do themselves.
None of these on their own is fatal. Two or three together is the pattern that signals the relationship is over. Save your notes from the last three to six months, because they will be useful when you talk to the next MSP.
The most important step: protect your own access BEFORE giving notice
This is the part most businesses get wrong, and it is the part with the highest cost when it goes wrong.
Many MSP relationships are structured so the MSP holds the keys to the kingdom. They have your Microsoft 365 Global Administrator credentials. They are the registered partner of record on your M365 licenses. They control your domain registrar account at GoDaddy or Cloudflare. They manage your DNS. They are the named contact at your ISP. They have RMM agents on every endpoint with admin rights.
In a healthy relationship, that is fine. The MSP is doing what they were hired to do. In a deteriorating relationship, it becomes leverage. Once you give notice, the MSP has no operational incentive to be cooperative, and the credentials they hold are the credentials you need to keep running your business.
Run this checklist two weeks before you plan to give notice. Run it before you sign with the new MSP if you can.
Microsoft 365 Global Administrator
- Log in to
admin.microsoft.comas a Global Admin. If you cannot, request the credentials from your current MSP "for an internal audit" before giving notice. - Confirm at least one Global Admin account is owned by your business, not the MSP. Ideal: a dedicated admin account in your domain, with MFA enrolled to a phone you own and recovery codes printed and stored in your office safe.
- Change the password on that admin account yourself. Document the new password securely.
- Confirm no Global Admin accounts belong to the MSP's tenant (look for accounts with email addresses ending in the MSP's domain). If they exist, they should be removed during the transition, not before. But you should know they exist.
- Verify that your business owns the Microsoft 365 tenant outright. If the tenant is in the MSP's organization, that is a serious problem that requires a separate tenant migration project.
Domain registrar (GoDaddy, Cloudflare, Namecheap, etc.)
- Log in to the registrar where your domain is registered. If you do not know which registrar, run
whois yourdomain.comfrom the command line or use any public WHOIS lookup tool. - Confirm the registrant contact, admin contact, and billing contact are your business email addresses, not the MSP's.
- If the MSP is listed, transfer ownership of the registrar account to you. This is usually a simple form on the registrar's side.
- Verify two-factor authentication is enabled and on a device you own.
- Note: domain transfers between registrars take 5-7 days and require the domain to be unlocked. Do not initiate a domain transfer during your notice period unless you have already lined up the new registrar.
DNS
- Whoever controls DNS controls your email delivery, your website, and your Microsoft 365 service availability. Confirm you have admin access to the DNS provider (often the same as your registrar, sometimes Cloudflare or Route 53 separately).
- Export the current DNS records as a backup. Save the export somewhere you control.
- Do not change DNS during the switch unless the new MSP requires it. DNS changes during a transition are the single most common cause of email outages.
Other vendor relationships
- ISP / firewall: confirm you (not the MSP) are the account holder.
- Microsoft 365 license partner of record: this is who Microsoft bills for licenses. Transfer can happen at end of the annual term or via a partner-of-record change form mid-term.
- Backup vendor (Datto, Veeam, Acronis, etc.): confirm you have the account credentials and that backups will remain accessible after the MSP relationship ends. Some MSPs run backups inside their own tenant on shared accounts.
- Security tool (CrowdStrike, SentinelOne, Huntress, Microsoft Defender for Business): same question. These often live in the MSP's tenant and disappear at the end of the contract.
- Antivirus / RMM: same.
The principle: anything that you cannot continue running without the MSP is something you need to either own or have ready to replace before the relationship ends.
Pick the new MSP
Once your access is protected, pick the new provider. This is a separate decision from the breakup, and it should be made on its own merits, not as a reaction to the current relationship. We have written separately on:
- The four IT support models for Salinas small businesses (in-house, break-fix, MSP, hybrid) and how to choose between them.
- Top 5 managed IT services providers in Salinas and Monterey Bay with honest profiles and a decision guide.
- How much does managed IT cost in Salinas in 2026 with real per-user ranges and a quote-evaluation checklist.
When you talk to the new MSP, ask them about their offboarding policy. If they ever lose you as a client, what do they hand back? A good MSP has a written answer to this. It signals that they treat clients as owners of the environment, not hostages of the contract. The relevant offboarding clauses to ask about, in writing, on the new contract:
- Full network and asset documentation handed over within 30 days of termination, in a standard format.
- All administrative credentials transferred to client-owned accounts within 30 days.
- Backup data exported in a usable format (not locked to a proprietary appliance).
- Microsoft 365 partner-of-record transferred at client's direction.
- RMM, EDR, and other agents removed from endpoints on request.
- No "cooperation fee" or "transition surcharge" beyond standard project rates for transition assistance.
The cleanest version of this: ask the new MSP to send you their standard offboarding clause before you sign the contract. The good ones have one. The bad ones have to invent something on the spot.
The 30/14/0-day transition timeline
Day -30 to -14: protect access and pick the new MSP
Run the access-protection checklist above. Pick the new MSP. Sign the new contract. Do not give notice to the current MSP yet.
Day -14 to 0: parallel deployment, quietly
The new MSP starts onboarding alongside the existing one. They:
- Deploy their RMM (remote monitoring) agents on every endpoint. This can run alongside the old MSP's RMM for a short period.
- Deploy their EDR / security stack. Most modern EDR tools coexist with the old one for a few days during overlap, then the old one is uninstalled. If they conflict, the new MSP times the swap.
- Configure backup to a new tenant. Verify a successful backup and test a restore before relying on it.
- Document the network, the servers, the user list, the line-of-business apps, and any vendor relationships.
- Build the security baseline: confirm MFA on every account, audit Global Admin list, review Conditional Access policies, validate patch compliance, confirm legacy authentication is off.
This phase is the part most rushed transitions skip. It is also the part that prevents the post-switch surprise where the new MSP discovers something the old one was hiding or quietly broken.
Day 0: give notice
Per your contract, typically 30 to 60 days written notice. The current MSP will continue to provide service during the notice period. You will need to be polite and businesslike; this is not the time to relitigate past grievances. The goal is a clean exit.
Within 48 hours of notice, ask the outgoing MSP in writing for:
- Full network documentation.
- Complete asset inventory.
- Administrative credential list (including service accounts).
- Backup data export in a portable format.
- Transfer of Microsoft 365 partner-of-record to your new provider (this is a one-form change in Microsoft Partner Center).
- Confirmation of the offboarding schedule (when their agents will be removed).
- Any IP, custom scripts, or configurations they developed specifically for your environment.
Day 0 to 30: cutover and verify
The old MSP removes their agents. The new MSP becomes primary. Verify:
- RMM and EDR are clean (no leftover old agents on any endpoint).
- Backups are running from the new system and a test restore has been performed.
- Microsoft 365 admin access is correct and the partner-of-record has transitioned.
- Documentation handover is complete.
- Final invoice from the old MSP is paid and reconciled.
Day 30 to 60: stabilization
The new MSP runs the environment solo. The first month is when previously-hidden problems surface: a backup that was never running, an endpoint that was never enrolled in EDR, a license that was being double-billed. The new MSP should expect to spend the first month cleaning up and the second month operating normally.
Common transition pitfalls
Giving notice before running the access checklist
Already covered above; this is the biggest one. The cost is anywhere from a few hours of friction to a tenant lockout that takes legal pressure to resolve. Run the checklist first.
Letting the old MSP "manage" the transition
The outgoing MSP has no incentive to do a thorough handover. Their incentive is to spend as little time as possible while still being technically compliant with the contract. The new MSP should drive the transition. The old MSP should respond to specific written requests from the new MSP. If you let the outgoing vendor lead, things get missed.
Skipping the parallel period
"We'll just cut over on the 1st." Tempting because it is faster and cheaper. Disastrous because the first time the new MSP touches your environment in production is also the first time they realize what the old MSP was hiding. The parallel period exists to surface those surprises before they become emergencies.
Forgetting about line-of-business apps
QuickBooks, vendor-specific ERP, industry-specific software (ag traceability, healthcare EHR, logistics dispatch). These often have admin access tied to the old MSP. Document who holds what before the transition. We wrote about one of the more annoying examples in the QuickBooks email error post.
Not getting the offboarding clause in writing
This applies in both directions. The contract with the old MSP should have specified offboarding terms. Most do not, or specify them vaguely. The contract with the new MSP should specify them clearly. Read both contracts before signing the second.
What a good new MSP onboarding looks like
The standard a serious MSP brings to onboarding:
- Week 1: Discovery. The new MSP audits the existing environment, documents everything, identifies gaps, builds a written project plan for the transition. You receive a draft document.
- Week 2: Tooling deployment. RMM and EDR rolled out, baseline scans completed, security gaps inventoried.
- Week 3: Identity and access. Microsoft 365 tenant audit, MFA enforcement, Conditional Access policies put in place, Global Admin cleanup. Heavy overlap with the identity hardening playbook.
- Week 4: Backup, monitoring, documentation. Backup tested with restore evidence. Monitoring tuned. Network and asset inventory finalized.
- Week 5-6: Cutover. Old agents removed, new MSP becomes primary.
- Week 7+: First monthly report. First quarterly business review at the 90-day mark.
Ghosxt's onboarding follows this rhythm. We document everything, we test before we cut over, and the first 90 days include a written audit of the environment we inherited. The audit is for you, not us; we want you to have a written baseline of where your environment was on the day we started, so the improvements over the next 12 months are measurable.
How we approach onboarding for clients leaving another Salinas MSP
About a third of the businesses we have onboarded came from another MSP. The pattern is consistent enough that we have a standard process for it. The first 60 days look like:
- Day 1-3: a one-hour call with the owner to understand the relationship that is ending, the specific complaints, and what they want from the new provider. We capture this in writing so we can show it back at the 90-day review.
- Day 3-14: we run the access-protection checklist for you. Most owners do not want to do it themselves, and we are paid to do that work. Critically, we do it before you give notice, so the outgoing MSP cannot use credential delays as leverage.
- Day 14-30: parallel deployment of our RMM, EDR, identity hardening, and backup, alongside the existing tooling. We do not depend on the outgoing MSP for anything during this phase.
- Day 30: you give notice to the old MSP. We coordinate the agent removal and documentation handover from our side, so your time is not consumed by it.
- Day 30-60: stabilization. Old agents off, baseline verified, first monthly report delivered.
- Day 90: written audit of what we inherited, what we have changed, and what we recommend over the next 12 months. This is the document that justifies the switch.
What this gets you: a transition that does not require you to be an IT project manager. Owners who switch MSPs are usually switching because the previous relationship demanded too much of their attention. The transition itself should not also demand too much of their attention.
What to do this week if you are unhappy with your current MSP
- Today: write down the specific things that are going wrong. Dates, ticket numbers, specifics. This becomes your evidence base.
- Today: log into
admin.microsoft.comas a Global Admin yourself. If you cannot, request credentials from your current MSP under any reasonable pretext. - This week: run the access-protection checklist (Microsoft 365 Global Admin, domain registrar, DNS, ISP).
- This week: talk to two or three potential new providers. Use the Top 5 listicle and the pricing guide to frame the conversations.
- Next two weeks: sign the new MSP. Do not give notice yet.
- Following two weeks: new MSP deploys their stack in parallel. Verify everything works.
- Day 30: give notice. Run the cutover and verify completion.
FAQs about switching IT providers
How do I know it's time to switch IT providers?
Five signs come up almost universally: response times slipping past the SLA without explanation, no monthly reporting (or generic reports that look the same every month), surprise project bills for work that should have been included, repeated security or backup misses, and a sense that the MSP is reactive instead of proactive. None of these on their own is fatal. Two or three together is the pattern that signals the relationship is over.
What should I do before giving notice to my current MSP?
The single most important thing: confirm you control your own Microsoft 365 Global Administrator account, your domain registrar, and your DNS. Many MSPs hold these credentials on behalf of clients, which is fine in a healthy relationship and risky in a deteriorating one. Before notice, log in as the Global Admin yourself, change the password, store the recovery key, and verify domain registrar and DNS are in accounts you control. Skip this step and you can find yourself locked out of your own tenant the day after termination.
How long does it take to switch MSPs?
A clean transition takes 30 to 60 days. The first 14 days are documentation and access recovery (running the pre-notice checklist). Days 14 to 30 are signing the new MSP and starting their discovery. Days 30 to 60 are the actual cutover: the new MSP deploys their RMM and security tooling alongside the old one, runs in parallel for a week or two to verify nothing is missed, then the old MSP is notified and access is rotated. Faster than 30 days usually means corners are being cut.
What does my current MSP have to give me when I leave?
In California, the answer depends on what your contract says, but the realistic ask is: full network and asset documentation, all administrative credentials, backup data in a usable format, transfer of the Microsoft 365 partner-of-record relationship (so license billing moves with you or to your new provider), and removal of the MSP's RMM and security agents from your endpoints. A good contract specifies all of this upfront. A bad contract is silent and you have to negotiate it during exit. Always ask to see the offboarding clause before signing any new MSP.
Can my old MSP block my exit?
Not legally, if you have your access in order. They can be slow, uncooperative, and unhelpful, which is why the pre-notice checklist matters. The leverage they have is operational: if they hold your Global Admin and you didn't run the access recovery first, they can effectively delay the transition by being slow to hand over credentials. Once you control your own Global Admin, domain registrar, and DNS, no MSP can stop you from switching. They can only make the last two weeks awkward.
Do I have to wait for my contract to end?
Read your contract carefully. Most MSP contracts in the Salinas market are 12-month initial terms with month-to-month or annual renewal after that. Most allow termination with 30 to 60 days written notice during the renewal period. Some have steep early-termination fees if you exit during the initial term — these are usually 50 percent of remaining months. Calculate the breakage cost; sometimes the math says "wait three more months, then switch." Sometimes it says "the early-termination fee is cheap compared to another year of this." Your call.
What if my current MSP is also a friend or family member?
Common in small business markets like Salinas. Honest answer: the relationship usually survives if the conversation is handled well. Tell them directly, in person, before signing the new MSP. Explain the specific reasons. Offer to refer other businesses to them. Pay any breakage fees gracefully. Most of the friend-and-family MSP relationships I have seen end have remained friendly because the business owner was upfront about why. The ones that ended badly were the ones where the owner went radio silent and then sent a termination notice via email.
Need help running the transition?
30 minutes with the founder. We'll walk through your current MSP relationship, run the access-protection checklist with you, and tell you honestly whether Ghosxt is the right next step. If a different provider on the Top 5 list is a better fit, we'll tell you that. No sales script.
Book your free assessmentPrefer to talk first? Email sales@ghosxt.com or call (831) 204-0501. Based in Salinas, serving Monterey, San Benito, Santa Cruz, and Santa Clara counties.