Telling Existing Clients You’re Taking Over Their Hosting

You bought the reseller plan two months ago. You set up the nameservers, moved your own site across, and it has been sitting at three accounts ever since.

The part nobody writes about is the email. The one that goes to a client who has been paying GoDaddy $70 a year since 2019, explaining that you’d like them to pay you $30 a month instead. Every migration tutorial on the internet starts after that email has been sent, which is unhelpful, because the email is the hard part.

So: don’t announce this. Roll it. One client at a time, timed to each client’s own renewal date, led by the one thing you can actually promise.

This page assumes you’ve decided to resell. If you haven’t, should web designers resell hosting to their clients is the argument, and the guide to starting a reseller hosting business is the whole picture. What follows is the conversation — who to have it with, in what order, and what to say.

The short answer: one client at a time, at their renewal date

Work out what each client is on and when it renews. Start with the clients where nothing has to change but the invoice. Write to each one six to eight weeks before their renewal, lead with a single point of responsibility rather than speed or savings, and give them an easy no. Decide what you’d hand back if they left before you send the first message.

Four rules, and the second is the one that does the work. A takeover timed to the client’s renewal isn’t a proposal at all — it’s a decision they already had to make this month, with one extra option in it. The same email sent in a random week in July is a designer asking for money.

Three groups shouldn’t start yet. If you’re behind on work a client already pays for, fix that first: a takeover lands on the service you gave them last month, not the one you intend to give them. If you’ve never run a migration, don’t learn on your best client. And if you haven’t settled what you’re charging, you’re not ready to write to anybody — how to price reseller hosting plans builds that number from your actual costs.

Before you say anything to anyone

Every takeover that goes badly goes badly for the same reason: somebody named a date before they knew what they were dealing with.

What you need to know about each client

Twenty minutes in a spreadsheet, once. Eight columns:

Two of those get skipped and shouldn’t. Renewal date sets the entire sequence — without it you have no reason to write to anyone this week rather than next year. Where the email lives sets the risk, and it’s the column that will change your mind about at least one client.

Who has access to what

Most designers have never separated these three, and they behave completely differently.

The account is yours, billed to you. You bought it, you rebill it or you absorb it. Nothing technical has to happen. This is a billing conversation and a short one.

The account is in the client’s name and you have the password. The most common case, and the one to be careful with. Having the login is not the same as having permission. You don’t move a site because you can; you move it because they said yes, in writing you can point at later. An email reply saying “sounds good” is fine. Nothing is not fine.

You have no access at all. Their nephew set it up in 2017. Add a fortnight and expect a password reset from an address nobody checks.

Then the domain, which is the thing that actually has to change and is frequently registered somewhere nobody remembers. Find it before you write to them, not after. Migrating client sites to your reseller account covers what to do with it once you have.

The two things that stop a takeover dead

The site isn’t on hosting. Wix, Squarespace, Shopify, a website-builder plan bolted onto a registrar account. There’s nothing to migrate. Moving means rebuilding, which is a project with a quote attached, not a hosting conversation. Confusing the two costs you a week and an awkward retraction.

The mail is fifteen years deep. POP mail collected onto one machine under someone’s desk since 2011. Movable, but it turns a one-hour job into a Saturday, and it’s the thing your client notices within the hour. More on that below.

Who to move, who to leave, and who to move last

The order matters more than the segmentation. You want practice, revenue and a track record before you write to the client you’re most nervous about.

Nobody should send their first takeover email to their oldest client. By the time you reach group 4 you’ll have done this three times, you’ll know what your provider’s migrations actually look like, and you’ll have a sentence about it that sounds like experience rather than hope.

The clients you should not take over

Some of these aren’t worth having, and deciding that in advance is cheaper than discovering it in month three.

The client who’s already leaving. Don’t add a dependency to a relationship you’re winding down.

The site you can’t support. A custom stack, a Node app, something with requirements a shared reseller account doesn’t meet. Taking it on means owning an outage you have no way to fix — reseller vs shared vs VPS vs dedicated covers where it should actually live. However it worth checking with your existing host to see if the offer Node app support. 

The resource hog. One site consuming several clients’ worth of everything. Either it gets its own arrangement or it stays where it is; how many hosting plans you should offer deals with structuring for that.

The client who already has an IT provider. You’ll be the third party in someone else’s escalation chain, and you’ll lose every disagreement about whose fault it was.

The client you’re about to fire. Obvious once written down. Regularly ignored.

Leaving a client where they are is a decision, not a failure. It costs you a few dollars a month in margin you never had, which is less than one bad Saturday.

What you’re actually asking for

The three things that change for the client

Say it plainly, because you’ll have to say it plainly to them:

1. Who they pay.
2. Who they call.
3. Where the site physically lives — which, for them, is the least interesting of the three and should be presented that way.

There’s an honest fourth, and volunteering it is what separates this from a sales pitch: their dependency on you goes up. They’re handing you something they currently control. The way to handle that isn’t to skate past it — it’s to answer the question before they ask it, which is what the exit terms below are for.

The promise that works, and the three that backfire

