C'est toujours un moment assez délicat que le basculement de l'ancien site au nouveau site, si on veut que du point de vue de l'internaute, ce soit le plus transparent possible. Par transparence, comprendre :

  • sans erreur du genre serveur introuvable, ou page non trouvée
  • des messages d'un forum qui "disparaissent", dû à une mauvaise synchronisation du contenu des deux bases de données
  • des mails qui se perdent..
  • etc.

Pour éviter tout ces désagréments, il y a plusieurs étapes à respecter dans l'ordre, voici ce que je fais.

Installation et premier tests

La première chose à faire bien sûr, est d'installer les fichiers et la base de données du site sur le nouveau serveur. Je me sert d'un nom de domaine temporaire (souvent l'hébergeur en donne un, genre moncompte.hebergeur.com) pour tester la nouvelle installation. Je règle tous les détails comme les droits sur les répertoires, la configuration PHP (dans la mesure du possible) etc. Je vérifie l'envoi des mails à partir de l'application (si elle est susceptible d'envoyer des mails), et bien sûr, je teste tout le site en allant dans les moindre recoins, en testant la création d'un compte utilisateur si les internautes peuvent s'inscrire sur le site etc.

Au sujet du contenu de la base de donnée : ce n'est pas grave si le contenu n'est pas à jour par rapport au "vrai" site. L'intérêt pour le moment est de faire en sorte que tout fonctionne.

En général aussi, je bloque l'accès à ce nouveau site par un fichier .htaccess avec login/mot de passe, ainsi je suis sûr qu'il n'y aura pas méprise avec le "vrai" site, si un internaute tombe dessus par hasard. Je crée donc un fichier .htpasswd qui contiendra le login/mot de passe (en utilisant le programme htpasswd), et je met ceci dans un .htaccess à la racine du nouveau site :

 AuthType Basic
 AuthName "site test"
 AuthUserFile /chemin/vers/.htpasswd
 Require valid-user

Je crée aussi les nouvelles boites aux lettres et déclare le nom de domaine dans l'interface d'administration du site fourni par l'hébergeur, (ou je fait ça à la main si j'ai un accès ssh root à la machine). Pour le nom de domaine, je ne fais que déclarer au niveau du serveur ! Je ne change rien au niveau du registrar (ex, chez Gandi), c'est à dire que je ne vais pas encore changer l'ip du nom de domaine au niveau du registrar. Enfin je configure l'accès ftp et éventuellement d'autres petites choses spécifiques au site.

Le nouveau site fonctionne, je suis maintenant prêt à faire le basculement.

Fermeture du vieux site

La première étape va être de fermer le "vieux" site. Pour cela, je créé un répertoire, qui contiendra juste un fichier HTML indiquant que le site est fermé (ce que j'appelle une page bouchon), et je fais pointer le documentRoot vers ce répertoire (je ne supprime pas les fichiers du site, pour pouvoir revenir vite en arrière si il y a des problèmes). Certains CMS proposent aussi une fonction "fermeture du site", mais le CMS n'est pas forcément la seule application du site. Et puis il n'est pas certain que le CMS en question face les choses proprement au niveau code HTTP.

En effet, il ne faut pas oublier le référencement par les moteurs de recherches par exemple. Il faut leur indiquer que, non, les pages n'ont pas disparues (erreur 404), elles sont juste temporairement inaccessibles. Et puis il faut aussi rediriger les requêtes des internautes vers la page "bouchon", afin qu'ils ne se trouvent pas devant une page d'erreur 404, et afin qu'ils comprennent qu'il n'y a pas de problème, on est en train de déménager, revenez plus tard.

Pour tout ça, je rajoute un .htaccess au niveau de la page bouchon, dont le contenu est le suivant :

RewriteEngine on
RewriteCond %{REQUEST_URI} !=/images/accueil.jpg
RewriteCond %{REQUEST_URI} !=/css/accueil.css
RewriteCond %{REQUEST_URI} !=/index.html
RewriteRule ^(.*) http://%{HTTP_HOST}/index.html [R,L]

Cela indique à Apache que toutes les urls qu'on lui demande (^(.*)), sont redirigés temporairement (le R dans [R,L]) vers le index.html. Mais seulement si l'url demandée est différente de /images/accueil.jpg, /css/accueil.css et bien sûr /index.html (instructions RewriteCond). Ici accueil.jpg et accueil.css sont les fichiers utilisés pour la page index.html. Vous devez donc créer autant de directives RewriteCond sur le même modèle, que de fichiers nécessaires à l'affichage de index.html.

Migration de la base de donnée

Maintenant que l'ancien site est fermé, le contenu de la base de donnée sur l'ancien site ne va plus être modifié par qui que ce soit. Et puisque le nouveau site est inaccessible au premier venu, je ne vais donc pas avoir de problème de désynchronisation des données. Je peux donc récupérer ce contenu, et l'enregistrer dans la base de donnée du nouveau site en écrasant les tables qui ont servies de tests.

C'est le moment aussi, si il y a besoin, de synchroniser la liste les fichiers qui ont été crée dynamiquement (comme les images que l'on upload dans un CMS), entre le vieux site et le nouveau site.

