What information should I get from my current website provider before leaving?

At least five things: who is listed as the domain registrant and the code needed to transfer it to another provider, access to the hosting control panel, an export of the website's content in a format you can reopen elsewhere, the source code if the site was custom built, and access to the email accounts on your domain. Ask in writing, not verbally, and before you give notice.

What can I do if my current provider doesn't reply or delays handing over access?

The first thing to check is whether you're actually the domain's registrant: if you are, you have the right to request the transfer code directly from your registrar, even without the cooperation of whoever manages the site. If the registrant turns out to be a different company or person, the priority changes: getting the domain reassigned to you comes before thinking about any transfer.

Do I have to change hosting too if I'm only switching who manages my website?

Not always. The domain, the hosting and whoever handles the content or the code can sit with three different providers, and changing one doesn't force you to touch the other two. The only question worth asking for each of the three is whether you're happy with it as it is, or whether it's worth moving too.

If the website was custom built, is the code automatically mine?

That's not a given, and it depends on what the contract you signed actually says. Before assuming you can reuse the code or have another provider review it, ask in writing whether you'll be handed a complete copy and whether you're free to use it: it's worth asking regardless of the answer you expect.

How far in advance should I start the process of switching providers?

Before giving notice on your current service, not after. Start the domain transfer request and the recovery of everything else while the relationship with your current provider is still formally active: it's the simplest way to avoid a gap where the site sits offline because neither provider is looking after it anymore.

BlogGuides

Switching website provider: what to ask before you say goodbye

Q: Do I need a specific code to change who manages my domain?

Yes. It's called the AuthInfo code, and it's required both by ICANN policy for generic domains like .com and .net, and by the .it Registry for .it domains: without that code the new provider cannot complete the transfer, no matter how cooperative your old provider is. It's the old provider's duty to hand it over on request from whoever is the registrant.

1 November 2026

Two colleagues in an office handing a document binder to each other across a table

Add as a preferred source on Google

One click, and Google will show my articles more often in your results.

It's almost never a matter of bad faith. You switch providers because the renewal price went up, because replies started taking too long, because the business has grown and you need someone more structured, or simply because you found an offer you like better. The decision itself isn't the problem. The problem is that a business website isn't one single thing: it's at least four different things, registered in different names, that need to be requested by their precise names before you say goodbye to whoever has been managing them so far.

Why the list comes first, not after the site has already gone dark

Whoever asks for everything up front, calmly, while the relationship with the old provider is still active, usually gets it without friction: it's a routine administrative request, not a dispute. Whoever realises too late, after notice has already been given, when the site is down and the old provider has no reason left to hurry, ends up chasing something they could have had in hand for weeks. The difference isn't in the attitude of whoever owes you the handover: it's in when you ask for it.

The domain: who can move it, and what it takes

The domain is the easiest piece to take for granted, because from the outside it looks like just an address. In reality it's registered to someone, the registrant, and that person or business holds legal control over it: they can authorise a transfer, must approve a change of provider, and receive the renewal notices. If you're not certain whether that's you or whoever built your site, the check is free and takes a couple of minutes with the whois tool, as I explain in who really owns your website and domain: how to check.

Once you know who the registrant is, moving the domain to another provider requires a specific code, called the AuthInfo code. It's required both by ICANN policy for generic domains like .com and .net, and by the .it Registry for .it domains: without that code, the new provider cannot complete the transfer. This is a technical requirement, not a courtesy: the old provider is obliged to hand it over on request from whoever is the registrant, it isn't their call whether to give it or not.

Hosting, if you're switching that too

The domain is the address; hosting is the space where the site's files actually live, with its own account and its own credentials, which can be registered to yet another person or business, separate from whoever holds the domain. I've written about real hosting prices in website hosting: what it really costs. If you're only switching who manages your content and the site stays on the same hosting, this part doesn't concern you. If you're moving hosting too, ask for access to the control panel and, above all, a complete backup of the files before the account gets closed: it's the simplest safety net to have, and the easiest one to forget to ask for.

The website's content: where it lives, and what format you can get it back in

Text, images, blog posts, product pages: all of it needs to be able to leave the system it was written in, not stay trapped behind a panel you're about to lose access to. If the site runs on a widely used system like WordPress, exporting is almost always a standard feature of the panel itself. If the site runs on something built specifically for that provider, the question to ask first is whether an export feature exists at all, or whether content will have to be copied over by hand, one piece at a time: that difference changes the timeline of the switch considerably, and it's better to know it before signing with the new provider, not after.

The code, if the site was custom built

If the site isn't built on a standard system but on code written specifically for it, the question of who can keep, reuse or have a copy of it reviewed doesn't have the same automatic answer for everyone: it depends on what the contract signed at the start of the relationship actually says. Don't assume either that the code is rightfully yours, or the opposite: ask in writing whether you'll be handed a complete copy of the source code and whether you're free to use it, even just to have it assessed by whoever might take over in the future. It's a question worth asking regardless of the answer you expect.

The email accounts on your domain

A business using addresses like info@yourdomain.com risks an easy-to-miss side effect: those mailboxes usually depend on the same DNS settings or the same hosting you're about to leave. Before closing anything, check where they're currently configured, whether you can export the mail already received, and what it takes to get them running again with the new provider without a day where mail reaches no one.

Connected tools: Analytics, Search Console, advertising

Visit statistics, ownership verification on Google Search Console, any advertising accounts linked to the site: if whoever built your site set these up, the account is likely registered under their name, not yours. It's not a problem as long as they stay reachable, but it's worth asking right away to be added as an owner or administrator, so the data history doesn't disappear along with the provider.

Timing: how to avoid a gap between one provider and the next

The most common mistake isn't forgetting one of the items above: it's asking for all of them, but only after notice has already been given to the old provider. At that point, the request becomes the last thing the departing provider has any interest in being quick about. The safer path is the opposite one: start the domain transfer request and the recovery of everything else while the relationship is still formally active, and only give notice once the new provider has confirmed they already have everything they need in hand.

The list, in short

Before saying goodbye to whoever currently manages your website, get this handed over in writing: the domain registration and the code to transfer it, access to the hosting panel if you're changing that too, an export of the content in a format usable elsewhere, the source code if the site is custom built, access to the email accounts on your domain, and administrator rights on connected tools like Analytics and Search Console. This isn't a list built to prepare for a conflict: it's the same documentation anyone running a business should have on hand at all times, regardless of when, or whether, they ever decide to switch providers.

If you'd like to talk through what's missing in your specific situation, that's something we can cover in a digital check-up: otherwise get in touch and let's work out where to start.