The one that works is one person responsible. Nothing to renew, no support queue, no login they’ll never use again, nobody telling them to contact their hosting provider. It’s true, it isn’t checkable in a way that can embarrass you, and it describes a service you’re already providing for free.

Three to avoid:

“It’ll be faster.” Checkable in thirty seconds, frequently false, and it converts every slow page load for the next four years into your problem specifically.

“It’ll be cheaper.” It usually isn’t — you’re charging monthly for something they bought annually at a promotional rate — and the claim invites the line-by-line comparison you least want.

“It’s more secure.” Unfalsifiable right up until the morning it isn’t, at which point it’s the first sentence quoted back to you. When a client site gets compromised is the version of that conversation you don’t want to have twice.

What about the price gap? Don’t compare to their old hosting bill at all. The moment you set your number beside a $70 annual invoice you’ve agreed to be judged on the same axis as a commodity, and you’ll lose. Present the arrangement as what it is — hosting plus the things you already do for free — and let the comparison be against your own service. Hosting inside a retainer or billed separately works through how to structure it so the number never appears on its own.

The year they already paid for

They renewed in March. It’s September. Asking them to pay twice for six months is how a reasonable idea becomes a grudge, and it’s the objection most people haven’t planned for.

Default to waiting. The second option is the one most people haven’t considered, and it’s cheaper than it sounds: your marginal cost for one more account on a plan you’re already paying for is a fraction of what that client pays you, which means absorbing four months of overlap to get a client onto your books early is usually a good trade. The reseller profit calculator will tell you what one account actually costs you, and how much you can make reselling web hosting puts it in context across the whole book.

Two things not to do. Don’t chase a refund from their old host on their behalf — it’s rarely available and it isn’t your job. And if they do decide to cancel early, they cancel it, after the new site is confirmed live. Never you, and never before.

Working backwards from their renewal date

The sequence runs backwards from a date you don’t control, which is why people get it wrong.

Their renewal date → migration complete, at least two weeks earlier → migration scheduled → their yes → your message, six to eight weeks before renewal → your audit, before any of it.

Three ways that breaks:

You name a date before you know your provider’s turnaround. The date in that email is set by somebody else’s queue, not your calendar. Most decent reseller hosts will run the transfers for you at no charge — ChemiCloud’s migration team moves websites, mailboxes and client accounts on request from the dashboard, which is genuinely useful and also a queue with other people in it. Ask what the current turnaround looks like before you write to anyone, then add a fortnight. (as of September 2026)

You migrate the week the renewal lands. If anything goes wrong you have no room, and the old hosting may lapse while you’re still fixing it.

You write to them four months early. Past about two months it stops being a decision and becomes a vague intention, and you’ll be re-explaining it in October.

The conversation itself

The shape of the message

Five parts, in order, under two hundred words total:

1. What’s coming up — their renewal.
2. What you’re proposing, in one sentence.
3. What changes for them: who they pay, who they call, where it lives.
4. What it costs and when it starts.
5. An easy no.

The fifth is the one people leave out and the one that does the most work. A proposal with no graceful decline reads as an instruction, and a client who feels instructed either agrees resentfully or goes quiet for three weeks.

Example wording

Not a template — a shape. This is the group 4 client: stable, happy, nothing wrong.

Hi Jane — your hosting with Bluehost renews on 14 November, so this is a good moment to raise something.

I’d like to move the site onto my own hosting and bill it as part of what you already pay me. In practice that means you stop paying Bluehost, you stop having a renewal to think about, and when something needs doing you email me the way you already do — I just won’t have to ask you for a password first.

It works out at $30 a month, starting from your renewal date, and I’d do the move the week before so there’s no gap. If you’d rather leave things as they are that’s completely fine — I’ll keep looking after the site either way, and I’ll remind you nearer the renewal.

Two variations worth writing differently. For group 1, where you already pay for the hosting, cut it to three sentences: this is an administrative tidy-up, not a proposal, and treating it as one invites a decision that didn’t need making. For group 2, open with their own complaint — you mentioned the site was down twice in August — and let the rest follow from it.

The frame to hold throughout: you’re the person who already fixes their website, not a vendor introducing a product. No subject line containing “important update”. No bulleted list of hosting features. No uptime percentages. Nothing about your infrastructure at all, in fact — what you use is your business rather than theirs.

The clients who need a call instead

Three: your largest client, anyone whose price changes materially, and anyone you’ve had an awkward conversation with in the last year. Phone first, then send the same message in writing the same day — the written version is what the arrangement rests on.

Handling the replies

“Is it cheaper?” No, and don’t apologise for that. It’s hosting plus the things you’re already doing, on one invoice, with nobody to chase.

“I already paid until March.” Good, that’s the date we’ll start.

“Why are you doing this?” Because you already call me when something breaks, and half the time I can’t fix it properly because the account isn’t mine. Nobody argues with this one.

“Can I keep my email where it is?” Often yes, and it’s a legitimate answer rather than a concession.

“What if I want to move away later?” Answer it fully, immediately, and without hesitating — see below. A pause here costs you the yes.

