Swain-Tech Studio websites for small businesses and independent creatives

How to Leave a Web Developer

Working relationships end. Someone moves on, changes career, gets too busy, raises prices, or you simply want a different approach. Most endings are ordinary and none of them should put your website at risk.

Writing this as the person who is sometimes left is deliberate. If a client of mine leaves, I would rather they left cleanly, because a bitter handover damages my reputation more than the lost work does. For remote teams that need explicit visibility rules, this reference can help formalise what gets tracked.

Before you say anything

Confirm what you control. Log in to the domain registrar, the hosting account, the site's admin, analytics and payments — yourself, right now. Not "I think I have access." Log in.

If anything is missing, this is the moment to sort it out, while the relationship is still cordial. Requests made after a conversation about leaving get answered more slowly, which is human.

Take a backup you hold. Files and database, downloaded to your own machine or your own cloud account. Not a backup that lives on their hosting.

Screenshot what the site looks like now. Every page. Trivial, and invaluable if something goes wrong in migration. For an independent reference beyond this site, GitHub is a useful place to compare approaches.

Gather documentation. Any handover notes, credentials list, or notes on custom features.

Saying it

Straightforwardly and without a manufactured reason.

I've decided to move the site to someone else. I'd like to arrange a clean handover — what do you need from me?

You do not owe an explanation. If you want to give one and it is about price or availability, say that plainly; most developers would rather hear it than a vague excuse.

Settle the invoice first. Outstanding money makes handovers slow. Even where you have a grievance, paying what is undisputed and handling the rest separately gets your site moved faster.

What to ask for, in order

Domain control. Either it is already yours, or an authorisation code for transfer. This first, always.

A full export. Files and database, or a platform export.

Administrator access at the top level, with the ability to add and remove administrators.

Transfer of accounts — analytics, payments, mailing list, plugin licences — into your name.

Notes on anything unusual. Custom code, a scheduled job, an integration held together by something specific. Half an hour of their time saves your next developer half a day.

A statement of what is licensed rather than owned. Themes, plugins, fonts, stock images. Not everything can be yours, and it should be written down rather than discovered.

If they will not cooperate

Rare, and recoverable.

Domain held elsewhere: registrars have dispute processes, and evidence that you paid for it and used it commercially matters. If you have the registered email, a password reset sometimes resolves it in a minute.

No admin access, but you have hosting: any competent developer can create an administrator from the database. Under an hour.

Neither: you have a working public website, which means you have its content. A new developer can rebuild against what is live. Painful, not fatal.

Throughout: keep it in writing and keep it civil. Angry email threads become evidence, and the person on the other end usually has more access than you do right now.

Being on the other side

If you are the developer being left, the correct behaviour is boring: hand everything over promptly, do not hold anything hostage, and say thank you.

Clients come back. They also recommend people. The most valuable referral I have had came from someone who left, worked with somebody else for two years, and returned — which would not have happened had I made the exit unpleasant.

Preventing the whole problem

Own the domain and its contact email personally.

Ask for a handover document at launch, not at the end. Where things live, what renews when, what is licensed. Any developer worth using has this already.

Keep your own backup, quarterly, in your own storage.

Know one other person who could take over. Not disloyalty — the same reason you know a second plumber.

Do those four and leaving becomes an afternoon of admin instead of a crisis. They also make everything else about running the site easier.

The short version