How to Fire Your MSP’s Web Service Without Losing Your IT Support

If you read the previous post and recognized your business, the next question is the practical one: how do you actually move the website work elsewhere without your IT support getting weird about it?

Most owners we talk to are stuck on this part. They know the website isn’t working. They know it’s the wrong shop building it. They just don’t want to wake up the next morning to find their email is broken because the IT guy is mad.

Good news: that fear is real but mostly overblown. With a clean handoff and the right conversation, you can keep your MSP doing what they’re good at and move the website to a team that does that well. Here’s the playbook.

First, do the math on whether they’ll actually retaliate

Most local MSPs don’t lose sleep about losing the website piece. The website was an upsell — usually a low-margin one — and they’re doing it because someone said yes, not because it’s strategic. When you tell them the web work is going elsewhere, the typical reaction is a shrug and a question about whether you’re keeping the IT contract.

What you should be alert for is the economic signal: how big is the website piece relative to your IT contract? If it’s less than 20% of what you pay them, they’ll keep the IT side because the IT contract is what actually pays their team. If it’s more than half, you’re a website-revenue customer with IT as the upsell — and that flips the dynamic. We’ll come back to this.

Step 1: Recover access before you say anything

This is the part most people get wrong. They have the conversation first, then ask for credentials, and now they’re asking a slightly defensive vendor for keys to a building they technically own — which is awkward at best.

Do the recovery first. It’s your stuff. You’re entitled to it. And if you find a piece you can’t get to, you’ve learned something important about your relationship before you’ve made it adversarial.

The access checklist

Before you do anything else, confirm you have direct ownership and login access to all of the following. If you don’t, ask politely — framed as a routine cleanup of your own records, not as a prelude to firing them.

1. Domain registrar. Where is yourdomain.com actually registered? GoDaddy? Cloudflare? Network Solutions? You should have the login. If your MSP “handles it,” that’s a problem — if you stop paying them, the domain renewal goes with them.
2. DNS provider. Same question for whoever manages the DNS records. Sometimes it’s the registrar, sometimes a separate provider (Cloudflare, AWS Route 53, ClouDNS). You want admin access.
3. Hosting / control panel. Where is the website actually served from? cPanel? AWS? a generic shared host like Bluehost? Get the login and admin credentials.
4. Source code / files. If your site is on WordPress, you want admin access to the WordPress dashboard. If it’s a static site, you want a copy of the source files (HTML, CSS, JS, images). Ask for an export or a zip if needed.
5. SSL certificate. Usually managed automatically these days, but worth confirming. If your MSP set up a paid cert and is renewing it under their account, plan to migrate it.
6. Email setup. Often the same vendor handles email (Microsoft 365, Google Workspace). Email is a separate concern from the website — but if your MSP is the admin on your email tenant, document the setup so the new web team doesn’t accidentally break MX records during the migration.
7. Google Business Profile. Are you listed as the owner, or is your MSP? Log into business.google.com with your business email and check. If they’re the primary owner, transfer ownership to yourself before the conversation. (You can keep them as a manager if you want.)
8. Google Analytics + Search Console. Same drill. Your business email should be the admin/owner; the MSP can be added as a user. If they own it under their own account, request ownership transfer.
9. Any marketing / forms / chat services. Mailchimp, ActiveCampaign, Calendly, Tidio, Drift — whatever’s wired into the site, you want to own those accounts directly.
10. Google Ads. If they run ads, you should be the billing owner on the Google Ads account, with them as a managed-account link. Not the other way around.

If any of those come back as “we’ll send those over once we know what’s going on,” that’s your first signal that the conversation is going to be harder than it should be. We’ll cover what to do about that below.

Step 2: Have the conversation

Once you have the access locked down, the conversation gets easier because there’s nothing they can hold over you. Here are two scripts depending on the relationship.

Script A: Brief and respectful (recommended for healthy relationships)

“Hey [name] — we’ve decided to move the website work to a specialist agency this year. We’re really happy with [MSP’s name] on the IT side and want to keep that exactly as it is — servers, email, helpdesk, the works.

The website handoff: we’ll need [list anything you don’t already have access to] sent over by [date]. The new team will be in touch directly with anything technical — no need for you to coordinate the migration.

