Migrer de OVH vers o2switch sans coupure ni perte SEO

Ce que tu vas apprendre

Migrer un site d’OVH vers o2switch n’est pas compliqué en soi, mais chaque étape mal séquencée peut casser quelque chose : emails coupés pendant 48h, site inaccessible en pleine journée de vente, ou pire, un référencement qui dégringole parce que les redirections ont été oubliées. Ce guide déroule la procédure complète, dans l’ordre, pour un site WordPress ou tout autre CMS classique hébergé mutualisé. Il s’adresse aux PME qui gèrent elles-mêmes leur hébergement, ou qui veulent comprendre ce que fait leur prestataire avant de signer.

Prérequis

• Accès FTP/SSH et panel d’administration (cPanel ou équivalent) chez OVH
• Accès admin à ton CMS (WordPress, Prestashop, etc.)
• Accès au panel de gestion DNS de ton nom de domaine (OVH ou registrar externe)
• Un compte o2switch actif (offre Perso ou Pro selon le trafic)
• Une fenêtre de calme dans ton activité (éviter un jour de forte affluence e-commerce)
• Un client FTP (FileZilla) ou accès SSH, voir notre guide SSH : connexion serveur, clés et bonnes pratiques

1. Sauvegarder fichiers et base de données côté OVH

Avant tout, fais une copie complète et vérifiée de ton site.

Fichiers : connecte-toi en FTP ou SSH à l’hébergement OVH et télécharge l’intégralité du répertoire racine (souvent www ou le dossier de ton domaine). Pour un site volumineux, compresse d’abord côté serveur avec une commande type tar -czf backup.tar.gz www/ si tu as un accès SSH — ça évite de rapatrier des milliers de petits fichiers un par un.

Base de données : depuis phpMyAdmin (accessible via le panel OVH), exporte la base au format SQL, structure + données, encodage UTF-8. Si la base dépasse quelques centaines de Mo, préfère une exportation en ligne de commande (mysqldump) pour éviter les timeouts d’interface.

Vérifie que le fichier SQL n’est pas tronqué en l’ouvrant et en cherchant la ligne finale (-- Dump completed). Une base coupée en plein import provoque une erreur de connexion à la base de données WordPress qu’on préfère éviter.

2. Créer l’hébergement chez o2switch et importer le site

Connecte-toi à ton nouvel espace cPanel o2switch. Crée un compte de messagerie temporaire si besoin, puis importe :

1. Les fichiers : upload via FTP (FileZilla) ou décompression directe si tu as transféré une archive via le gestionnaire de fichiers cPanel.
2. La base de données : crée une nouvelle base MySQL dans cPanel, un utilisateur associé avec tous les privilèges, puis importe le fichier SQL via phpMyAdmin.
3. Le fichier de configuration (wp-config.php pour WordPress, parameters.php pour Prestashop) : mets à jour les identifiants de connexion à la nouvelle base (nom, utilisateur, mot de passe, hôte — souvent localhost chez o2switch).

À ce stade, ton site existe en deux exemplaires : l’original sur OVH toujours en ligne, la copie sur o2switch pas encore visible publiquement. C’est la clé d’une migration sans coupure.

3. Tester sur l’URL provisoire ou via le fichier hosts

o2switch fournit une URL temporaire (type IP/~utilisateur) ou tu peux modifier ton fichier hosts local pour pointer ton nom de domaine vers la nouvelle IP sans toucher aux DNS publics. Cette seconde méthode est préférable car elle te permet de tester le site avec son vrai nom de domaine, ce qui évite les soucis de liens absolus mal résolus.

Vérifie point par point :

• Pages d’accueil, articles, fiches produits
• Formulaires de contact (voir Formulaire de contact qui n’envoie rien si un souci apparaît)
• Panier et checkout si e-commerce (voir Erreurs WooCommerce courantes)
• Vitesse de chargement — profite de la migration pour vérifier le diagnostic complet de lenteur

Ne passe à l’étape suivante que si tout fonctionne à l’identique sur la copie o2switch.

4. Baisser le TTL DNS avant la bascule

C’est l’étape que presque tout le monde oublie, et celle qui cause les coupures visibles. Le TTL (Time To Live) définit combien de temps les résolveurs DNS gardent en cache l’ancienne adresse IP. Un TTL par défaut à 24h ou 3600s signifie que certains visiteurs continueront de voir l’ancien site (ou une erreur) pendant des heures après la bascule.

