Moving a website from one provider to another without interruption

When moving a website from one provider to another you probably want to do this without any downtime, i.e. your users should not notice that the provider has changed. Here are a few tips for this process:

Moving static pages (html, css, …)

For moving static pages you can just copy them from your old webspace onto your new webspace, either using a program on your computer or directly. My old provider and my new provider offered ssh access. So I could just use rsync to copy the data from the old server to the new. I had to run a command like this on the new server:

rsync -rtv --links* www/

Later I could run it again to incrementally copy only changed files.

Creating an SSL certificate for the not-yet connected domain

Let’s say you are moving from one provider to another. You will need to setup an SSL certificate on the new provider before moving the domain there. Because otherwise there would be a downtime between moving the domain and setting up the SSL certificate. If your provider allows to manually enter a certificate and you cannot download the certificate from your old provider, you can use the “manual” mode of “Let’s encrypt” to create the necessary files. First you have to install Certbot. Then you can create a certificate like this:

mkdir certificate
cd certificate

mkdir logs
mkdir etc
mkdir work

certbot certonly -a manual -i apache -d --logs-dir logs --config-dir etc --work-dir work

During the process you will have to create a directory .well-known/acme-challenge on your old server and copy a file with a certain content into it. If you have ssh access it can look like this:

mkdir .well-known
cd .well-known
mkdir acme-challenge
cd acme-challenge
cat > thechallengefilename

Then copy&paste the content of the challenge file into the ssh shell and press CTRL-D and then CTRL-C. Afterward you can continue with certbot.

Then you should have four files in etc/live/

cert.pem    chain.pem   fullchain.pem   privkey.pem

You have to copy the contents of these files onto your new provider’s server as your new SSL certificate. It depends on your provider where you have to put it. E.g. on my provider there was a “manual” mode that allowed to copy cert.pem into the CRT field, privkey.pem into the PrivateKey field and chain.pem into the CAT field. Afterward the SSL certificate was successfully installed.

Moving PHP files and databases

If you have also dynamic content, e.g. PHP files and databases, you have the problem that during the transfer of your domain you cannot know which server a user will use. Because the DNS entry of your domain is saved on multiple DNS servers and it can take 24 hours until they all point to the same server, i.e. to your new server. During that time both servers will be used. However that could mean that some data would be saved into your old database and some into your new and you would have to merge both. To prevent this you can just forward all requests from your old server to your new server using a PHP script like this (from StackOverflow):



ini_set('display_errors', 1);

/* Set it true for debugging. */
$logHeaders = FALSE;

/* Site to forward requests to.  */
$site = '';

/* Domains to use when rewriting some headers. */
$remoteDomain = '';
$proxyDomain = '';

$request = $_SERVER['REQUEST_URI'];

$ch = curl_init();

/* If there was a POST request, then forward that as well.*/
    curl_setopt($ch, CURLOPT_POST, TRUE);
    curl_setopt($ch, CURLOPT_POSTFIELDS, $_POST);
curl_setopt($ch, CURLOPT_URL, $site . $request);
curl_setopt($ch, CURLOPT_HEADER, TRUE);

$headers = getallheaders();

/* Translate some headers to make the remote party think we actually browsing that site. */
$extraHeaders = array();
if (isset($headers['Referer']))
    $extraHeaders[] = 'Referer: '. str_replace($proxyDomain, $remoteDomain, $headers['Referer']);
if (isset($headers['Origin']))
    $extraHeaders[] = 'Origin: '. str_replace($proxyDomain, $remoteDomain, $headers['Origin']);

/* Forward cookie as it came.  */
curl_setopt($ch, CURLOPT_HTTPHEADER, $extraHeaders);
if (isset($headers['Cookie']))
    curl_setopt($ch, CURLOPT_COOKIE, $headers['Cookie']);

if ($logHeaders)
    $f = fopen("headers.txt", "a");
    curl_setopt($ch, CURLOPT_VERBOSE, TRUE);
    curl_setopt($ch, CURLOPT_STDERR, $f);

curl_setopt($ch, CURLOPT_FOLLOWLOCATION, true);
$response = curl_exec($ch);

$header_size = curl_getinfo($ch, CURLINFO_HEADER_SIZE);
$headers = substr($response, 0, $header_size);
$body = substr($response, $header_size);

$headerArray = explode(PHP_EOL, $headers);

/* Process response headers. */
foreach($headerArray as $header)
    $colonPos = strpos($header, ':');
    if ($colonPos !== FALSE)
        $headerName = substr($header, 0, $colonPos);

        /* Ignore content headers, let the webserver decide how to deal with the content. */
        if (trim($headerName) == 'Content-Encoding') continue;
        if (trim($headerName) == 'Content-Length') continue;
        if (trim($headerName) == 'Transfer-Encoding') continue;
        if (trim($headerName) == 'Location') continue;
        /* -- */
        /* Change cookie domain for the proxy */
        if (trim($headerName) == 'Set-Cookie')
            $header = str_replace('domain='.$remoteDomain, 'domain='.$proxyDomain, $header);
        /* -- */

    header($header, FALSE);

echo $body;

if ($logHeaders)


And you have to forward all requests to that file by creating a .htaccess file with the following content in the root directory of your old server’s webspace:

RewriteEngine On
RewriteRule .* proxy.php

The problem here is that you need a domain with a different name to forward the requests to. Or you could maybe enter your new server’s IP. I just created another domain (a subdomain of an existing domain that I had already transferred), e.g. and let it host the same files as my main domain. I.e. on the old server I still had the domain but now with the .htaccess and proxy.php files. On the new server I had and which both pointed to the same web directory and had the same contents.

This way the old could forward all requests to the new server using because “” was not accessible on the new server yet. When I then transferred the domain from the old provider to the new provider the on the new server started to receive requests and replaced the old server.

Before uploading the .htaccess file you have to copy (export/import) your databases from your old server onto your new server and enter the new database connections and passwords in your php files if necessary.

Moving email accounts

Just setup the same accounts on your new server that you had on your old server. Then use e.g. Thunderbird to connect to both servers and move the emails from one server to the other or just archive them on your computer.

Moving the domain name

When you move your domain name from one hoster to another you have to configure the nameserver on the target hoster to the same IPs as the original hoster first (until you are ready to make the switch). And when you have done that you should set the nameservers of your domain in the original hoster’s web interface already to the nameservers of your new hoster and wait 24 hours. Because what can happen is when you actually move your domain from one hoster to another that your original hoster will immediately remove your entries from their nameservers. So that clients that don’t know your new nameserver yet (because they are using an old cached response that says that your nameserver is the original nameserver) will ask the wrong nameserver and will get no answer. So you should do this:

  • When you are moving from hoster A to B then configure B’s nameserver in the same way as A’s nameserver (i.e. the same entries and IPs, just different nameservers).
  • Then open the web interface of hoster A and enter the nameservers of hoster B for your domain.
  • Wait 24 hours so that everyone knows the new nameservers.
  • Move your domain from hoster A to hoster B.


After all these steps you should have successfully moved your domain from one provider to another and the users shouldn’t have noticed it because there was no downtime.