Gérer des sites WordPress pour des clients nécessite un hébergement qui fonctionne sans intervention constante. Cependant, la crainte d’un temps d’arrêt, d’un enregistrement DNS erroné ou d’une perte de données peut vous faire hésiter et vous empêcher de procéder à un changement d’infrastructure nécessaire.
L’équipe de migration de Kinsta gère quotidiennement la charge de travail des agences, qu’il s’agisse de sites individuels à fort trafic ou de portefeuilles de clients complets. Ci-dessous, nous déconstruisons les mythes les plus tenaces sur la migration et montrons comment le processus de Kinsta fonctionne réellement dans des scénarios concrets.
Mythe 1 : La migration met vos sites hors ligne pendant des heures ou des jours
Le mythe : La migration vers un nouvel hébergement nécessite la mise hors ligne de vos sites pendant le transfert des fichiers et la propagation des DNS. Il en résulte des heures ou des jours d’indisponibilité qui ont un impact sur les clients et les revenus.
La crainte d’un temps d’arrêt prolongé est un obstacle important à la migration des agences. Les migrations d’hébergement classiques nécessitent souvent la mise hors ligne des sites pendant le transfert. Par exemple, les fournisseurs d’hébergement partagé ne disposent généralement pas de l’infrastructure nécessaire pour cloner les sites sans affecter la version en ligne.
La vérité
Le processus de migration de Kinsta ne nécessite jamais la mise hors ligne de votre site. L’équipe de migration clone votre site sur les serveurs de Kinsta tandis que votre site d’origine continue d’accueillir du trafic et de fonctionner.
La seule brève période de transition survient lorsque vous mettez à jour les enregistrements DNS. Pendant la propagation DNS, certains visiteurs peuvent atteindre votre ancien hébergement tandis que d’autres accèdent aux serveurs de Kinsta. Cette propagation se termine généralement en quelques minutes ou quelques heures, en fonction de votre fournisseur DNS et des réglages TTL. Cela signifie que vous pouvez planifier les mises à jour DNS pendant les périodes de faible trafic ou coordonner les changements en fonction des besoins spécifiques de l’entreprise.
Mythe 2 : Les changements de DNS vont interrompre votre site et vos services de messagerie
Le mythe : Le changement de DNS perturbe l’acheminement du courrier électronique, entraîne une inaccessibilité temporaire du site et crée des conflits entre les environnements d’hébergement.
Les changements de DNS peuvent créer de l’anxiété car ils représentent un point critique où les choses pourraient mal tourner. Cette inquiétude est légitime, car des migrations de DNS mal gérées peuvent provoquer des perturbations, mettre un site hors ligne ou créer des conflits entre les environnements.
La vérité
L’approche de Kinsta en matière de gestion des DNS permet d’éviter ces problèmes grâce à une vérification minutieuse et à des conseils clairs. Vous gardez un contrôle total sur le moment et la manière dont les enregistrements DNS sont mis à jour, ce qui vous permet de coordonner les changements avec votre équipe et vos clients à votre propre rythme.
L’impact pratique de la propagation des DNS est minime lorsque les deux sites servent la même version du site, d’autant plus que Kinsta clone votre site avant que vous ne mettiez à jour les DNS.
En ce qui concerne l’hébergement du courrier électronique, les enregistrements MX dirigent la livraison du courrier électronique et existent séparément des enregistrements A qui dirigent votre domaine vers l’hébergement web. De plus, si votre hébergement de messagerie est séparé de votre hébergement web, vos enregistrements n’ont généralement pas besoin d’être modifiés.
Le processus de vérification recommandé par Kinsta consiste à utiliser l’outil de prévisualisation du site avant la mise à jour, ce qui vous permet d’accéder à votre site migré à l’aide d’une URL temporaire. Vous pouvez tester les fonctionnalités, vérifier le contenu et les intégrations avant d’effectuer les changements DNS qui affectent les visiteurs.
Selon l’équipe de migration :
Dans nos messages post-migration, nous renvoyons à des articles sur le pointage des DNS que les clients peuvent consulter, puis contacter nos ingénieurs d’assistance pour toute autre question.
Mythe 3 : Votre configuration personnalisée est trop complexe pour être migrée en douceur
Le mythe : Les architectures WordPress personnalisées, les configurations non standard et les configurations spécialisées sont trop complexes pour être prises en charge par les plateformes d’hébergement infogérées ou se briseront lors de la migration.
Les agences construisent souvent des sites WordPress en utilisant des architectures non standard qui peuvent renforcer la sécurité, améliorer les performances ou rationaliser les flux de développement. Ces configurations personnalisées peuvent vous amener à penser que les plateformes d’hébergement infogérées ne les prennent pas en charge.
La vérité
L’équipe de migration de Kinsta gère régulièrement un large éventail de configurations techniques, de sorte que votre configuration personnalisée n’est probablement pas aussi unique qu’elle en a l’air.
Par exemple, les implémentations de Bedrock et Roots stack apparaissent fréquemment dans les migrations d’agences. Les réseaux multisites (qu’il s’agisse de sous-domaines, de sous-répertoires ou de domaines) font l’objet d’une vérification complète du réseau, de vérifications du mappage des domaines et de tests de fonctionnalité inter-sites au cours du processus de migration.
Lorsque les sites s’appuient sur des directives Apache uniquement, Kinsta les traduit en règles compatibles avec Nginx. Cela inclut la validation du comportement de réécriture, des redirections et des contrôles d’accès pour s’assurer que le site se comporte de manière identique en production. Comme l’explique l’équipe :
L’équipe Migrations a géré une variété de configurations telles que Bedrock/Roots, multisite et proxies inversés. Nous avons réussi à migrer des règles de redirection, des règles IP et des règles Nginx approuvées.
Et pour les cas particuliers, l’équipe construit des outils personnalisés. Une agence est arrivée avec plus de 800 règles de redirection stockées dans un ancien système sans option d’exportation. Les ingénieurs de Kinsta ont écrit un script pour extraire, normaliser et reformater les règles afin de les importer proprement dans le gestionnaire de redirection de Kinsta.
Mythe 4 : Vous perdez des données ou avez des liens cassés après la migration
Le mythe : Les migrations WordPress corrompent les bases de données, brisent les liens internes du site, endommagent les références des médias et provoquent des pertes de données qui nécessitent des corrections manuelles importantes.
L’intégrité des données est une préoccupation légitime car WordPress stocke des relations complexes dans sa base de données. Les données sérialisées (où les objets PHP sont stockés sous forme de chaînes de caractères) peuvent se briser si les URL changent sans traitement adéquat. Les liens internes, les références aux médias et les configurations des extensions dépendent tous d’informations précises sur le chemin d’accès et le domaine.
La vérité
Le flux de migration de Kinsta est conçu spécifiquement pour éviter ces problèmes, et tous les risques sont détectés avant que les changements de DNS n’affectent les visiteurs.
Le processus commence par une sauvegarde propre et compatible de votre site. En fonction de votre fournisseur actuel, l’équipe de migration utilise des outils de ligne de commande, phpMyAdmin, ou des exportations au niveau du panneau pour générer un instantané complet de vos données.
Une fois les données importées, l’équipe effectue une série de contrôles d’intégrité, notamment la vérification de la taille de la base de données, la conversion des anciennes tables MyISAM en tables InnoDB et la détection automatique des configurations multisites ou des sous-répertoires sur la base du fichier wp-config.php.
Les changements d’URL et les mises à jour de données sont gérés en toute sécurité en utilisant WP-CLI search-and-replace, et non des éditions SQL manuelles. Cela garantit que les tableaux sérialisés restent intacts. Les chemins d’accès à la médiathèque font l’objet d’une vérification manuelle, et l’équipe effectue des tests frontend et backend pour confirmer que les images et les fichiers joints se chargent correctement.
Le même niveau d’attention est appliqué au comportement des liens et aux URL codées en dur. Au cours de l’assurance qualité, l’équipe identifie tous les fichiers de thèmes ou d’extensions qui font référence à des chemins d’accès absolus. Si nécessaire, elle signale ces éléments et fournit des conseils sur la manière de les corriger en utilisant des pratiques de développement respectueuses de WordPress.
Comme l’explique l’équipe chargée des migrations :
Nous effectuons des contrôles d’assurance qualité pour nous assurer que le site migré reflète le site source. Il s’agit notamment de mettre à jour le référencement des domaines et des chemins d’accès. Nous vous ferons également des recommandations sur la manière de résoudre les problèmes liés à des thèmes ou à des extensions obsolètes.
Mythe 5 : La migration de grands sites ou de sites multiples prend des semaines
Le mythe : Les sites comportant de grandes bases de données, des bibliothèques de fichiers étendues ou des portefeuilles d’agences comprenant des dizaines de sites nécessiteront des semaines, voire des mois, pour être migrés avec succès.
Les agences qui gèrent des sites très volumineux partent souvent du principe que les migrations à grande échelle sont lentes et risquées. Cette croyance provient généralement d’expériences passées avec des fournisseurs d’hébergement qui ont une capacité de migration limitée ou qui n’ont pas d’équipe dédiée pour gérer des charges de travail complexes.
La vérité
Le flux de migration de Kinsta s’adapte aux portefeuilles de sites multiples et de grande taille sans créer de retards déraisonnables.
Grâce à une planification préalable adéquate, les délais restent prévisibles, même pour les très grands sites. Comme l’explique l’équipe de migration :
Grâce à une bonne planification préalable, nous sommes en mesure de respecter le calendrier du client. Pour les sites de grande taille, nous pouvons effectuer une migration en deux étapes : nous migrons les fichiers, puis, à une date ultérieure, nous migrons les fichiers plus récents et exportons la base de données afin de réduire la durée de la migration.
Un exemple de l’équipe est la migration d’un site de 300 Go, où la migration des fichiers a pris plus de 24 heures en raison de la lenteur de la connexion entre l’hébergeur sortant et Kinsta. L’équipe a migré les fichiers deux jours avant la date d’achèvement prévue, puis n’a migré que les fichiers les plus récents, ainsi que l’exportation de la base de données, le dernier jour.
Les migrations en masse suivent une approche structurée similaire :
- Vous recevez une feuille de calcul pour la migration groupée afin de fournir des détails sur chaque site du portefeuille.
- L’équipe s’efforce de migrer au moins huit sites par agence et par jour ouvrable, en adaptant la programmation en fonction de vos priorités.
- Une fois chaque lot terminé, l’équipe envoie des notifications afin que vous puissiez commencer à tester immédiatement.
Pour les sites de commerce électronique et de médias dont le contenu est constamment mis à jour, l’approche en deux étapes consiste à migrer un premier lot de fichiers, puis à effectuer une synchronisation finale du nouveau contenu et une exportation de la base de données juste avant tout changement de DNS. Cela permet de minimiser les divergences entre le site en ligne et la version migrée.
Préparer votre agence à une migration en douceur
Une bonne préparation permet d’accélérer les migrations et de réduire les risques de problèmes inattendus.
L’équipe de migration de Kinsta utilise une liste de contrôle pré-migration interne basée sur des années d’expérience et des milliers de migrations réalisées. Les agences peuvent s’inspirer de cette structure pour rendre le processus encore plus fluide.
- Alignez votre équipe et vos canaux de communication : Commencez par confirmer qui, dans votre équipe, participera à la migration. Partagez leurs adresses e-mail afin que Kinsta puisse les ajouter à un seul ticket de migration. Cela permet de centraliser les mises à jour et d’éviter une communication fragmentée pendant le processus.
- Vérifiez toutes les informations d’identification avant d’envoyer votre demande : Testez tous les identifiants dont dépendra votre migration :
- Accès au panneau d’hébergement
- Accès SSH ou SFTP
- Comptes administrateurs WordPress
En vous assurant à l’avance que ces identifiants fonctionnent, vous éviterez les retards une fois la migration commencée.
- Documentez les configurations personnalisées et tout ce qui sort de l’ordinaire : Plus l’équipe de migration a de contexte, plus vite elle peut reproduire votre configuration avec précision. Voici quelques détails utiles :
- Les règles de redirection personnalisées qui doivent être conservées
- Les tâches planifiées ou les tâches cron qui doivent continuer à fonctionner
- La nécessité d’un mode de maintenance pour les sites de commerce électronique
- Les configurations de serveur non standard ou les dérogations
- Toute restriction d’IP ou règle de contrôle d’accès actuellement en place
Ces éléments aident l’équipe à anticiper les cas extrêmes avant qu’ils ne surviennent.
- Fournissez des informations sur le DNS et le courrier électronique : L’accès au DNS devient important lors de la transition finale. Notez donc où votre DNS est géré et assurez-vous que les informations d’identification sont prêtes. Vous devez également préciser où se trouve l’hébergement de votre messagerie, par exemple Google Workspace, Microsoft 365 ou un fournisseur de messagerie distinct, car cela aide l’équipe à coordonner les enregistrements MX et à éviter les interruptions d’e-mail.
- Définissez les attentes des parties prenantes : Assurez-vous que toutes les personnes impliquées comprennent le processus de migration, le calendrier et si des temps d’arrêt ou des fenêtres de maintenance sont prévus. Une communication claire, que ce soit par l’intermédiaire de Kinsta ou de votre équipe interne, assure le bon déroulement du processus et évite les surprises de dernière minute.
Ce que cela signifie pour votre agence
La migration de sites WordPress ne devrait pas être risquée ou perturbante, pourtant des expériences d’hébergement dépassées ont conduit de nombreuses agences à penser le contraire.
L’équipe de migration de Kinsta existe pour rendre le processus prévisible, rapide et adapté aux complexités auxquelles les agences sont confrontées chaque jour.
Les obstacles étant levés, êtes-vous prêt à franchir le pas ? Explorez l’hébergement infogéré de Kinsta pour WordPress et découvrez comment notre programme de partenariat avec les agences soutient votre croissance.
Si vous avez des questions, notre équipe est toujours là pour vous aider.
Joel est un développeur d'interfaces publiques qui travaille chez Kinsta en tant que rédacteur technique. Il est un enseignant passionné par l'open source et a écrit plus de 200 articles techniques, principalement autour de JavaScript et de ses frameworks.
