Une migration WordPress ne consiste pas seulement à copier un dossier et une base. Le site dépend souvent du domaine, des DNS, du certificat, des e-mails, des tâches planifiées, de services externes et de réglages propres au serveur. Une checklist partagée permet de savoir qui intervient, ce qui doit rester stable pendant la bascule et comment revenir en arrière si un contrôle échoue.
Pour relier ce guide à une mise en œuvre concrète, consultez la migration et la reprise d’un site WordPress : cette page présente l’inventaire, la copie, la bascule, les redirections et le retour arrière.
Inventorier avant de déplacer
Recensez les domaines, sous-domaines, zones DNS, certificats et redirections. Listez l’hébergement actuel, le futur environnement, les versions de PHP et de la base, l’espace utilisé et les limites utiles. Identifiez les tâches cron, caches, règles serveur, CDN, stockage distant et protections qui influencent le fonctionnement.
Dans WordPress, relevez le thème actif, le thème enfant, les extensions, les utilisateurs administrateurs et le code spécifique. Notez les licences, les comptes qui les détiennent et les services connectés : paiement, CRM, formulaires, SMTP, analytics ou API métier. Vérifiez les accès avant le jour prévu ; un mot de passe introuvable ne doit pas bloquer la bascule.
Définir responsabilités et fenêtre de changement
Attribuez un responsable pour la décision de bascule, le DNS, les tests et l’information des utilisateurs. Précisez qui peut autoriser un retour arrière. Pour une boutique ou un site avec espace membre, choisissez comment traiter les données créées entre la copie initiale et la mise en production.
Annoncez une période de gel ou organisez une synchronisation finale des commandes, comptes et contenus. Réduire la durée de vie des enregistrements DNS peut aider à préparer le changement, mais cette action doit être faite suffisamment tôt et vérifiée. La propagation ne se contrôle pas depuis WordPress.
Créer une copie complète et testable
Conservez une sauvegarde de l’environnement actuel avant intervention. Copiez les fichiers et exportez la base de façon cohérente. Gardez cette copie hors du nouvel hébergement afin qu’une erreur de manipulation ne touche pas toutes les versions.
Installez le site sur une adresse de test protégée. Adaptez les URL avec un outil qui respecte les données sérialisées de WordPress. N’effectuez pas de remplacement brut dans un export SQL sans comprendre son format. Désactivez l’indexation, les envois réels d’e-mails, les paiements et les webhooks pendant la recette.
Valider la compatibilité du nouvel environnement
Contrôlez la version de PHP, les extensions serveur, le moteur de base, les limites mémoire, la taille d’envoi et les droits de fichiers. Consultez les journaux PHP et serveur après chargement. Une migration peut révéler une dépendance ancienne masquée par l’environnement précédent.
Testez la connexion, les rôles, les médias, les permaliens, les formulaires, la recherche et les parcours propres au site. Pour une boutique, utilisez les modes de test des paiements et vérifiez les e-mails transactionnels sans contacter de vrais clients. Contrôlez aussi les tâches planifiées et intégrations avec des données maîtrisées.
Préparer DNS, HTTPS et messagerie
Documentez les enregistrements DNS avant modification. Vérifiez l’émission du certificat sur la nouvelle cible et les redirections entre variantes du domaine. La messagerie n’est pas automatiquement migrée avec WordPress : conservez les enregistrements MX, SPF, DKIM et DMARC si le fournisseur d’e-mail ne change pas.
Assurez-vous que les formulaires utilisent une configuration d’envoi compatible avec le nouvel hébergement. Une page qui confirme visuellement l’envoi peut masquer un message jamais remis. Réalisez des tests contrôlés vers des destinataires prévus.
Exécuter et contrôler la bascule
Au début de la fenêtre, effectuez la synchronisation finale, activez la configuration de production et modifiez les enregistrements convenus. Notez l’heure et chaque changement. Testez depuis plusieurs réseaux si nécessaire, car certains résolveurs peuvent encore pointer vers l’ancienne adresse.
Contrôlez les réponses HTTP, le certificat, l’administration, les formulaires, les paiements, les tâches et les journaux. Vérifiez que les protections de l’environnement de test ne bloquent plus l’indexation de la production. Ne supprimez pas immédiatement l’ancien hébergement : conservez-le pendant la période convenue, sans laisser deux sites accepter des transactions concurrentes.
Erreurs à éviter
- Découvrir le jour de la bascule que le DNS ou les licences sont gérés par un tiers absent.
- Oublier les e-mails parce qu’ils utilisent le même nom de domaine.
- Tester uniquement la page d’accueil.
- Faire des remplacements SQL qui corrompent des données sérialisées.
- Laisser l’environnement de test indexable ou capable d’envoyer de vrais messages.
- Fermer l’ancien serveur avant validation du retour arrière.
Checklist finale
- Accès, domaines, DNS, hébergements et responsables confirmés.
- Fichiers, base, licences, cron et services externes inventoriés.
- Sauvegarde complète isolée et procédure de retour définie.
- Copie testée sur le nouvel environnement.
- Données créées pendant la migration traitées.
- DNS, certificat, e-mails et redirections préparés.
- Parcours métier et journaux contrôlés après bascule.
- Ancien environnement conservé selon une durée convenue.
Faire préparer votre migration
Une bascule fiable commence par un inventaire et se termine par des contrôles documentés. Pour organiser la copie, les tests, le DNS et le retour arrière, consultez la prestation migration et reprise de site WordPress.