Migrer d’AWS vers OVHcloud : méthode, délais et économies

La question revient souvent de la même manière. Pas « AWS est-il un bon cloud ? », mais « est-ce qu’on paie le juste prix pour ce qu’on en fait ? ».

Beaucoup d’entreprises ont démarré sur un hyperscaler pour de bonnes raisons : rapidité de mise en route, catalogue immense, crédits de départ. Quelques années plus tard, la facture a grossi, l’architecture s’est complexifiée, et personne ne sait précisément ce qui coûte quoi.

Voici comment se déroule concrètement une migration vers OVHcloud : ce qui se transfère facilement, ce qui demande du travail, combien de temps cela prend et quelles économies attendre.

Les trois déclencheurs

La facture. C’est le premier motif. Entre les transferts de données sortants, les services managés facturés à l’usage et les environnements oubliés, le coût réel dépasse souvent largement l’estimation initiale.

La juridiction. Le Cloud Act permet aux autorités américaines d’accéder aux données hébergées par des entreprises américaines, où qu’elles soient stockées. Pour certaines activités, et pour répondre aux questionnaires de sécurité de vos clients, c’est devenu un point bloquant.

La réversibilité. Au 12 janvier 2027, les frais de changement de fournisseur cloud disparaissent complètement. L’obstacle financier à une migration tombe, ce qui en fait un bon moment pour instruire le sujet.

Ce qui se migre facilement

Soyons clairs : tout ne se vaut pas. Une bonne partie d’une infrastructure classique se transpose sans difficulté.

• Les machines virtuelles (EC2) vers des instances Public Cloud ou un cloud privé VMware.
• Le stockage objet (S3) vers l’Object Storage d’OVHcloud, compatible avec la même interface : vos applications n’ont souvent qu’une URL à changer.
• Les bases de données (RDS) vers les bases managées OVHcloud, en PostgreSQL, MySQL ou MongoDB.
• Les conteneurs (EKS) vers du Kubernetes managé.
• Le DNS et la diffusion de contenu, qui se reconfigurent en quelques heures.

Ce qui demande du travail

Le vrai sujet, ce sont les services propriétaires sans équivalent direct : fonctions serverless, files de messages spécifiques, briques d’intelligence artificielle maison.

Là, il ne s’agit plus de migrer mais de réécrire une partie du code, ou de remplacer le service par une alternative open source hébergée. C’est faisable, mais cela change la nature du projet : on passe d’une migration à une évolution d’architecture.

À retenir
La première question à se poser n’est pas « combien ça coûte ? » mais « quelle part de notre architecture repose sur des services propriétaires ? ». C’est elle qui détermine le budget et le délai.

La méthode, en cinq étapes

1. L’inventaire et l’analyse de dépendance

On liste chaque service utilisé, son volume réel et son coût mensuel. On identifie ce qui se transpose directement et ce qui demande une adaptation. À l’issue de cette étape, vous savez si votre projet se compte en semaines ou en mois.

2. La conception de la cible

C’est le moment de redimensionner. Reproduire à l’identique une infrastructure dimensionnée au fil des ans serait une occasion manquée : la plupart des environnements sont surprovisionnés. On définit aussi la sauvegarde, le plan de reprise et la supervision.

3. La migration d’un environnement test

On commence par un environnement de préproduction ou une application secondaire. On mesure les performances réelles, on ajuste, on documente la procédure. Cette étape évite les mauvaises surprises le jour de la bascule.

4. La bascule de production

Les données sont synchronisées en continu jusqu’au basculement, qui se fait sur une fenêtre courte, souvent la nuit ou le week-end. Le retour arrière reste possible : l’environnement d’origine est conservé quelques jours.

5. L’optimisation après migration

Un mois d’observation permet d’ajuster finement les ressources en fonction de l’usage constaté. C’est là que se gagne une part significative des économies.

Combien de temps ça prend

Les ordres de grandeur que nous constatons sur nos projets :

• Infrastructure classique, quelques dizaines de machines et une base de données : de six à douze semaines, dont une bonne moitié en préparation et en tests.
• Architecture avec services managés propriétaires : il faut y ajouter le temps de réécriture, qui dépend entièrement de votre code.
• La bascule elle-même : quelques heures, sur une fenêtre planifiée.

L’interruption de service, elle, se mesure en minutes quand la préparation a été faite correctement.

Les économies : l’exemple d’In Extenso

In Extenso, leader de l’expertise comptable, a migré son infrastructure d’AWS vers OVHcloud avec nos équipes.

Résultat : près de 25 % d’économies, des services complémentaires inclus, et une proximité avec nos équipes que le client met en avant.

L’écart vient rarement d’un seul poste. Il se construit sur trois leviers : une tarification à la ressource sans frais de transfert surprise, un redimensionnement au juste besoin, et l’arrêt des environnements qui tournaient sans raison.

Trois erreurs à éviter

• Migrer à l’identique. Reproduire une architecture surdimensionnée revient à transporter le problème ailleurs.
• Négliger le transfert des données. Sur de gros volumes, c’est souvent le poste le plus long et le plus coûteux de la migration. À chiffrer dès l’inventaire.
• Partir sans plan de retour arrière. Tant que la nouvelle infrastructure n’a pas tourné quelques jours en conditions réelles, l’ancienne reste en place.

À retenir
Une migration réussie ne se juge pas le jour de la bascule, mais un mois après : sur la facture, sur les performances, et sur le temps que vos équipes n’ont plus à passer sur l’infrastructure.

Faisons l’étude ensemble

Vous vous demandez ce que donnerait une migration dans votre cas ? Notre diagnostic gratuit dure 30 minutes : inventaire de vos services, identification de ce qui se transpose directement, estimation du délai et des économies. Vous repartez avec un compte rendu écrit, même si vous décidez de rester où vous êtes.

HostMe est OVHcloud Advanced Partner, avec deux datacenters français à Roubaix et Strasbourg, et une infrastructure certifiée ISO 27001.

Demander mon étude de migration