48h avant la migration, connecte-toi au panel DNS et réduis le TTL des enregistrements A et MX à 300 secondes (5 minutes). Cela oblige les résolveurs à revérifier fréquemment, donc à propager le changement bien plus vite le jour J.

Si tu gères tes DNS chez OVH ou ailleurs, la logique est la même qu’expliquée dans notre guide sur les DNS qui ne propagent pas.

5. Basculer les enregistrements DNS

Le jour de la bascule, une fois le TTL réduit et le test validé :

1. Modifie l’enregistrement A pour pointer vers l’IP du serveur o2switch.
2. Modifie les enregistrements MX si tu migres aussi les emails vers o2switch (voir étape 7).
3. Laisse le TTL bas pendant 24 à 48h après la bascule, puis remonte-le à une valeur standard (3600s ou plus) une fois la propagation confirmée stable.

Surveille la propagation avec un outil de vérification DNS public. Compte entre quelques minutes et quelques heures selon les résolveurs, rarement plus si le TTL a bien été abaissé en amont.

6. Réémettre le certificat SSL

Un certificat SSL est lié au serveur qui l’a émis. Une fois le DNS basculé vers o2switch, l’ancien certificat OVH ne suit pas — il faut en générer un nouveau côté o2switch, généralement via Let’s Encrypt intégré au cPanel (AutoSSL), gratuit et automatique dès que le domaine pointe correctement.

Vérifie l’activation en visitant ton site en HTTPS. Si tu obtiens un avertissement de certificat expiré ou invalide, consulte NET::ERR_CERT_DATE_INVALID ou ERR_SSL_PROTOCOL_ERROR pour diagnostiquer. Vérifie aussi qu’aucune ressource ne charge encore en HTTP pour éviter le contenu mixte.

7. Reconfigurer les emails

Si tes boîtes mail restent chez OVH (MX inchangés), rien à faire ici. Si tu migres aussi la messagerie vers o2switch :

• Crée les comptes emails dans cPanel avant de basculer les MX
• Exporte les emails existants (via un client IMAP type Thunderbird) et réimporte-les dans les nouvelles boîtes
• Mets à jour la configuration SMTP de ton site pour l’envoi transactionnel — voir configurer l’envoi SMTP ou passer par une API comme Resend
• Vérifie SPF, DKIM et DMARC après la bascule pour éviter que tes emails finissent en spam : voir le guide déliverabilité

8. Poser les redirections et couper l’ancien hébergement

Une fois tout validé côté o2switch, résilie l’hébergement OVH — mais pas tout de suite. Garde-le actif au moins deux semaines après la bascule DNS complète, le temps que la propagation soit totale et que tu confirmes l’absence d’erreurs résiduelles.

Si l’URL de certaines pages a changé (structure de permaliens différente, migration de CMS en même temps), pose des redirections 301 propres plutôt que de laisser des 404. Notre guide sur le changement d’hébergeur sans perdre son SEO détaille la logique de conservation du référencement dans ce contexte précis.

Migration assistée o2switch : quand la déléguer, quand la faire soi-même

o2switch propose un service de migration gratuit et assisté par leur support technique. Voici quand y recourir :

La migration assistée reste gratuite mais suit leur planning : compte parfois plusieurs jours d’attente. Si tu es pressé et à l’aise techniquement, la procédure manuelle prend souvent moins de temps.

Pièges courants

• TTL non réduit à l’avance : la bascule traîne 24h au lieu de 5 minutes, avec des visiteurs qui atterrissent tantôt sur l’ancien site, tantôt sur le nouveau.
• wp-config.php oublié : le site importé affiche une erreur de connexion à la base de données parce que les identifiants MySQL n’ont pas été mis à jour.
• SSL non réémis avant la bascule complète : les visiteurs tombent sur un avertissement de sécurité pendant les premières heures.
• Ancien hébergement résilié trop vite : impossible de revenir en arrière si un problème surgit après la bascule DNS.
• Emails coupés sans prévenir : bascule des MX en pleine journée ouvrée, messages perdus pendant la période de propagation.
• Liens internes en dur vers l’ancien domaine ou IP : certains thèmes ou plugins stockent des URLs absolues qui cassent après migration si la base n’est pas correctement remplacée (rechercher-remplacer dans la base, pas seulement dans les fichiers).

Une migration bien préparée se joue avant tout dans l’ordre des étapes, pas dans leur difficulté technique individuelle. Prends le temps de tester sur l’URL provisoire avant de toucher aux DNS : c’est la garantie de zéro coupure visible pour tes visiteurs.