Migrer un serveur vers AWS, ce n'est pas « déplacer une machine dans le cloud » : c'est rejouer votre infrastructure dans un modèle différent, où la moindre erreur d'évaluation se paie en downtime, en facture qui dérape ou en données mal protégées. Cette page décrit la méthode complète, du premier inventaire au dernier euro optimisé après la bascule, avec les outils réels, les durées par stratégie, le plan de cutover et de rollback, et un angle que le SERP français n'offre pas : quand AWS n'est pas le bon choix, et comment migrer sans vous enfermer.
Qu'est-ce qu'une migration de serveur vers AWS ?
Une migration de serveur vers AWS consiste à transférer une charge de travail hébergée hors d'AWS, sur un serveur physique installé dans vos locaux (on-premise), sur un serveur dédié loué chez un hébergeur (OVHcloud, Scaleway…), ou sur une machine virtuelle (VMware vSphere, Microsoft Hyper-V), vers l'infrastructure d'Amazon Web Services, le plus souvent sous forme d'instances Amazon EC2 adossées à des volumes Amazon EBS.
Le terme recouvre en réalité plusieurs niveaux d'ambition. Au plus simple, on réplique un serveur Windows ou Linux « tel quel » vers une instance EC2 : c'est le lift-and-shift. Au plus poussé, on profite du déménagement pour remplacer le serveur de base de données par un service managé (Amazon RDS, Amazon Aurora), externaliser le stockage de fichiers, ou redécouper l'application. Entre les deux existe tout un spectre de stratégies, formalisé par AWS sous le nom des 6R (devenues 7R).
Migrer n'est donc jamais une opération purement technique. C'est une décision d'architecture, de coûts et de conformité. Un serveur applicatif migré sans réflexion reste aussi fragile sur EC2 qu'il l'était sur votre baie VMware (avec, en prime, une facture mensuelle là où vous aviez un investissement amorti). À l'inverse, une migration bien cadrée devient le point de départ d'une modernisation : élasticité, automatisation, réduction de la maintenance matérielle, sécurité renforcée.
À retenir. La question n'est pas « comment déplacer ce serveur ? » mais « ce serveur doit-il être déplacé, et sous quelle forme ? ». Une migration réussie commence par un inventaire et un arbitrage, jamais par un outil de réplication. C'est ce cadrage qui sépare un projet maîtrisé d'un lift-and-shift qui coûtera deux fois le prix prévu.
Cette page traite la migration au niveau du serveur. Pour la vision d'ensemble d'un programme à l'échelle de l'entreprise, consultez notre pilier migration cloud en entreprise.
Rehost serveur : la stratégie dominante de cette page
Migrer un serveur vers AWS relève, dans la grande majorité des cas, du rehost (lift-and-shift) : on réplique le serveur Windows ou Linux « tel quel » vers une instance Amazon EC2 adossée à des volumes Amazon EBS, sans réécrire l'application. C'est le chemin le plus rapide et le moins risqué quand un bail de datacenter se termine, qu'un contrat d'hébergeur dédié (OVHcloud, Scaleway…) n'est pas renouvelé, ou qu'on veut « sortir d'abord, optimiser ensuite ». Son revers : sans rightsizing ni engagements ultérieurs, on hérite du sur-dimensionnement d'origine et la facture grimpe, d'où l'importance de la phase FinOps décrite plus bas.
Le rehost n'est qu'un des sept chemins possibles. Le replatform (par exemple basculer une base auto-gérée vers Amazon RDS) et le refactor (réécriture pour conteneurs ou serverless) relèvent davantage de la modernisation applicative. Pour l'arbre de décision complet, les 7R (Rehost, Replatform, Repurchase, Refactor, Retire, Retain, Relocate), le piège du lift-and-shift et le tableau de choix par type d'application, consultez la page de référence : le modèle 6R/7R de la migration cloud.
Le bon réflexe. Sur cette page, on traite la couche serveur : rehost par défaut, replatform là où le gain est évident et bon marché. Le refactor d'une application stratégique est un projet à part entière, qui relève de la migration d'application vers le cloud. Notre rôle d'indépendant est précisément de vous éviter le refactor inutile que personne n'a le courage de déconseiller.
Les phases d'une migration AWS : Assess, Mobilize, Migrate
AWS structure tout programme de migration en trois phases, issues de l'AWS Cloud Adoption Framework (CAF). Cette grille en trois temps évite l'erreur la plus commune : se précipiter sur les outils de réplication avant d'avoir compris ce qu'on migre.
- Évaluation (Assess). On mesure la maturité, le périmètre et l'analyse de rentabilité. Inventaire des serveurs, estimation du coût cible (TCO), analyse de rentabilité pour la direction. C'est la phase qui décide si et pourquoi migrer.
- Mobilisation (Mobilize). On bâtit les fondations et on lève les blocages. Construction de la landing zone, mise en place de la sécurité, montée en compétence des équipes, choix des outils, premier lot pilote. C'est la phase qui rend le comment possible.
- Migration & Modernisation (Migrate/Modernize). On migre par vagues, application par application, en appliquant la stratégie 6R retenue pour chacune, puis on optimise. C'est la phase d'exécution, et celle qui ne doit jamais commencer avant que les deux premières soient solides.
La tentation, sous pression de délai, est de fusionner Assess et Mobilize pour « gagner du temps ». C'est exactement ce qui produit les migrations ratées : on découvre les dépendances bloquantes une fois la bascule lancée, quand il est trop tard et trop cher pour reculer.
Découverte outillée : inventaire et dépendances côté AWS
La phase d'évaluation repose sur une activité que tout le monde sous-estime : la découverte. La méthode générique (pourquoi personne ne connaît réellement son parc, comment regrouper les serveurs en vagues cohérentes par dépendances et criticité) est développée sur la page de référence : méthode de cartographie des dépendances. Ici, on se concentre sur son outillage AWS.
AWS fournit deux outils pour industrialiser cette phase. AWS Application Discovery Service collecte, via un agent ou sans agent, les données de configuration et d'utilisation des serveurs ; ses données alimentent AWS Migration Hub, qui centralise le suivi du programme. AWS Migration Evaluator (anciennement TSO Logic) produit une analyse de rentabilité chiffrée : il modélise le coût AWS cible à partir de l'usage réel observé, pour objectiver la décision côté direction financière.
Retour d'expérience. Sur plus de 120 projets accompagnés, la découverte révèle presque toujours deux choses : un pourcentage non négligeable de serveurs candidats au Retire (personne ne les utilise plus), et au moins une dépendance critique non documentée qui aurait fait échouer la bascule si on ne l'avait pas trouvée à temps. Le temps passé en découverte n'est jamais perdu : c'est l'assurance du reste du projet.
Les outils de migration AWS
AWS propose une boîte à outils spécialisée selon ce que l'on migre : serveur, base de données, fichiers ou volumes massifs. Les confondre, ou en utiliser un seul pour tout, est une erreur classique.
| Outil | Usage principal | Note | |---|---|---| | AWS Application Migration Service (MGN) | Rehost de serveurs entiers (OS, applis) vers EC2 par réplication continue par blocs | Service de rehost recommandé par AWS ; gratuit 90 jours par serveur | | AWS Database Migration Service (DMS) | Migration de bases de données avec un downtime minimal (réplication continue) | Homogène et hétérogène ; combiné au SCT pour changer de moteur | | AWS Schema Conversion Tool (SCT) | Conversion de schéma et de code (procédures stockées) entre moteurs hétérogènes | Ex. Oracle/SQL Server → PostgreSQL/Aurora | | AWS Migration Hub | Tableau de bord central : inventaire, suivi des vagues, progression | Agrège Discovery Service, MGN et DMS | | AWS DataSync | Transfert de fichiers et de partages (NFS, SMB) vers S3, EFS, FSx | Pour les serveurs de fichiers | | AWS Snow Family (Snowball) | Transfert physique de volumes massifs de données (téraoctets à pétaoctets) | Quand le lien réseau est insuffisant pour transférer en ligne | | AWS Storage Gateway | Passerelle hybride stockage on-premise ↔ AWS | Étape de transition ou stockage hybride durable | | AWS Transform | Accélération de la migration et modernisation, notamment de charges VMware | Outil d'aide à la transformation .NET, mainframe, VMware |
AWS MGN est le cœur de réacteur d'un rehost. Il installe un agent léger sur le serveur source, réplique en continu ses blocs disque vers une zone de transit AWS, puis permet de lancer des tests de bascule sans toucher à la production. Le jour J, on coupe la source, on finalise la dernière synchronisation et on bascule sur l'instance EC2, d'où une fenêtre d'arrêt très courte. Sa gratuité pendant 90 jours par serveur couvre largement la durée d'un projet de migration normal.
Pour les bases de données, AWS DMS maintient la base source opérationnelle pendant qu'il réplique en continu vers la cible, ce qui réduit le downtime à la fenêtre de bascule finale. Lorsqu'on change de moteur (par exemple Oracle vers Aurora PostgreSQL), le SCT convertit d'abord le schéma et signale le code qui demande une réécriture manuelle.
La migration par vagues : Migration Factory et runbooks
À l'échelle de plusieurs dizaines de serveurs, on ne migre pas tout d'un coup. On organise le parc en vagues (waves) : des lots de serveurs liés par leurs dépendances, ordonnés du moins critique au plus critique. Les premières vagues servent de rodage ; les vagues critiques bénéficient de l'expérience accumulée.
Cette industrialisation porte un nom : la Migration Factory. L'idée est de transformer une opération artisanale et risquée en un processus répétable. Chaque type de migration (un serveur Windows applicatif, un serveur de fichiers, une base SQL Server…) reçoit son runbook : une procédure détaillée, pas-à-pas, qui décrit la préparation, la réplication, les tests, la bascule et le rollback. Le runbook est rejoué à chaque vague, affiné à chaque itération.
L'avantage est double. D'abord la fiabilité : ce qui est documenté et répété échoue moins que ce qui est improvisé. Ensuite la prévisibilité : une fois les premières vagues calibrées, on estime sérieusement la durée et le coût des suivantes. C'est cette approche qui rend une migration de parc pilotable plutôt que subie.
La landing zone : le socle indispensable avant de migrer
Voici l'erreur fondatrice que commettent la plupart des migrations bâclées : migrer des serveurs avant d'avoir construit le socle qui les accueille. On se retrouve alors avec des instances EC2 dispersées dans un compte AWS unique, sans gouvernance, sans isolation, sans traçabilité : une dette technique installée dès le premier jour.
La landing zone est l'environnement AWS multi-comptes, sécurisé et conforme, sur lequel viennent « atterrir » vos serveurs migrés. Elle se construit avec AWS Control Tower pour les besoins standards, ou avec le Landing Zone Accelerator on AWS (LZA) pour les charges fortement réglementées. Elle pose, avant toute migration : la structure de comptes (production, recette, sécurité), les identités centralisées (IAM Identity Center), la journalisation, le réseau, les garde-fous de gouvernance et le chiffrement.
Migrer sans landing zone revient à emménager dans une maison sans fondations ni serrures. Le concept générique (qu'est-ce qu'une landing zone et pourquoi la poser avant tout serveur) est traité sur la landing zone : la fondation avant de migrer ; cette page-ci, propriétaire du sujet pour le couple AWS, en détaille la déclinaison Control Tower. Le chantier s'inscrit dans une démarche plus large de gouvernance cloud. La règle est simple : le socle d'abord, les serveurs ensuite.
À retenir. Une landing zone se met en place en quelques jours et conditionne la sécurité et la lisibilité des coûts de tout ce qui suit. La sauter pour « gagner du temps » est le faux gain le plus coûteux d'un projet de migration. C'est typiquement la première chose que nous corrigeons lorsque l'on nous demande de reprendre une infrastructure cloud existante mal partie.
Migrer des serveurs Windows Server et Linux vers Amazon EC2
La migration d'un serveur vers Amazon EC2 suit, pour un rehost, une trame éprouvée avec AWS MGN, valable aussi bien pour Windows Server que pour Linux.
- Préparation de la cible. On dimensionne le type d'instance EC2 d'arrivée (famille, vCPU, RAM) à partir de l'usage réel observé en découverte, et non du dimensionnement d'origine, presque toujours surévalué. On prépare le réseau (VPC, sous-réseaux, groupes de sécurité) et les volumes EBS.
- Installation de l'agent et réplication. L'agent MGN réplique en continu les blocs disque du serveur source vers AWS, sans interrompre la production.
- Tests de bascule. On lance une instance EC2 de test à partir de la réplique, dans un réseau isolé, pour valider que le serveur démarre, que l'application répond et que les dépendances tiennent. On rejoue ces tests autant de fois que nécessaire, sans impact sur la source.
- Bascule (cutover). À la fenêtre planifiée, on finalise la dernière synchronisation, on arrête la source et on promeut l'instance EC2 en production. Le downtime se limite à cette fenêtre.
Les spécificités à traiter selon l'OS : pour Windows Server, la gestion des licences (BYOL ou licence incluse AWS), l'intégration à Active Directory et la conversion éventuelle de pilotes ; pour Linux, les paramètres de démarrage, les dépendances de paquets et les points de montage. Le driver injection assuré par MGN gère la compatibilité matérielle au démarrage sur EC2.
Cas particuliers : fichiers, Active Directory, legacy, VMware
Tous les serveurs ne se migrent pas comme un serveur applicatif standard.
- Serveur de fichiers. Plutôt qu'un rehost EC2, on transfère les données avec AWS DataSync vers Amazon FSx (pour les partages Windows/SMB), Amazon EFS (NFS) ou Amazon S3, un replatform qui supprime la gestion du serveur.
- Active Directory / Entra ID. On choisit entre déployer des contrôleurs de domaine sur EC2, utiliser AWS Directory Service (Managed Microsoft AD), ou s'appuyer sur une intégration hybride avec l'annuaire existant. Le choix dépend de l'architecture d'identité globale.
- Applications legacy. Une application ancienne, peu documentée, sans support éditeur, relève souvent du rehost prudent (on déplace sans toucher) ou du Retain (on ne migre pas tant qu'on n'a pas de plan). Le refactor d'un legacy mal connu est un piège.
- Parc VMware entier. Sortir d'un cluster VMware vSphere complet (après le séisme Broadcom 2026, arbitrage Amazon EVS vs EC2 via MGN) ne se traite pas comme un serveur isolé : licensing par cœur, HCX, conception réseau. Ce cas a sa page dédiée. Voir la sortie VMware vers AWS : EVS, EC2.
Migrer les bases de données : DMS et SCT
La base de données est presque toujours la partie la plus délicate d'une migration, parce qu'elle ne tolère ni perte de données ni downtime prolongé. Deux scénarios.
Migration homogène (même moteur des deux côtés, ex. PostgreSQL on-premise → Amazon RDS PostgreSQL) : AWS DMS réplique les données et garde la base source synchronisée par capture des changements (CDC) jusqu'à la bascule. Downtime réduit à la fenêtre finale.
Migration hétérogène (changement de moteur, ex. Oracle ou SQL Server → Aurora PostgreSQL) : on utilise d'abord le Schema Conversion Tool (SCT) pour convertir le schéma, les types de données et le code procédural (procédures stockées, triggers). Le SCT signale précisément ce qui ne se convertit pas automatiquement et demande une réécriture. Ensuite, DMS migre les données. Ce type de projet réduit la dépendance aux licences propriétaires (Oracle, SQL Server) mais demande des tests fonctionnels approfondis.
Le choix de la cible structure le bénéfice : Amazon RDS (base managée multi-moteurs : SQL Server, Oracle, MySQL, PostgreSQL, MariaDB) supprime l'administration courante ; Amazon Aurora (compatible MySQL/PostgreSQL) ajoute des performances et une résilience supérieures. Garder la base sur EC2 (auto-gérée) ne se justifie que pour des contraintes spécifiques de version ou de configuration.
Le bon réflexe. Une migration de base de données ne se valide pas sur « ça démarre » mais sur des tests de non-régression fonctionnels : intégrité des données, performances des requêtes critiques, comportement de l'application cliente. C'est là que se cachent les mauvaises surprises post-bascule.
Souveraineté et conformité : l'arbitrage que personne ne pose
C'est l'angle mort du SERP français, et pourtant la première question d'un DSI ou d'un RSSI sérieux : migrer vers AWS est-il compatible avec la souveraineté de mes données ? Nous le traitons sans parti pris, parce que nous sommes indépendants d'AWS.
Le point de tension est juridique. AWS est une société de droit américain, soumise au Cloud Act, qui autorise les autorités américaines à demander l'accès à des données détenues par une entreprise américaine, y compris stockées en Europe. Cette extraterritorialité crée une zone de friction avec le RGPD, même lorsque les données résident physiquement en Europe.
Plusieurs réponses existent, à pondérer selon votre sensibilité de données :
- La région AWS Paris (eu-west-3). Héberger vos serveurs en France maintient les données sur le territoire et réduit la latence. C'est nécessaire mais, juridiquement, pas suffisant face au Cloud Act : la résidence physique ne neutralise pas l'extraterritorialité.
- Le chiffrement maîtrisé. Chiffrer les données avec des clés que vous contrôlez (gestion de clés externalisée, modèles type External Key Store) limite l'exploitabilité d'un accès contraint.
- L'AWS European Sovereign Cloud. AWS développe une offre de cloud souverain européen, opérée par des entités européennes, conçue pour répondre aux exigences de souveraineté. C'est une réponse structurelle à suivre selon son calendrier de disponibilité.
- L'arbitrage avec d'autres fournisseurs. Pour des données réellement sensibles relevant de la souveraineté stricte, un acteur européen comme OVHcloud (de droit français, hors Cloud Act) peut être plus adapté, voire un modèle hybride. Nous le disons quand c'est le cas : c'est précisément ce qu'aucun prestataire mono-AWS n'a intérêt à reconnaître.
Conformité sectorielle réglementée
La souveraineté se double d'exigences métier selon le secteur :
- Santé (HDS). L'hébergement de données de santé impose un hébergeur certifié HDS. AWS dispose de la certification HDS sur des régions et services au périmètre précis : la migration doit rester dans ce périmètre, chez un partenaire certifié HDS. Voir notre accompagnement du secteur santé.
- Finance & assurance (DORA). Le règlement DORA impose la résilience opérationnelle numérique : tests, maîtrise du risque lié aux prestataires tiers, et réversibilité documentée. Migrer une charge financière vers AWS suppose de pouvoir démontrer que vous pourriez en sortir. Voir le secteur finance.
- ISO 27001. Une démarche ISO 27001 sur votre SI doit se prolonger dans l'architecture cible : séparation des rôles, traçabilité, gestion des accès.
Le détail des référentiels réglementaires (RGPD art. 28/32, HDS, DORA, NIS2, SecNumCloud : obligations et portée) est développé sur la page de référence : conformité RGPD, HDS, DORA et souveraineté en migration cloud ; on ne garde ici que la nuance propre à AWS. Cet arbitrage souveraineté/conformité se mène en conseil neutre, sans pousser AWS si votre cas appelle une autre réponse, et il s'inscrit dans une sécurisation de l'infrastructure cloud d'ensemble.
Quand AWS n'est pas le bon choix
Notre indépendance se mesure à notre capacité à vous déconseiller AWS quand il ne convient pas. Deux cas, propres à cette page, reviennent régulièrement.
D'abord la souveraineté stricte. Pour des données réellement sensibles relevant d'une souveraineté hors Cloud Act, un acteur de droit français comme OVHcloud, voire un modèle hybride, est souvent plus adapté. C'est l'arbitrage détaillé dans la section souveraineté ci-dessus, dont cette page est propriétaire dans le silo.
Ensuite les charges stables à faible élasticité. Quand le besoin est une infrastructure prévisible, sans pic ni scalabilité forte, une tarification au forfait (serveur dédié, OVHcloud) peut s'avérer plus économique que le modèle à l'usage d'AWS, dont la valeur tient justement à l'élasticité.
Reste l'arbitrage le plus fréquent : Azure ou AWS ? Pour un SI fortement Microsoft (Entra ID, Microsoft 365, SQL Server, .NET), regardez l'équivalent côté Azure : migration serveur vers Azure, que nous accompagnons tout autant en tant qu'architecte Azure. Le comparatif neutre tête-à-tête des deux plateformes (services, identité, FinOps, écosystème) est traité sur la page de référence : comparatif neutre Azure vs AWS pour migrer.
Notre conviction d'indépendant. Un prestataire qui ne recommande jamais autre chose qu'AWS ne fait pas de conseil : il fait du placement. Nous arbitrons Azure, AWS et OVH sur la base de vos contraintes (techniques, financières, juridiques) et nous l'écrivons noir sur blanc.
Réversibilité et anti-vendor-lock-in : restez propriétaire
L'enfermement (vendor lock-in) est le risque silencieux de toute migration : dépendance technique au fournisseur cloud, et dépendance au prestataire qui a construit l'infrastructure. Notre principe est sans ambiguïté : les comptes AWS sont à votre nom, l'infrastructure est décrite en Terraform versionné dans vos dépôts Git, la documentation d'architecture vous est remise et la réversibilité est documentée. Vous pouvez reprendre la main ou changer de prestataire à tout moment, sans dépendre de nous pour comprendre votre propre infrastructure.
La doctrine complète (clause de sortie, comptes à votre nom, IaC portable et plan de réversibilité exigé par DORA) est développée sur la page de référence : réversibilité et anti-vendor-lock-in. Nous l'appliquons aussi lorsqu'il faut reprendre une infrastructure cloud existante.
Le plan de cutover et la stratégie de rollback
La bascule (cutover) est le moment où le projet réussit ou échoue aux yeux des utilisateurs. C'est aussi ce que les contenus concurrents passent sous silence. Un cutover sérieux se prépare comme une opération chirurgicale, avec un plan B écrit avant d'entrer en salle.
Un plan de cutover documente :
- La fenêtre de bascule. Choisie aux heures de moindre activité (nuit, week-end), dimensionnée pour absorber un imprévu sans déborder.
- La séquence pas-à-pas. Gel des modifications sur la source, dernière synchronisation, arrêt de la source, promotion de la cible, repointage DNS/réseau, vérifications.
- Les tests de non-régression. Une liste de contrôle fonctionnelle : l'application répond, les transactions passent, les intégrations tiennent, les performances sont au rendez-vous. Validée par les référents métier, pas seulement par la technique.
- Les critères Go / No-Go. Des conditions objectives qui décident, à un point précis, si l'on poursuit ou si l'on déclenche le rollback. Pas de décision à l'intuition sous stress.
- Le plan de rollback. La procédure de retour arrière vers la source, maintenue disponible pendant toute la fenêtre. Tant que le rollback est possible, l'échec n'est jamais catastrophique : on revient, on analyse, on rejoue.
À retenir. Une migration sans plan de rollback documenté n'est pas une migration maîtrisée : c'est un pari. Le principe générique (plan de rollback et tests de non-régression comme filet de reprise sur échec) est posé sur la page de référence ; cette page-ci l'ancre dans le cutover opérationnel ci-dessus. Nous ne lançons jamais une bascule sans rollback disponible.
RTO, RPO et continuité d'activité pendant la migration
La migration ne doit pas dégrader votre continuité d'activité, ni pendant, ni après. Deux indicateurs cadrent l'exigence :
- RTO (Recovery Time Objective) : le temps de reprise acceptable, c'est-à-dire la durée maximale d'interruption tolérée.
- RPO (Recovery Point Objective) : la perte de données acceptable, c'est-à-dire l'écart maximal entre la dernière donnée sauvegardée et l'incident.
La réplication continue par blocs d'AWS MGN, comme la réplication CDC de DMS, permettent de viser un downtime réduit à la seule fenêtre de bascule et une perte de données proche de zéro : la dernière synchronisation précédant immédiatement l'arrêt de la source. C'est ce qui distingue une migration moderne d'un ancien export/import qui imposait des heures d'indisponibilité.
Au-delà de la bascule, la migration est l'occasion de (re)poser votre stratégie de continuité dans le cloud : sauvegardes immuables isolées, réplication multi-région pour les charges critiques, tests de reprise réguliers. C'est l'objet de nos démarches dédiées de PRA cloud et de PCA cloud. Une infrastructure cible qui n'a pas de plan de reprise n'est pas terminée, elle est seulement déployée.
Sécurité de la cible AWS
Migrer vers AWS déplace le périmètre de sécurité, il ne le supprime pas. Le modèle de responsabilité partagée d'AWS est la clé : AWS sécurise le cloud (l'infrastructure physique, l'hyperviseur, les services managés) ; vous restez responsable de la sécurité dans le cloud (vos OS, vos configurations, vos accès, vos données). Une migration mal sécurisée transfère vos vulnérabilités vers EC2, elle ne les corrige pas.
La sécurisation de la cible repose sur une chaîne cohérente :
- Identités sans clés statiques. IAM Identity Center pour la connexion humaine fédérée avec authentification multifacteur, des rôles plutôt que des clés d'accès permanentes.
- Chiffrement par défaut. Volumes EBS, snapshots, bases RDS et objets S3 chiffrés via KMS, au repos et en transit.
- Détection des menaces. Amazon GuardDuty pour la détection comportementale, AWS Security Hub pour la posture de conformité agrégée.
- Référentiels durcis. Application des CIS Benchmarks aux instances et aux comptes, pour partir d'une configuration durcie plutôt que des réglages par défaut.
- Journalisation centralisée et immuable des accès et des événements.
Cette posture s'inscrit dans une démarche plus large de sécurisation de l'infrastructure cloud. Migrer sans la traiter, c'est exposer dans le cloud des serveurs qui étaient au moins protégés par votre périmètre réseau historique.
FinOps post-migration : l'optimisation que personne ne pousse au bout
Voici où la plupart des prestataires s'arrêtent, à la bascule, et où le vrai gain commence. Un lift-and-shift livre souvent, le jour J, une infrastructure plus chère que l'ancienne : on a répliqué le sur-dimensionnement sans les optimisations du cloud. Le cadrage générique de ce business case avant/après, et le piège du lift-and-shift, est traité sur la page de référence : FinOps de migration et business case avant/après. Ici, voici les leviers propres à AWS qui rendent le run rentable après la bascule :
- Rightsizing. Redimensionner les instances EC2 sur la base de leur usage réel observé après quelques semaines, et non sur l'estimation initiale. C'est le premier gisement d'économies, souvent le plus important.
- Engagements (Savings Plans / Reserved Instances). Pour les charges stables et prévisibles, s'engager sur une durée (1 ou 3 ans) réduit fortement le coût par rapport au tarif à la demande.
- Instances Spot. Pour les charges tolérantes à l'interruption (traitements batch, environnements non critiques), les instances Spot offrent une réduction marquée sur le tarif à la demande.
- Extinction hors usage. Éteindre automatiquement les environnements de développement et de recette en dehors des heures ouvrées : on ne paie pas une machine qui dort.
- Tagging. Un étiquetage rigoureux dès la migration rend les coûts lisibles par application, par équipe ou par projet, sans quoi aucune optimisation ciblée n'est possible.
À retenir. Une migration sans phase FinOps est une migration à moitié faite. Le lift-and-shift sort de votre datacenter ; l'optimisation rend le cloud rentable. Les économies se constatent généralement dans les semaines suivant la bascule, à mesure que l'usage réel se mesure, mais elles ne tombent pas toutes seules : elles se pilotent.
C'est tout l'objet de notre démarche d'optimisation des coûts cloud et de l'accompagnement par un audit FinOps. Nous tenons à couvrir l'après-bascule, pas seulement le déménagement.
Gestion du changement et montée en compétence
Une migration technique réussie peut échouer humainement. Si vos équipes ne savent pas exploiter l'infrastructure cible, vous avez seulement déplacé le problème, et créé une dépendance au prestataire. La conduite du changement fait partie du projet, pas de ses options.
Elle s'organise autour de quelques principes : la constitution progressive d'un CCoE (Cloud Center of Excellence), équipe transverse qui porte les standards et diffuse les bonnes pratiques ; la formation des équipes d'exploitation aux services AWS qu'elles vont opérer ; la remise des runbooks et de la documentation pour rendre l'exploitation reproductible ; et un transfert de compétences organisé pour que votre autonomie grandisse au fil du projet plutôt que de fondre. Nous détaillons cette dimension dans notre page dédiée au Cloud Center of Excellence.
Erreurs fréquentes et pièges d'une migration AWS
Douze ans de missions et plus de 120 projets laissent un catalogue d'erreurs récurrentes. Les nommer, c'est les éviter.
- Sur-dimensionnement. Reproduire à l'identique le dimensionnement on-premise, calibré pour des pics et amorti depuis longtemps. Sur AWS, on paie ce sur-dimensionnement chaque mois. La cible se calibre sur l'usage réel observé.
- Lift-and-shift sans optimisation ultérieure. Le rehost est légitime, mais s'arrêter là, sans rightsizing ni engagements, garantit une facture supérieure à l'ancien coût.
- Sous-estimation des dépendances. Migrer un serveur sans son réseau de dépendances casse la chaîne applicative. La découverte n'est pas optionnelle.
- Migration sans landing zone. Déposer des serveurs dans un compte unique non gouverné installe une dette de sécurité et de coûts dès le départ.
- Refactor prématuré. Réécrire une application avant de la connaître, ou sans justification métier, transforme un déménagement en chantier sans fin.
- Cutover sans rollback. Basculer sans plan de retour arrière, c'est parier la production.
- Oubli du FinOps et de la conformité. Considérer la bascule comme la fin du projet, en laissant filer les coûts et en repoussant la mise en conformité.
Retour d'expérience. La majorité des migrations que l'on nous demande de rattraper n'ont pas échoué sur une difficulté technique exotique, mais sur ces fondamentaux négligés sous la pression du délai. Quelques jours de cadrage rigoureux épargnent des mois de correction. C'est aussi pour cela que nous proposons un audit d'infrastructure cloud avant tout engagement.
Checklist pré-migration et KPI de réussite
Avant de lancer une vague, une migration maîtrisée valide une liste de contrôle concrète :
- Inventaire exhaustif et cartographie des dépendances réalisés et validés.
- Stratégie 6R arbitrée pour chaque application du lot.
- Landing zone AWS en place, sécurisée et conforme.
- Cible dimensionnée sur l'usage réel observé, pas sur l'existant.
- Plan de cutover et plan de rollback écrits et validés.
- Tests de non-régression définis avec les référents métier.
- Fenêtre de bascule planifiée et communiquée.
- Stratégie FinOps et tagging définis avant la bascule.
La réussite se mesure ensuite sur des KPI objectifs, pas sur une impression :
| KPI | Ce qu'il mesure | Cible saine | |---|---|---| | Downtime constaté | Durée réelle d'indisponibilité à la bascule | Conforme ou inférieur à la fenêtre planifiée | | Dérive de coûts | Écart entre coût AWS réel et budget estimé | Maîtrisée, puis réduite par le FinOps | | Taux de bascule réussie | Part des vagues basculées sans rollback | Élevé, le rollback restant l'exception | | Perte de données (RPO réel) | Écart de données constaté à la bascule | Proche de zéro grâce à la réplication continue | | Autonomie de l'équipe | Capacité à exploiter sans le prestataire | Croissante au fil des vagues |
Combien coûte une migration de serveurs vers AWS ? Durée et livrables
Voici la transparence que le SERP français n'offre pas. Le coût d'une migration se décompose en trois postes : le projet (la prestation de migration), le run AWS (la facture mensuelle d'hébergement) et les outils (souvent gratuits).
Le budget projet
Le budget indicatif d'un projet de migration de serveurs vers AWS mené par Architecte Cloud se situe dans une fourchette de 12 000 à 35 000 €, établie sur devis selon le périmètre. Il dépend principalement de :
- le nombre de serveurs et de bases de données à migrer ;
- la stratégie retenue par application (un parc en rehost coûte bien moins qu'un projet de replatform/refactor) ;
- la complexité des dépendances et du réseau ;
- les exigences de conformité (RGPD seul, ou HDS / DORA) ;
- la présence ou non d'une landing zone à construire au préalable ;
- le périmètre de transfert de compétences souhaité.
Cadre de transparence. Cette fourchette est indicative, jamais un prix ferme : seul un cadrage permet d'établir un devis précis. Nos honoraires sont clairs et sans engagement caché, l'une de nos convictions d'indépendant.
L'effort et la durée par stratégie
L'effort dépend massivement de la stratégie. Pour fixer des ordres de grandeur par application :
| Stratégie | Effort indicatif (jours-homme/appli) | Durée typique | |---|---|---| | Rehost | 10 à 30 j/h | Quelques jours par vague | | Replatform | 50 à 150 j/h | Quelques semaines | | Refactor | 300 à 2 000+ j/h | Plusieurs mois (projet à part entière) |
À l'échelle d'un projet de migration de serveurs cadré (parc modéré, majorité en rehost et quelques replatform), la durée se situe typiquement entre 1 et 4 semaines, selon le volume de serveurs et la complexité. Les vagues critiques bénéficient du rodage des premières.
Le coût AWS (run mensuel)
La facture AWS mensuelle dépend de vos charges, principalement : les instances EC2 (calcul), les volumes EBS (stockage bloc), le transfert de données sortant, et les services managés éventuels (RDS, S3, FSx). Point important : AWS MGN est gratuit pendant 90 jours par serveur, ce qui couvre la durée d'un projet normal. L'outil de migration ne pèse donc quasiment pas sur le budget. Le vrai enjeu du run n'est pas le coût initial, mais l'optimisation FinOps qui suit la bascule.
Les livrables remis
- Les serveurs et bases migrés et opérationnels sur AWS, dans des comptes à votre nom.
- Le code IaC (Terraform) complet, versionné dans vos dépôts Git.
- La documentation d'architecture, les runbooks de migration et le plan de cutover/rollback.
- Le modèle de tagging et la configuration FinOps initiale (budgets, alertes).
- Le transfert de compétences et, si vous le souhaitez, un point d'entrée vers l'infogérance cloud d'entreprise.
Notre méthode d'accompagnement
Architecte Cloud est un intermédiaire indépendant qui cadre votre besoin et vous met en relation avec des prestataires d'expertise et d'infogérance cloud sur Microsoft Azure et AWS, du conseil à l'exploitation. Notre accompagnement de migration suit une trame éprouvée, alignée sur le Cloud Adoption Framework :
- Audit & cadrage. Inventaire, cartographie des dépendances, arbitrage 6R par application, analyse de rentabilité. Pas de solution sur étagère : un diagnostic d'abord. C'est l'objet de notre audit d'infrastructure cloud.
- Mobilisation. Construction de la landing zone, sécurisation, choix des outils, premier lot pilote.
- Migration par vagues. Exécution via runbooks, tests de bascule, cutover maîtrisé avec rollback disponible, lot après lot.
- Optimisation FinOps. Rightsizing, engagements, extinction hors usage, tagging, pour rendre le cloud rentable après la bascule.
- Transfert de compétences & run (optionnel). Documentation, formation, remise du code. Exploitation 24/7 si vous le souhaitez, sans jamais vous enfermer.
Ce qui nous distingue tient en trois mots : indépendance (conseil sans parti pris Azure/AWS, on dit quand AWS n'est pas le bon choix, coûts clairs), autonomie (tout ce qui est construit pour vous vous appartient : code IaC, comptes, documentation) et réversibilité (vous pouvez reprendre la main ou changer de prestataire à tout moment). Nos preuves : 12 ans d'expertise, plus de 120 projets accompagnés, plus de 40 clients, une satisfaction client reconnue. Microsoft Azure Partner (Solutions Partner : Infrastructure) et AWS Partner (Advanced Tier Services), prestataires qualifiés (certifications AWS DevOps Engineer Pro, AWS Solutions Architect, Azure Solutions Architect Expert, CISSP, FinOps Certified Practitioner), démarche ISO 27001, membre de la FinOps Foundation.
Prochaine étape. Une migration se décide sur un diagnostic, pas sur une brochure. Lancez votre audit en ligne ou contactez-nous : réponse sous 48 h ouvrées. Pour situer ce chantier dans une démarche globale, consultez notre pilier migration cloud en entreprise et nos services de migration cloud. Pour la couche applicative et la stratégie 6R, conformité et FinOps de migration, voyez la page de référence du silo.
FAQ
Comment migrer un serveur vers AWS ?
On suit quatre temps : une découverte (inventaire et cartographie des dépendances), le choix d'une stratégie 6R adaptée, la construction d'une landing zone d'accueil, puis la migration proprement dite. Pour un rehost, AWS MGN réplique en continu les blocs disque du serveur source vers EC2, permet de tester la bascule sans toucher à la production, puis on bascule lors d'une fenêtre planifiée. La clé est de cadrer avant de répliquer : une migration ne commence jamais par un outil, mais par un inventaire et un arbitrage.
Combien de temps prend une migration de serveur vers AWS ?
Pour un projet de migration de serveurs cadré (parc modéré, majorité en rehost), la durée se situe typiquement entre 1 et 4 semaines. Par application, un rehost demande 10 à 30 jours-homme, un replatform 50 à 150, un refactor de 300 à plus de 2 000. La durée réelle dépend du nombre de serveurs, de la complexité des dépendances et des exigences de conformité. Les premières vagues servent de rodage et accélèrent les suivantes.
Combien coûte une migration vers AWS ?
Le budget projet indicatif d'une migration de serveurs menée par Architecte Cloud va de 12 000 à 35 000 €, sur devis selon le périmètre (nombre de serveurs, stratégie 6R, dépendances, conformité, landing zone à construire). S'y ajoute la facture AWS mensuelle (EC2, EBS, transfert de données), distincte du coût projet. Bonne nouvelle : AWS MGN est gratuit 90 jours par serveur, donc l'outil de migration pèse peu. Le vrai enjeu de coût est l'optimisation FinOps qui suit la bascule.
Comment migrer un serveur on-premise vers Amazon EC2 ?
On dimensionne l'instance EC2 cible sur l'usage réel observé, on installe l'agent AWS MGN qui réplique en continu les blocs disque du serveur, on lance des tests de bascule dans un réseau isolé, puis on bascule lors d'une fenêtre planifiée en finalisant la dernière synchronisation. MGN gère la compatibilité matérielle au démarrage. Pour Windows Server, on traite les licences et l'intégration Active Directory ; pour Linux, les paramètres de démarrage et les dépendances de paquets.
Comment migrer une base de données SQL Server ou Oracle vers AWS ?
Pour une migration homogène (même moteur), AWS DMS réplique les données et synchronise la source jusqu'à la bascule, avec un downtime minimal. Pour une migration hétérogène (changement de moteur, ex. Oracle vers Aurora PostgreSQL), on convertit d'abord le schéma et le code avec l'AWS Schema Conversion Tool (SCT), qui signale ce qui demande une réécriture manuelle, puis DMS migre les données. La cible peut être Amazon RDS (base managée) ou Amazon Aurora. Des tests de non-régression fonctionnels sont indispensables.
Quels outils AWS utiliser pour migrer ses serveurs (MGN, DMS, Migration Hub) ?
AWS MGN (Application Migration Service) gère le rehost de serveurs entiers vers EC2 par réplication continue, gratuit 90 jours par serveur. AWS DMS migre les bases de données avec un downtime minimal, combiné au SCT pour changer de moteur. AWS Migration Hub centralise le suivi du programme. S'y ajoutent AWS Application Discovery Service pour l'inventaire, DataSync pour les fichiers, et Snow Family pour transférer physiquement des volumes massifs quand le réseau ne suffit pas.
Y a-t-il un temps d'arrêt (downtime) pendant la migration vers AWS ?
La réplication continue par blocs d'AWS MGN, comme la réplication CDC de DMS, permet de viser un downtime réduit à la seule fenêtre de bascule, planifiée aux heures creuses. La perte de données reste proche de zéro grâce à la dernière synchronisation précédant immédiatement l'arrêt de la source. C'est ce qui distingue une migration moderne d'un ancien export/import qui imposait des heures d'indisponibilité. Le downtime constaté fait partie des KPI de réussite d'un projet maîtrisé.
Comment migrer d'un serveur dédié OVH vers AWS ?
Le principe est identique à une migration on-premise : découverte (inventaire et dépendances), choix de stratégie, landing zone, puis réplication via AWS MGN vers EC2. L'agent fonctionne sur un serveur dédié comme sur une machine de vos locaux. Le point d'attention spécifique est le transfert de données (volume, bande passante du lien OVH vers AWS) et le repointage DNS lors de la bascule. Cela dit, en conseil neutre, nous vérifions d'abord que migrer d'OVH vers AWS sert réellement votre cas : pour des données souveraines, rester chez un acteur français peut être plus adapté.
La migration vers AWS est-elle conforme au RGPD et à la souveraineté des données ?
Héberger en région AWS Paris (eu-west-3) maintient les données en France et aide à la conformité RGPD, mais ne neutralise pas à lui seul le Cloud Act, qui soumet AWS au droit américain. Des réponses existent : chiffrement avec clés maîtrisées, AWS European Sovereign Cloud à venir, et pour des données très sensibles, l'arbitrage vers un acteur européen comme OVHcloud. La santé impose un hébergeur certifié HDS ; la finance, la résilience et la réversibilité exigées par DORA. Nous traitons cet arbitrage en conseil neutre.
Quelles sont les étapes d'un projet de migration vers le cloud AWS ?
AWS structure le programme en trois phases : Évaluation (Assess) : inventaire, cartographie, analyse de rentabilité ; Mobilisation (Mobilize) : landing zone, sécurité, outils, lot pilote ; Migration & Modernisation (Migrate/Modernize) : migration par vagues selon la stratégie 6R retenue, puis optimisation. L'erreur fréquente est de sauter l'évaluation pour gagner du temps : on découvre alors les dépendances bloquantes une fois la bascule lancée, quand reculer coûte cher.
Qu'est-ce qu'une landing zone AWS et pourquoi est-elle indispensable avant de migrer ?
Une landing zone AWS est l'environnement multi-comptes sécurisé et conforme sur lequel viennent « atterrir » vos serveurs migrés : structure de comptes, identités centralisées (IAM Identity Center), journalisation, réseau, garde-fous et chiffrement, le tout posé avant la migration. La construire avec Control Tower ou le Landing Zone Accelerator évite de disperser des instances EC2 dans un compte unique non gouverné : une dette de sécurité et de coûts installée dès le premier jour. La règle : le socle d'abord, les serveurs ensuite.
Migrer vers AWS ou Azure : comment choisir ?
Le bon cloud dépend de votre contexte. Pour un SI fortement Microsoft (Entra ID, Microsoft 365, SQL Server, .NET), Azure offre une intégration native de l'identité et des licences souvent décisive. AWS excelle sur l'élasticité, la profondeur de catalogue et les architectures cloud-natives. Pour des données souveraines strictes, un acteur européen comme OVHcloud mérite l'examen. En intermédiaire indépendant, nous arbitrons sur vos contraintes techniques, financières et juridiques, et nous le disons quand AWS n'est pas le bon choix.