L'hébergement mutualisé a du sens au démarrage : le prix est bas, le fournisseur gère le serveur et vous ne vous souciez que de vos fichiers. Mais le modèle a des limites strictes. Votre site partage le processeur, la mémoire et le disque avec d'autres locataires, vous ne pouvez pas installer les logiciels ou les extensions PHP dont vous avez besoin, et un voisin très actif peut ralentir vos pages. Lorsque vous avez besoin de ressources prévisibles, d'une adresse IPv4 dédiée et d'un contrôle total sur l'environnement, un VPS est l'étape suivante naturelle.
Déplacer des serveurs semble être une opération risquée, mais ce n'est pas une fatalité. L'astuce consiste à préparer le nouvel environnement pendant que l'ancien continue de fonctionner, puis à basculer seulement quand tout est testé. Cet article vous donne un plan étape par étape qui fonctionne pour les configurations d'hébergement mutualisé typiques : une application, une base de données, des tâches planifiées, des fichiers téléversés et des enregistrements DNS.
Open Vista propose des offres VPS NVMe facturées en dollars US sans engagement, de $9.99 par mois pour le VPS-1G jusqu'à $49.99 pour le VPS-5G. Chaque offre inclut une adresse IPv4 dédiée, un panneau de gestion, des sauvegardes automatiques et un support 24/7 en anglais et en français, et un serveur est déployé en moins de 15 minutes. Cette rapidité compte ici : vous pouvez préparer et tester votre environnement cible avant d'annoncer le moindre changement.
Étape 1 : inventorier l'existant avant de toucher à quoi que ce soit
La plupart des migrations échouées ne sont pas dues à des fichiers manquants, mais à des éléments qui n'ont jamais été consignés. Avant de commander quoi que ce soit, dressez un inventaire complet de ce dont votre site dépend :
- Fichiers web, répertoires d'uploads et de médias, avec les chemins exacts.
- Bases de données : moteur, noms, utilisateurs et tailles.
- Tâches planifiées (cron jobs) et commandes qu'elles exécutent.
- Règles de réécriture — `.htaccess` sur les hébergements de type Apache, ou règles nginx équivalentes.
- Variables d'environnement et secrets stockés dans les fichiers de configuration.
- Certificats SSL et domaines qu'ils couvrent.
- Enregistrements DNS : la zone complète, y compris les enregistrements A, CNAME, MX et TXT tels que SPF et DKIM.
- Boîtes mail, si l'e-mail est hébergé sur le même compte mutualisé.
Exportez une copie de la zone DNS avant de commencer. Notez les éléments qui dépendent des chemins internes de l'ancien hébergeur, car ce sont eux qui cassent lors d'un transfert. Cette liste vous aide aussi à décider de ce qui reste : de nombreuses équipes conservent le mail sur l'ancien hébergeur pendant que le site migre, et migrent les boîtes plus tard.
Étape 2 : préparer et tester le nouvel environnement VPS
Commandez l'offre VPS adaptée à la charge de travail. Pour la plupart des sites qui quittent l'hébergement mutualisé, le VPS-2G (1 vCPU, 2 GB RAM, 40 GB NVMe) est un point de départ confortable ; si vous exploitez plusieurs applications ou anticipez une croissance rapide, regardez le VPS-3G (2 vCPU, 3 GB RAM, 50 GB NVMe), l'offre la plus populaire. Comparez toute la gamme sur openvista.ma/en/vps et commandez sur my.openvista.ma.
Une fois le serveur déployé, préparez-le sereinement :
- Connectez-vous en SSH et créez un utilisateur non-root disposant des droits sudo.
- Configurez l'authentification par clé ; laissez la connexion par mot de passe désactivée ou restreinte.
- Appliquez toutes les mises à jour du système d'exploitation avant d'installer quoi que ce soit d'autre.
- Installez votre pile — serveur web, PHP ou votre runtime, base de données — et rapprochez-vous le plus possible des versions utilisées sur l'ancien hébergeur. Les écarts de version sont une source fréquente de surprises lors d'une migration.
- Configurez le pare-feu pour n'autoriser d'abord que SSH, HTTP et HTTPS.
- Vérifiez que les sauvegardes automatiques sont activées sur la nouvelle offre et sécurisez l'accès au panneau de gestion.
Faites tout cela avant le jour de la migration. Vous voulez une base saine et connue pour tester, pas un serveur à configurer pendant que votre site est censé basculer.
Étape 3 : déplacer les données en trois passes
Passe 1 — fichiers. Utilisez rsync via SSH. Il préserve les permissions et peut reprendre après une interruption :
```bash
rsync -avz --progress /path/to/public_html/ user@new-server:/var/www/your-site/
```
Exécutez-la plusieurs fois pendant la préparation, puis une dernière synchronisation juste avant la bascule. Pour de très grosses archives, un tar compressé transféré une seule fois fonctionne aussi.
Passe 2 — base de données. Exportez la base avec `mysqldump` (ou l'équivalent pour votre moteur), transférez le dump et importez-le sur le nouveau serveur. Créez un utilisateur applicatif dédié avec le strict minimum de privilèges nécessaires, puis vérifiez le nombre de lignes des tables clés.
Passe 3 — configuration. Mettez à jour les chemins, les valeurs de domaine et les secrets dans la configuration de l'application pour qu'ils pointent vers le nouvel environnement. Comparez les réglages PHP tels que `memory_limit` et `upload_max_filesize`. Surveillez les URL absolues codées en dur dans la base de données — prévoyez un recherche-remplacement minutieux. Testez l'application sur la nouvelle base avant le basculement DNS, à l'aide d'une entrée hosts locale ou d'un sous-domaine temporaire.
Documentez chaque modification manuelle au fil de l'eau, pour que le processus reste reproductible — et n'utilisez `--delete` dans rsync que lorsque vous êtes certain que la source est la copie de référence.
Étape 4 : basculer le DNS et mettre le site en ligne
- Réduisez le TTL des enregistrements à modifier au moins 24 à 48 heures à l'avance, pour que les nouvelles valeurs se propagent rapidement.
- Assurez-vous qu'un certificat SSL est déjà émis et fonctionnel sur le nouveau serveur ; HTTPS doit être opérationnel dès la première seconde de la bascule.
- Le jour de la bascule, faites pointer l'enregistrement A vers votre nouvelle adresse IPv4 dédiée.
- Surveillez les journaux de l'application, les logs d'erreur du serveur web et les connexions à la base de données pendant les premières heures.
- Maintenez l'ancien hébergement actif pendant la période de recouvrement — généralement deux à quatre semaines — et gardez une note de retour arrière : en cas de problème, repointer le DNS rétablit rapidement la configuration précédente.
- Ne modifiez les enregistrements MX, SPF et DKIM que si l'e-mail a migré avec vous. Si le mail reste sur l'ancien hébergeur, laissez ces enregistrements intacts.
Checklist après migration
- [ ] Toutes les pages se chargent en HTTPS sur le nouveau serveur.
- [ ] Les formulaires et les e-mails transactionnels fonctionnent ; SPF et DKIM vérifiés si le mail a migré.
- [ ] Les cron jobs s'exécutent et les journaux confirment leur succès.
- [ ] Sauvegardes automatiques confirmées actives sur le nouveau VPS.
- [ ] URL codées en dur remplacées et testées.
- [ ] Ancien hébergement toujours disponible pour un retour arrière.
- [ ] Note de retour arrière rédigée et stockée avec les identifiants DNS.
- [ ] Supervision et revue régulière des journaux planifiées.
FAQ
Combien de temps prend une migration de l'hébergement mutualisé vers un VPS ? Pour un site typique — quelques gigaoctets de fichiers et une base de données — le transfert prend de quelques minutes à deux heures environ selon la bande passante. Prévoyez une fenêtre de maintenance, mais comme le nouveau serveur est prêt avant le basculement DNS, l'essentiel du travail se fait sans impact pour les visiteurs.
Mon site subira-t-il une indisponibilité ? Pas du fait de la migration elle-même. La propagation DNS peut brièvement diriger certains visiteurs vers l'ancien hébergeur et d'autres vers le nouveau ; maintenir les deux en ligne pendant le recouvrement rend cela inoffensif. La vitesse de propagation dépend des résolveurs et du TTL que vous définissez.
Dois-je migrer l'e-mail en même temps ? Non. Si vos boîtes restent provisoirement sur l'hébergement mutualisé, laissez les enregistrements MX inchangés et migrez le mail plus tard. Seuls les enregistrements web changent le premier jour.
Et si quelque chose casse après la bascule ? L'ancien hébergement tourne toujours : vous pouvez repointer le DNS et diagnostiquer depuis une position stable. Comme le nouveau VPS dispose de sauvegardes automatiques, vous pouvez aussi restaurer et réessayer sans pression.
La migration est un projet ponctuel, mais l'hébergement que vous choisissez est une décision de long terme. Les offres VPS NVMe d'Open Vista sont facturées en dollars US sans engagement, et chaque offre comprend une adresse IPv4 dédiée, un panneau de gestion, des sauvegardes automatiques et un support 24/7 en anglais et en français. Retrouvez toute la gamme sur https://openvista.ma/en/vps et commandez votre serveur en quelques minutes sur my.openvista.ma.