Let me know if you want to reduce the contract to reflect dropping the web piece, or if you’d rather keep it the same. Either’s fine.”

That’s it. No justification, no elaborate explanation, no apology. You’re a customer making a vendor decision. Most professional MSPs respond fine to this.

Script B: Decline a sales push without committing to anything

Sometimes the conversation isn’t about firing them — it’s about pushing back when they want to bundle more web stuff into your contract. Use this:

“Appreciate the offer. We’re going to keep website work separate from IT for now — different teams, different cadence. The IT side is working great and we’d like to keep that focused. If we have any web needs, we’ll handle those through a different vendor.”

Friendly, firm, no opening for them to come back with “but we can do that too.”

Step 3: What to do after the conversation

Migrate fast and clean

Don’t leave the old site live for months. Once the new site is ready, point the DNS over and put a clean redirect on the old hosting. The longer the old site exists in parallel, the more chances there are for an outdated phone number or wrong hours to embarrass you in a search result.

Keep your MSP’s IT scope explicitly defined

Once the website is gone from their plate, you can have a follow-up conversation about what’s in their managed-IT contract going forward. Most MSPs are happy to define scope clearly — the contract becomes simpler for both sides.

Watch the first 60 days

Most MSPs are fine after the handoff. A small number get passive-aggressive (slower response times on tickets, “we’ll get to it next week” on things that used to be same-day). If you see that pattern, document it — that’s information about whether the relationship was actually healthy or just stable because you weren’t making any moves.

Red flags during the transition

Most handoffs are fine. The exceptions to watch for:

• Domain hostage. “We’ll release the domain once you settle the outstanding balance” on a balance you didn’t know existed. Push back hard and immediately — ICANN rules say a registrar can’t hold your domain for an undisclosed dispute. If they don’t budge, file a complaint with ICANN.
• Surprise “handoff fees.” Some shops will try to charge $500–$2000 to “package up” the site files. Read your original agreement — unless this fee was disclosed up front, it’s opportunistic. You can usually push back successfully by saying “send me everything that was billed for in the original engagement” without engaging on a new fee.
• Account ownership confusion. Google Business Profile, Google Ads, and Google Analytics are the most common places where ownership is tangled. The fix is in the Google admin UIs, not in negotiation with the MSP — but it can take a few days to resolve a transfer request.
• Sudden IT service degradation. If response times triple or tickets start sitting overnight after you’ve announced the web move, that’s a separate problem to address. Worth bringing up directly — sometimes it’s coincidence, sometimes it’s a signal that you should be looking at a new IT provider too.
• Push to bundle “managed website” back in. If they push hard to keep the web work, that’s a sign you’re higher-margin to them than you thought. Worth knowing.

What if the IT contract is actually the smaller piece?

Earlier we mentioned the case where the website is more than half of what you pay your MSP. If that’s you, the calculus is different — you’re effectively their website customer with IT as a side service, and the math is:

• If you stop paying for the website, you become a low-priority small-IT-only customer to them, and the relationship probably ends in 6–12 months either way
• You should pre-line-up an alternative IT provider before the conversation
• The handoff is messier because you’re moving more pieces, but the math is still in your favor — spending the same total on actual specialists is almost always better than paying generalists for both

This is also where Coderize Express becomes especially handy — if you need both a new website and a new IT provider, the website you can solve in 3-5 days while you take more time on the IT search.

If you want help with any of this

The fastest path: spin up a replacement site on Coderize Express ($199-$399/mo, $99 deposit credited to your first month of service, live in 3-5 days) so you have something polished and converting before you have the conversation with your MSP. That way the question becomes “here’s the new site, please send over the domain credentials” instead of “please build us another site, but better, with no specifics about what better means.”

If your situation calls for a real custom rebuild — multi-page service business, e-commerce, member portal, etc. — our custom-build service ($5,500+) is the path. We hand over source code; no platform lock-in.

Either way, we’ll do a free 15-minute audit of your current setup before quoting anything — we look at the site, the Google Business Profile, the local-pack rankings, and the access situation, and tell you honestly whether the rebuild is going to be worth it. Reach out and we’ll send a calendar link.

And if you haven’t read the prequel: Should Your IT Company Build Your Website? covers the structural reasons MSP-built websites usually underperform, in case you’re still on the fence about whether to make the move.