Switching Web Host: Move Site and Email Without Downtime

Anyone switching provider is moving not one thing but four: the domain with its registration contract, the website with files and database, the mailboxes with their contents, and the DNS zone that ties everything together. These four parts belong together, yet they have to be handled separately in technical and contractual terms. Experience shows that a move rarely fails because a database dump goes wrong; it fails because somebody tries to move all four at once. What makes it harder is that responsibilities are often scattered: the domain is registered in the name of a former agency, the mailbox runs on a different contract, and the server credentials are known only to a colleague who left the company long ago. The first step of a change is therefore not a technical action but an inventory.

That inventory is larger today than it was ten years ago, because more parts are outsourced. According to the survey on the use of information technology in enterprises, around 54 percent (Federal Statistical Office) of companies with ten or more employees used paid cloud services in 2025, and among small businesses with ten to 49 employees the figure was 51 percent (Federal Statistical Office). Each of those services brings its own credentials, its own notice periods and its own export routes. At the same time the infrastructure in the country keeps growing: Germany operates around 2,000 data centres (Bitkom) with more than 100 kilowatts of connected load, and their total capacity rose to 2,980 megawatts (Bitkom) in 2025, up 9 percent (Bitkom) year on year. If you want to weigh up the merits of a domestic location, the legal and technical arguments are in our article on web hosting in Germany; the practical side is described on our page about hosting in a German data centre.

The domain is the only part a company can genuinely lose. It sits on a contract with a registry, and changing the provider that looks after it follows a defined procedure. For .de domains it is called a provider change and relies on a stored password, the AuthInfo. Since 2 February 2010 (DENIC) this is the only procedure applied: the outgoing provider deposits the code with the registry, where it stays valid for 30 days (DENIC). If the submitted code matches the deposited one, responsibility changes within minutes, without touching name servers or content. With a stock of more than 18 million (DENIC) .de domains this is routine, yet it regularly fails on outdated contact details: if the register lists an address that no longer exists, the code does not arrive.

For generic endings such as .com or .net, the ICANN transfer policy applies. It obliges the outgoing provider to respond to a transfer request within five days (ICANN) as a rule, and it locks a domain for 60 days (ICANN) against a further provider change after a transfer or a change of registrant. That lock is the reason a move cannot be squeezed in at short notice. On top of it come transfer locks that many providers set by default and that have to be lifted before the move. So plan the domain part as the first task, not the last. Reverse the order and you get the same surprises as in a poorly prepared rebuild, which we described in our article on the website relaunch without ranking loss.

Certificates are the break point that shows up fastest, because the browser puts up a warning page. In the old environment the certificate was renewed automatically; in the new one that automation has to be set up first, and it only works once the domain already points to the new server. The deadlines are getting shorter: the CA/Browser Forum has resolved to cap the maximum lifetime of publicly trusted TLS certificates at 200 days (CA/Browser Forum) from 15 March 2026, at 100 days (CA/Browser Forum) from March 2027 and at 47 days (CA/Browser Forum) from March 2029. A working automatic renewal is therefore no longer a convenience but a prerequisite for operation. Check in addition whether strict transport security is active, because then the browser will not forgive even a short gap. What else belongs to technical hardening is set out in our website security basics.

The second break point is redirects. They often live in a server configuration that does not come along when the directory tree is copied, because in the old environment it sat somewhere else. If they fall away, old addresses lead nowhere and hard-won visibility is lost step by step. The search engine documentation recommends keeping redirects in place for at least one year (Google Search Central) after a move. Language references are affected too: anyone running several language versions should check after the change whether the mutual references still line up, as we describe in our article on structuring and maintaining a multilingual website. The third break point is scheduled tasks: cron jobs for backups, feed imports, invoicing or clean-ups keep running in the old environment until the contract ends, and do not run at all in the new one until somebody sets them up. If you were planning to rebuild anyway, it makes sense to combine the move with a planned website relaunch.

A move exposes what was agreed in the contract and what was not. Software is protected by copyright, and rights of use do not arise on their own. Under the purpose-transfer principle in Section 31(5) (UrhG), the scope of granted rights is determined by the purpose assumed in the contract if the types of use are not listed explicitly. In case of doubt the scope stays narrow. For a company that wants to take its website along, that means: if you only agreed on the use of the running site, you do not automatically hold the right to keep operating the source code on another server, to modify it or to have a third party develop it further. Points like these belong in the contract before anything is built, not in a negotiation once the change is already under way.

The same applies to content. Text, photographs and graphics often come from different sources: your own shots, commissioned work, licensed material. Image licences are frequently tied to a particular use and do not travel along by themselves. So clarify before the change which images may continue to be used and for which a licence has to be acquired anew. A clean handover package contains the complete source code, the database, the media files, a list of the extensions in use with their version numbers, the licence records and the credentials. If you would rather hand that responsibility over for good, our website care with a named contact takes it on and keeps the inventory documented as it changes.