“Let me think about it.” Give them a date and a default: I’ll follow up the week before your renewal, and if it’s not right we’ll leave everything exactly as it is.

And the reply that isn’t a question: silence. Follow up once, before their renewal, then stop. A client who has declined twice has answered.

The email conversation

Mail is where takeovers go wrong, and it goes wrong within the hour rather than quietly.

Three things to establish before you promise anything. Where the mail actually is — if it’s on Google Workspace or Microsoft 365, this is one DNS record and a non-event, which is the most reassuring sentence in this article for about a third of readers. How much there is and how it’s collected — POP mail on one machine behaves nothing like IMAP across three devices. Who set up the mail clients — if the answer is “nobody, it’s been like that for a decade”, budget time for reconfiguring devices and warn the client they’ll need to be reachable that day.

Here’s the position worth holding: it is entirely reasonable to move the website and leave the email alone. Either where it is, or onto a proper mail provider as a separate piece of work. A designer who declines to take custody of fifteen years of somebody’s inbox isn’t failing at the job — they’re scoping it. And if mail does move, tell the client in advance what the day will look like, because unannounced email disruption is the fastest way to lose a client you’ve had for six years.

The mechanics of moving it are a separate subject — migrating client sites without downtime covers those.

What they get back if they leave

Name the leverage honestly, at least to yourself: once you host the site, ending the relationship also means moving the site. That’s real friction your client didn’t have before, and the way to keep it from poisoning things later is to remove it from the negotiation now, before anybody needs it.

Five things to decide before you send the first message:

• What they get. A full backup of the site and databases, plus mail if you’re holding it, in a format any host can restore. Not a zip of the theme folder — backups, and who’s responsible when a client deletes their site is worth reading before you promise a format.
• How fast. A number of business days, stated.
• What it costs. Free is cleanest. If you charge for hands-on migration help, name the figure now rather than at the worst possible moment.
• How long the site stays up after they give notice.
• Who holds the domain. It’s theirs, it always was, and confirming that unprompted buys more goodwill than anything else in the message.

Hosting inside a retainer or billed separately sets out the three endings a hosted client can have and how to write a transfer-out policy once and use it forever. The only thing to add for a takeover is timing: the terms have to exist before this conversation, not after, because this is the moment the client’s exposure changes and the natural moment to tell them what it means. Where the clauses actually live is a terms-of-service question.

The order things have to happen in

1. Their written yes. An email reply is enough; it just has to exist.
2. Create the account on your reseller plan.
3. Migrate, and check the site on a temporary URL before touching DNS.
4. Test properly — forms, SSL, checkout, outbound email from the site — not just the homepage.
5. Lower the DNS TTL, then switch your customers.
6. Watch mail delivery for 48 hours.
7. Leave the old hosting running. Thirty days minimum.
8. The client cancels the old account, not you. Once you’ve both confirmed everything works.
9. First invoice on the agreed date, never before the site is live.
10. Put the next price review in the diary — raising hosting prices on existing clients explains why that date matters more than the first one.

Steps 7 and 8 are the two that get skipped. Cancelling somebody else’s service on their behalf, even with their password, is fine ninety-nine times and catastrophic once.

One more thing changes at step 9, quietly: you are now the person who gets called when the site is down at 2am, and that call is no longer a favour. Handling downtime with a communication plan is worth having before you need it, and what hosting support load actually looks like is worth answering before you move client number fifteen.

Mistakes worth avoiding

• Announcing to the whole client list in one week
• Promising a migration date before checking your provider’s turnaround
• Leading with speed, security or savings
• Moving a site before you have a written yes
• Cancelling the client’s old hosting yourself
• Invoicing before the site is live
• Taking on the email without asking how much of it there is
• Starting with your biggest client
• Having no answer ready for “what if I want to leave?”

Frequently asked questions

Can I move a client’s website without asking them? No. Having the login isn’t permission, and the arrangement rests on a written yes you can point at later — an email reply is enough. It also isn’t in your interest: a client who discovers the move afterwards will remember that, not the improvement.

What if a client says no — can I still maintain their site? Yes, and most designers keep several clients on their own hosting indefinitely. Ask for your own login rather than sharing theirs, note the renewal date, and raise it again next year if it still makes sense.

Should I tell clients which hosting company I use? You don’t have to, and mostly there’s no reason to. What you’re selling is the arrangement, not the infrastructure underneath it — white-label hosting: where the seams actually show covers how far that holds and where it doesn’t.

How many clients can I move at once? As many as you can support in the week afterwards, which is fewer than you think — two or three at a time is a sensible ceiling while you’re learning what breaks. The constraint is your attention, not the plan.

You’ve got a yes and a live site. The open question now is how the hosting appears on the invoice — as its own line, or folded into what you already charge. Hosting inside a retainer vs billed separately makes the case for each and sets out what to write down before the first client leaves.

One thing worth checking as this gets going: a takeover is the moment your account count jumps. Five clients becomes twenty in a quarter, and the number that constrains you on a reseller hosting plan is cPanel accounts rather than storage — which is not the figure most people compare when they buy.