Inventorier le projet avant de réserver le déplacement
Utilisez un site de demande illustratif à client.example.com : les éditeurs publient des pages de projet, les visiteurs téléversent un brief, et une tâche planifiée exporte les demandes vers un système client. Déplacer ses pages publiques ne couvrirait qu'une partie du travail. Confirmez l'accès autorisé à la source et à la destination, les contrôles de domaine et les copies de récupération avant de fixer une date.
Pour chaque composant, consignez son propriétaire, sa version, son emplacement, ses dépendances et sa vérification d'acceptation. Gardez les emplacements des identifiants dans l'inventaire ; gardez les mots de passe et les clés privées dans le coffre de secrets approuvé.
Faites défiler horizontalement pour toutes les colonnes du tableau.
| Composant | Enregistrer avant de déplacer | Qui le confirme |
|---|---|---|
| Domaine et DNS | Bureau d'enregistrement, opérateur DNS, enregistrements actuels et TTL | Propriétaire du compte client |
| Application | Version, environnement d'exécution, extensions et méthode de déploiement | Mainteneur de l'agence |
| Données et téléversements | Base de données, chemins de téléversement, méthode de sauvegarde et dernière copie utilisable | Opérateur de données |
| Formulaires et intégrations | Destinataires, points de terminaison webhook et destination de test autorisée | Responsable du flux de travail client |
| Travail planifié | Cron ou planificateur, fuseau horaire, file d'attente et dernière exécution réussie | Mainteneur de l'agence |
Prouver la copie de récupération avant de toucher à la production
Restaurez dans une destination de test séparée, jamais par-dessus la base de données en production. Pour PostgreSQL, un dump SQL représente un instantané cohérent de la base de données, mais un dump d'une seule base n'inclut pas les rôles ou tablespaces à l'échelle du cluster. Consignez les objets de support requis par votre application. Cet instantané de base de données ne rend pas non plus automatiquement cohérents les téléversements copiés séparément. Documentation sur le dump SQL PostgreSQL.
Pour un projet WordPress, incluez ses fichiers et sa base de données. Si les URL changent, suivez ses conseils spécifiques à la migration : un rechercher-remplacer indiscriminé dans la base de données peut endommager les valeurs sérialisées. Répétez la méthode choisie sur la copie. Manuel de migration WordPress.
Enregistrez une demande connue et sa pièce jointe, restaurez-les, et vérifiez les deux via l'application. Gardez la sauvegarde originale protégée en dehors du serveur en cours de déplacement. Un transfert de fichiers terminé ne vaut pas acceptation de la restauration.
Répéter les flux de travail que le client remarquera
Testez à l'aide d'un nom d'hôte temporaire à accès contrôlé ou d'une correspondance de noms réservée aux opérateurs. Configurez l'application pour cette route de test, y compris HTTPS et les URL de rappel pertinentes. Empêchez la copie d'envoyer des messages de production, de traiter des paiements réels ou d'exécuter des planifications de production. Utilisez des enregistrements synthétiques approuvés plutôt que des données personnelles non nécessaires.
Rédigez un résultat attendu avant chaque vérification. Consignez réussite ou échec, l'emplacement des preuves et la personne qui les a examinées ; une capture d'écran de la page d'accueil ne peut pas remplacer l'ensemble de la grille.
Faites défiler horizontalement pour toutes les colonnes du tableau.
| Flux de travail | Résultat attendu | Preuves à conserver |
|---|---|---|
| Formulaire et pièce jointe | Une demande stockée et un fichier lisible ; destinataire de test uniquement | Identifiant d'enregistrement synthétique et observation de livraison |
| Webhook | Un événement de test approuvé atteint le consommateur de test prévu | Identifiant d'événement et résultat du consommateur |
| Export planifié | Une exécution contrôlée, fuseau horaire correct, pas de doublon de l'ancien serveur | Identifiant d'exécution et comparaison des enregistrements exportés |
| Routes éditeur et visiteur | Permissions attendues, redirections, ressources et comportement HTTPS | URL vérifiées et détails de toute défaillance |
Définir la dernière écriture sur l'ancien système
Pour cet exemple, l'agence propose une brève fenêtre de maintenance : suspendre la soumission et l'édition des demandes, arrêter l'ancienne planification d'export, terminer ou prendre en compte le travail en file d'attente, puis créer la copie finale de la base de données et des téléversements. Le client doit approuver la manière dont les visiteurs sont informés que les soumissions sont temporairement indisponibles.
Consignez l'identifiant de la dernière demande acceptée et l'heure d'arrêt des écritures. Validez que la destination inclut cet enregistrement et sa pièce jointe avant d'autoriser de nouvelles soumissions. Gardez la source incapable d'accepter des écritures indépendantes pendant que les réponses DNS peuvent différer. Un projet qui ne peut pas suspendre les écritures nécessite une conception de synchronisation spécifique à l'application ; n'en improvisez pas une pendant la bascule.
Tenir un journal des décisions DNS
Le TTL contrôle la durée de mise en cache des réponses DNS. L'abaisser au moment de la bascule n'invalide pas les réponses déjà mises en cache avec la valeur précédente ; préparez donc tout changement de TTL à l'avance et observez la transition depuis les réseaux concernés. Cloudflare note également que la mise en cache locale peut retarder un changement visible. Documentation sur le TTL DNS Cloudflare.
Consignez le nom et le type d'enregistrement, l'ancienne valeur, la valeur prévue, le TTL précédent, l'approbation, l'heure de changement et le résultat observé. Vérifiez les enregistrements IPv6 ainsi que les enregistrements IPv4 s'ils existent tous les deux. Préservez les enregistrements de messagerie non liés. Après le changement, vérifiez que le nom d'hôte public atteint l'application prévue et son flux de travail critique, pas seulement l'adresse IP prévue.
Faire du retour arrière une décision de données
Convenez de conditions d'arrêt concrètes : la dernière demande est manquante, les pièces jointes ne peuvent pas être ouvertes, la connexion échoue, ou un webhook atteint le mauvais destinataire. Avant que de nouvelles écritures ne commencent, un retour répété vers la source conservée peut être possible. Une fois que la destination accepte de nouvelles demandes, restaurer une ancienne sauvegarde ou inverser uniquement le DNS peut perdre ces enregistrements.
Si une condition d'arrêt apparaît après la réouverture, suspendez les écritures, conservez les deux copies et demandez à l'opérateur nommé de réconcilier les changements avant de choisir le système faisant autorité. L'approbateur client décide s'il faut poursuivre la récupération ou utiliser l'alternative convenue. Tenez un bref journal d'incident au lieu de basculer le DNS à plusieurs reprises.
Clore le déplacement avec des preuves et une responsabilité
Demandez au client d'examiner la grille d'acceptation. Confirmez un seul planificateur actif, le nouveau chemin de sauvegarde, la responsabilité des alertes et le prochain point de contrôle d'observation. Conservez la source pendant la période convenue, puis approuvez explicitement son retrait. Supprimez les accès temporaires et les données de test conformément à l'accord de projet.
Utilisez le résultat pour mettre à jour la fiche de responsabilité opérationnelle et budget du projet. Cette procédure organise le travail de votre équipe ; elle n'implique ni assistance à la migration incluse ni service ininterrompu.
Sources et révision
Les références techniques ont été vérifiées en septembre 12, 2026. Les exemples sont des exercices de planification ; la documentation logicielle citée n'établit pas les capacités de service PrivateHostLab.