Comment migrer un serveur sur site vers AWS (guide simple)

Introduction

Les migrations d'On-prem vers AWS échouent moins à cause du calcul et plus à cause des lacunes de planification : objectifs de basculement peu clairs, dépendances négligées et tests précipités. Ce guide rend le processus facile à suivre tout en restant opérationnel. Vous définirez à quoi ressemble le succès, préparerez une zone de destination minimale, effectuerez des lancements de test AWS MGN, basculerez en toute confiance, puis optimiserez la charge de travail après sa mise en service.

Que devez-vous décider avant de migrer quoi que ce soit ?

Quelle stratégie de migration convient à ce serveur (les "7 Rs" d'AWS) ?

La façon la plus rapide de perdre du temps est de migrer la mauvaise chose. Avant d'installer un agent, décidez quelle stratégie de migration le serveur mérite afin de ne pas déplacer quelque chose qui devrait être retiré ou remplacé. En pratique, de nombreuses équipes commencent par le rehosting pour la rapidité, puis optimisent plus tard une fois que la charge de travail est stable dans AWS.

Cependant, cela ne fonctionne que lorsque le serveur est un bon candidat "tel quel" et ne créera pas de dettes techniques coûteuses immédiatement après la transition. Raccourcis de décision pratiques :

• Rehéberger : agissez rapidement avec un minimum de changements lorsque le temps est compté.
• Replatformer : conservez l'application mais apportez de petites modifications pour l'adapter à AWS.
• Refactor : réserver des efforts pour des éléments différenciateurs critiques pour l'entreprise.
• Rachat : remplacer par SaaS au lieu de migrer le serveur.
• Retirer/Conserver : supprimer les systèmes inutilisés ou maintenir des charges de travail contraintes sur site.

Un point de contrôle interne utile est de se demander si la charge de travail a un « avenir cloud ». Si le serveur sera plus tard décomposé en services gérés ou en conteneurs, documentez cela maintenant et considérez le rehosting comme une étape temporaire plutôt qu'un design permanent.

Quels sont les RTO/RPO, la fenêtre d'arrêt et les déclencheurs de retour en arrière ?

Les coupures réussissent lorsque le succès est mesurable. Définissez le temps d'arrêt acceptable et la tolérance à la perte de données, puis notez les conditions qui obligent à revenir en arrière. Cela maintient l'objectif de migration et empêche les équipes d'improviser pendant la fenêtre de coupure. Cela aide également les parties prenantes de l'entreprise à donner leur accord car elles peuvent voir exactement quel risque est accepté.

Définir et documenter :

• RTO : temps d'arrêt maximal acceptable.
• RPO : perte de données maximale acceptable.
• Fenêtre d'indisponibilité : lorsque vous êtes autorisé à basculer le trafic de production.
• Déclencheurs de rollback : conditions d'échec spécifiques (panne d'authentification, transactions échouées, incohérence des données).
• Mécanisme de basculement : DNS flip, commutateur de répartition de charge, modifications de routage/pare-feu.

Pour garder le plan de retour réaliste, spécifiez qui possède chaque action pendant la transition. Par exemple, une personne est responsable des modifications DNS, une autre de la validation de l'application, et une autre de la "décision de retour" basée sur les déclencheurs ci-dessus.

Que devez-vous préparer dans AWS et sur site en premier ?

Connectivité et bases de pare-feu pour la réplication

La réplication ne fonctionne que si l'environnement source peut atteindre AWS de manière cohérente. Les bloqueurs les plus courants sont les contrôles de sortie stricts, les proxies et l'inspection TLS qui interfèrent avec le trafic HTTPS sortant. Validez la connectivité tôt et maintenez le chemin réseau stable pendant la réplication initiale et les lancements de test. Dans de nombreux environnements, la réplication n'est pas "bloquée" complètement ; au lieu de cela, des pertes intermittentes ou une inspection des paquets provoquent un comportement instable qui est difficile à diagnostiquer par la suite.

Modèles de connectivité courants :