Je fais un tour supplémentaire sur le nouveau site pour voir si tout fonctionne encore.

Basculement au niveau des DNS

C'est le moment le plus important du processus : le nouveau site va devenir opérationnel officiellement.

J'enlève d'abord le htaccess sur le nouveau site (celui qui demande le mot de passe), afin qu'il soit accessible publiquement. Si il y a des internautes qui tombent dessus tout de suite, ce n'est pas grave, l'ancien est fermé, donc pas de risque de désynchronisation des données.

Il est temps maintenant d'aller chez le registrar, pour changer l'adresse IP du nom de domaine. Une fois faite, la modification va se propager sur les serveurs DNS secondaires de la planète entière. En général, il faut compter 24h.

Pendant ce laps de temps, il va donc y avoir des internautes (ou des moteurs d'indexation) qui vont tomber soit sur le vieux site avec sa page bouchon, soit sur le nouveau site qui est maintenant opérationnel. Et bien sûr, ils seront de plus en plus nombreux à tomber sur le nouveau site au fur et à mesure que l'horloge tourne.

Migration des mails

Si vous avez des comptes mails rattachés au nom de domaine, il va falloir aussi faire la synchronisation entre les anciennes boite aux lettres et les nouvelles. C'est cependant plus compliqué qu'avec la base de donnée. En effet, pendant le temps de propagation de l'information des DNS, il va y avoir le même effet que pour l'accès au site web : il va y avoir des messages qui vont arriver sur le nouveau serveur, mais aussi des messages qui vont arriver sur l'ancien serveur. Si vous fermez trop tôt votre ancienne boite aux lettres, des mails vont être perdus.

Pour rapatrier les mails dans la nouvelle boîte aux lettres qui arrivent sur l'ancienne, il y a plusieurs solutions selon les habitudes :

  • Dans le client mail (au hasard, thunderbird), on peut créer un compte pour chaque boite mail, et on fait du drag and drop des messages de l'ancien vers le nouveau.
  • On peut utiliser des outils comme imapsync : vous leur indiquez les paramètres d'accès à la première boite aux lettres, les paramètres de la seconde, et ils transfèrent les mails de la première à la seconde. Bien sûr, il faut avoir un accès en IMAP aux boites aux lettres. Notez que c'est la seule bonne méthode quand on ne se sert que de webmail pour lire ses mails (à moins que lesdits webmails proposent une fonction d'importation/exportation).

Répétez ces opérations autant de fois que nécessaire pendant la période de basculement.

Fermeture définitive de l'ancien site

En général, je ferme définitivement l'ancien site 48h après le basculement du DNS. On peut toutefois vérifier que plus personne ne va sur l'ancien site en visualisant les statistiques de visites : quand c'est à zéro ou presque, c'est bon. La vérification des arrivages des mails dans les anciennes boites aux lettres permet aussi de constater si oui ou non tout les DNS sont à jour.

Une fois que la fermeture est possible, et que le nouveau site fonctionne bien, vous pouvez effacer vos fichiers, votre base de données, supprimer les boîtes aux lettres et fermer votre compte chez votre ancien hébergeur. Enfin, si vous pouvez (et voulez) récupérer les fichiers de statistiques, de l'ancien site, c'est le moment ou jamais.

Conclusion

Ce processus n'est pas forcément parfait, ni complet, puisqu'il peut y avoir des besoins spécifiques selon les sites, mais c'est à peu prés ce que je fais pour des sites en PHP/Mysql classiques. Petite note aussi, moi qui suit assez parano pour ça: profitez de ce déménagement pour changer tous les mots de passes (compte mail, mysql etc). Ne réutilisez pas les mots de passe de votre ancien hébergeur.