Most businesses stay with a web developer about two years past the point it stopped working. The relationship usually started well, the developer knows the site’s history, and switching feels risky, so the frustration gets absorbed as normal. Sometimes it is fixable with one direct conversation. Sometimes the business has grown past what the arrangement can deliver. This article covers how to tell the difference, and how to switch without your website becoming a hostage.
Quick answer: The pattern looks like this: response times stretch, small changes take weeks, proactive advice stops, and you realize you hold none of your own credentials. Switching safely means collecting access first (domain, hosting, site admin, analytics), then bringing the new team in for a parallel handoff period before anything is cut off.
What are the signs?
- Response time has decayed from hours to weeks, and urgent means something different to them than to you.
- Every request, however small, becomes a quoted project with a lead time.
- The advice stopped. Nobody flags problems or suggests improvements anymore; they only execute what you spell out.
- It is one person with no backup, and their vacation is your outage window.
- There is no staging site and no version control, so changes are edits on the live site and rollback means hoping.
- You learn about problems from customers instead of monitoring.
- You asked for a login and the answer was complicated.
Which of these are fixable with a conversation?
Capacity problems sometimes are. A good developer who got busy will tell you so when asked directly, and either restructures the arrangement or helps you transition, because professionals do not hold sites hostage. Have the conversation once, with specifics: response times, a named recent example, and what you need going forward. What that conversation cannot fix is a skills ceiling or a business model mismatch, like a solo designer maintaining what has become an e-commerce operation. If the same problems survive a direct conversation, you have your answer.
What access should you hold no matter who builds?
This list is worth auditing today, before you need it:
- The domain registrar account, in your company’s name with your billing.
- DNS management, wherever it lives.
- The hosting account, as owner rather than as an invited user.
- WordPress or platform admin credentials for your own site.
- Google Analytics and Search Console, with your account as administrator.
- The code repository, if custom work exists, under your organization.
- License keys for paid plugins and themes.
If any of these live only with the developer, that is the first thing to fix, independent of whether you switch.
How do you switch without downtime?
- Complete the access audit above quietly. Recover what you can through account processes.
- Engage the new provider for a paid audit before anyone is notified. They inventory the site, flag risks, and confirm they can support it.
- Run a short parallel period where both have access and nothing is cut off. The new team takes over routine work first.
- Transfer remaining credentials, then rotate every password and remove old access, including FTP accounts and API keys.
- Get a handoff document: hosting details, integrations, licenses, known quirks.
- Give notice per your agreement’s terms, professionally. Burned bridges have a way of owning DNS records.
What if the current developer will not hand things over?
Escalate through the account owners rather than through them. Registrars have documented recovery processes for businesses that can prove ownership. Hosts will work with the paying account holder. Outstanding invoices should be settled, since unpaid work is the one legitimate reason for a hold. Document requests in writing as you go. Legal pressure exists as a last resort and is rarely needed once the platform-level recovery paths get used. The permanent fix is the ownership list above, from day one, with every provider.
What should you expect from the next arrangement?
Onboarding that starts with an audit, credentials that live in your accounts from the first week, response terms in writing, and a monthly report you can read in two minutes. Whether that is a maintenance plan or a fuller fractional team arrangement depends on how much development you need. If you are somewhere in this process now, reach out through the contact form and tell us where it stands, including the awkward parts. We have onboarded plenty of sites mid-divorce.
Frequently asked questions
Who legally owns my website?
Whatever the contract says, which is why it matters. Typically you own content and design you paid for, while code ownership and licensing vary. Separate from legal ownership is practical control: the accounts and credentials. Secure the practical control regardless of the paperwork.
Do we have to rebuild from scratch?
Usually not. A competent new provider audits what exists and keeps what is sound. Rebuilds are for sites on a developer’s proprietary platform, or codebases in a state where maintaining costs more than replacing. Treat “it all has to go” from a new provider as a claim to verify.
How long does switching take?
Two to six weeks in the normal case: audit, parallel access, credential rotation, handoff. Access recovery is the variable. When the old developer cooperates it is quick, and when they have vanished, registrar and host recovery processes add weeks.
Should we tell our current developer we are unhappy first?
Yes, once, directly, if the relationship was ever good. It is fair, and sometimes it works. Secure your access audit before that conversation, since the small risk of a bad reaction is easier to carry when you already hold your own keys.
What if the site is on the developer’s proprietary platform?
Then you are deciding about the platform, and the developer, at the same time. Ask what export options exist for content and data. Often the realistic path is a planned rebuild on a portable platform, timed on your schedule rather than during a crisis.
What does onboarding with a new provider cost?
A paid audit typically runs a few hundred to a couple thousand dollars depending on site complexity, and it is worth paying, because it produces the inventory and risk list that make the transition safe. Free audits are sales documents, priced accordingly.