• Sortie Internet publique (la plus simple lorsqu'elle est autorisée)
• VPN site à site (courant pour la connectivité privée)
• Connexion directe (plus prévisible pour les environnements plus grands)

Vérifications préalables :

• Le HTTPS sortant fonctionne de manière fiable depuis le réseau source.
• Le comportement du proxy est compris et testé avec le flux de migration.
• Les équipes de sécurité approuvent la sortie requise pour la fenêtre de migration.

Si votre environnement est très sécurisé, ajoutez une courte étape de « validation du réseau » à votre plan de déploiement : validez les points de terminaison à partir d'un serveur pilote, puis répliquez cet ensemble de règles exact pour le reste du déploiement.

Liste de contrôle minimale pour la zone de destination AWS

Vous n'avez pas besoin d'une zone d'atterrissage parfaite pour commencer, mais vous avez besoin d'un objectif cohérent qui ne changera pas en cours de route. Gardez la construction minimale, mais délibérée, afin que les tests reflètent à quoi ressemblera le basculement. De nombreux problèmes de migration proviennent de raccourcis réseau "temporaires" qui deviennent permanents parce que personne n'a le temps de les reconstruire après le lancement.

Éléments minimum de la zone d'atterrissage :

• A VPC et sous-réseaux où les instances seront lancées (souvent test séparé vs production)
• Groupes de sécurité aligné aux flux d'application réels (éviter "ouvrir maintenant, corriger plus tard")
• IAM prêt pour les opérations de migration et l'accès et les outils du deuxième jour
• De base étiquetage la propriété et le suivi des coûts sont donc clairs après la transition

Il aide également à décider tôt comment les administrateurs accéderont aux instances (bastion, VPN , SSM) et comment l'accès Internet sortant sera fourni (passerelle NAT, proxy). Ces choix affectent le patching, les agents de surveillance et le dépannage dès le premier jour.

Liste de vérification de la préparation du serveur source

Une migration réussie dépend d'une source propre. Confirmez que la charge de travail est compatible avec la méthode que vous avez choisie, puis identifiez tout ce qui dépend d'hypothèses locales qui changeront dans AWS. C'est également ici que vous signalez les serveurs "cas spéciaux" qui peuvent nécessiter une séquence différente. Par exemple, un serveur de fichiers avec une activité d'écriture importante peut nécessiter une fenêtre de transition plus stricte et une validation plus rigoureuse des fichiers et des partages ouverts.

Vérifications de préparation qui préviennent les surprises :

• Compatibilité OS/charge de travail avec l'approche de migration
• Disque suffisant et I/O stable pour la surcharge de réplication
• Dépendances mappées : DNS , AD/LDAP , interne PKI/certificats bases de données, partages
• Brittleness cachée : adresses IP codées en dur, TLS obsolète, tâches planifiées peu courantes
• Cas spéciaux signalés tôt : contrôleurs de domaine, clusters, appareils, licence par dongle

Avant de quitter cette étape, capturez les éléments « doivent rester les mêmes » tels que le nom d'hôte, les exigences d'adresse IP ou les liaisons de certificat, car ceux-ci affectent directement vos paramètres de lancement AWS et votre séquence de basculement.

Comment migrer un serveur vers AWS avec AWS MGN ?

Initialiser MGN et définir les paramètres de réplication par défaut

Initialisez AWS MGN dans la région où le serveur fonctionnera, puis définissez les paramètres de réplication par défaut afin que l'exécution des vagues reste cohérente. Un modèle stable réduit la variance par serveur et rend le dépannage répétable. Considérez cela comme votre procédure opérationnelle standard pour la réplication, similaire à une image dorée dans un environnement virtualisé.

Définir les paramètres de réplication par défaut à l'avance :

• Stratégie de sous-réseau cible et placement réseau
• Groupe de sécurité de référence pour les instances lancées
• Comportement de stockage (mappage de volume, chiffrement attentes)
• Throttling de réplication pour protéger le trafic de production

Si vous savez déjà que la production nécessitera des paramètres différents de ceux des tests, définissez ces différences de manière explicite. De cette façon, les lancements de tests restent représentatifs sans exposer prématurément les réseaux de production.

Installez l'agent et complétez la synchronisation initiale

Installez l'agent de réplication sur le serveur source et confirmez qu'il s'enregistre avec succès. La synchronisation initiale est l'endroit où l'instabilité vous coûte le plus, donc évitez les changements inutiles et surveillez de près la santé de la réplication. C'est également à ce stade que les équipes bénéficient de la documentation du flux d'installation "connu pour être bon" afin de ne pas résoudre les mêmes problèmes à chaque vague.

Orientation opérationnelle :

• Maintenez le serveur stable pendant la réplication initiale (évitez les redémarrages si possible)
• Surveiller l'état de la réplication et résoudre les erreurs immédiatement
• Documenter la méthode d'installation afin que les futures vagues soient cohérentes.

Lors de la synchronisation initiale, surveillez non seulement la console de migration mais aussi les performances du serveur. La surcharge de réplication peut révéler des goulets d'étranglement de stockage ou des erreurs de disque qui étaient auparavant masquées dans l'environnement sur site.

Lancer une instance de test et valider

Un lancement de test transforme les hypothèses en preuves. Lancez l'instance de test, puis validez la santé de l'application de bout en bout, pas seulement le succès du démarrage. Utilisez une liste de contrôle afin que les tests soient reproductibles sur les serveurs et les vagues. Si les utilisateurs finaux se connecteront via TSplus Remote Access inclure une vérification du chemin d'accès dans la validation. La cohérence est importante car elle vous permet de comparer les résultats entre les charges de travail et de repérer des modèles, tels que des problèmes de résolution DNS affectant plusieurs serveurs.

Liste de contrôle de validation minimale :

• Le démarrage se termine et les services commencent proprement.
• Les tests de validation d'application réussissent pour les flux de travail clés
• L'authentification fonctionne (AD/LDAP/local)
• Les chemins de données fonctionnent (connexions DB, partages de fichiers, intégrations)
• Les tâches planifiées et les services en arrière-plan fonctionnent comme prévu
• Journaux et signaux de surveillance apparaître là où votre équipe des opérations s'y attend

Ajoutez une étape de plus que les équipes omettent souvent : validez comment les utilisateurs accéderont réellement à l'application, y compris le routage interne, les règles de pare-feu et tout système en amont. Un serveur peut être « sain » mais inaccessible en pratique.

Lancer la transition et finaliser

La transition est un changement contrôlé, pas un saut dans l'inconnu. Gel des modifications, lorsque cela est possible, exécutez le déplacement du trafic en utilisant le mécanisme prévu, puis validez en utilisant la même liste de contrôle que pour les tests. Gardez la propriété de retour explicite afin que les décisions soient rapides. Traitez cela comme un manuel répétable : moins vous improvisez, moins le risque est élevé.

Essentiels de l'exécution de la transition :

• Confirmer le gel des changements et le plan de communication
• Lancer l'instance de basculement et changer le trafic (DNS/LB/routage)
• Répéter la liste de vérification de validation en mettant un accent particulier sur l'intégrité des données
• Appliquez des déclencheurs de rollback si nécessaire et rétablissez le trafic proprement.
• Finaliser la transition et supprimer ou mettre fin aux ressources de test

Immédiatement après la transition, capturez ce qui a changé en production (nouvelles adresses IP, nouvelles routes, nouvelles règles de groupe de sécurité) et documentez-le. C'est l'information dont l'équipe des opérations a besoin lorsque quelque chose se casse des semaines plus tard.

Ce qui casse généralement et que devez-vous faire immédiatement après la transition ?

Sortie réseau, dépendances DNS/AD, et "le lift-and-shift n'est pas fait"

La plupart des échecs sont des échecs de dépendance. La réplication a tendance à se rompre sur les contraintes de sortie et de proxy, tandis que le comportement de l'application a tendance à se rompre sur l'identité, la résolution de noms et les certificats. Même lorsque le basculement réussit, le rehosting n'est que la première étape, pas l'état final. Sans une deuxième phase, vous vous retrouvez souvent avec un « héritage hébergé dans le cloud » qui coûte plus cher et est plus difficile à gérer.

Les points de rupture les plus courants :

• HTTPS sortant bloqué ou modifié par le proxy inspection TLS
• Changements de résolution DNS (problèmes de horizon divisé, règles de résolveur manquantes)
• Gaps de connectivité AD/LDAP depuis le VPC
• Chaînes PKI internes manquantes ou non fiables dans le nouvel environnement
• Points de terminaison codés en dur et hypothèses héritées sur les chemins de réseau local

Une simple atténuation consiste à tester l'identité et le DNS tôt avec un lancement pilote. Si ces fondamentaux fonctionnent, le reste de la validation de l'application devient beaucoup plus prévisible.

Stabilisation post-migration : sécurité, sauvegardes, surveillance, coût

Les 48 premières heures après la transition doivent prioriser la stabilité et le contrôle. Assurez-vous que la charge de travail est observable, récupérable et gérée de manière sécurisée avant de consacrer du temps à une optimisation plus approfondie. C'est également à ce stade que votre migration réussit à long terme, car de bonnes opérations de deuxième jour empêchent les résultats du type « nous l'avons déplacé, mais personne ne veut en être responsable ».

Actions immédiates après la transition :

• Confirmer que la surveillance/l'alerte est active et détenue
• Assurez-vous que les sauvegardes sont activées et effectuez une validation de restauration.
• Renforcez les groupes de sécurité et appliquez le principe du moindre privilège IAM
• Standardiser l'approche de mise à jour et l'accès administratif (chemins audités)
• Commencez à optimiser après avoir collecté des données d'utilisation réelles.
• Appliquer le marquage pour éviter la dérive des coûts "propriétaire inconnu"

Une fois la stabilité prouvée, planifiez un court examen d'optimisation pour chaque serveur migré. Même un léger passage sur les types de stockage, le choix de la famille d'instances et la stratégie de capacité réservée peuvent réduire considérablement les coûts.

Où se situe TSplus après avoir déplacé des serveurs vers AWS ?

Après que les charges de travail Windows s'exécutent sur AWS, de nombreuses équipes ont toujours besoin d'un moyen simple de publier des applications et des bureaux Windows aux utilisateurs sans construire une infrastructure VDI lourde. TSplus Remote Access fournit la publication d'applications et l'accès à distance au bureau pour les serveurs Windows dans AWS, sur site ou dans des environnements hybrides, avec une administration simple et une licence prévisible qui convient aux opérations des PME et du marché intermédiaire.

Conclusion

Migrer un serveur sur site vers AWS est le plus réussi lorsqu'il suit un runbook répétable : choisir la bonne stratégie de migration, valider les dépendances, répliquer en toute sécurité, tester de manière réaliste et effectuer la transition avec des déclencheurs de retour en arrière clairs. Une fois la production stable, concentrez-vous sur les opérations du deuxième jour : renforcement de la sécurité, validation des sauvegardes, surveillance et ajustement des ressources. Cela transforme un "déménagement" en une plateforme fiable et contrôlée en termes de coûts.