Une migration OVH vers Microsoft 365 est souvent un moment sensible pour une PME. La messagerie sert aux devis, aux clients, aux relances, aux factures, aux rendez-vous et au support.
L’objectif n’est donc pas seulement de déplacer des mails.
Il faut préparer les boîtes, le domaine, les DNS, Outlook, les contacts, les calendriers, les boîtes partagées et la sécurité après bascule.
Exchange Online devient alors la nouvelle messagerie professionnelle dans Microsoft 365. Les utilisateurs travaillent avec Outlook, les calendriers partagés, les boîtes communes, Teams et les autres services Microsoft.
Une migration vers Exchange Online doit donc être traitée comme un projet de continuité de messagerie, pas comme une simple copie de messages.
Ce guide de migration ovh vers Microsoft Exchange est dédié aux PME de moins de 50 utilisateurs, et vise à guider les dirigeants en expliquant les éléments techniques à connaître et les pièges à éviter. Il ne vise pas à expliquer les étapes de A à Z, mais à vous aider à choisir, orienter et contrôler un prestataire afin de réaliser la migration.
Votre PME utilise encore une messagerie OVH et souhaite passer à Microsoft 365 sans perte de données ni interruption ? Axorys peut organiser, migrer et valider votre environnement Exchange Online.
Une PME peut vouloir quitter une messagerie OVH pour plusieurs raisons.
La première est souvent la centralisation.
Microsoft 365 regroupe la messagerie Exchange Online, Outlook, Teams, SharePoint, OneDrive, les comptes utilisateurs et les règles de sécurité dans un même environnement.
Cela devient utile quand :
MFA signifie authentification multifacteur. C’est une vérification supplémentaire lors de la connexion, au-delà du mot de passe.
Exchange Online apporte aussi une logique plus structurée pour les boîtes partagées, les calendriers, les délégations et l’administration des comptes.
Pour découvrir l’univers Microsoft, consultez le guide principal Microsoft 365 pour PME et les autres ressources sur Microsoft 365 en PME.
Avant de migrer, il faut identifier la source réelle.
OVH peut héberger le domaine, la messagerie, ou seulement une partie des services. Une entreprise peut avoir son nom de domaine chez OVH, mais ses mails ailleurs. Elle peut aussi utiliser MX Plan, Email Pro, Exchange hébergé OVH ou une boîte IMAP standard.
Avant de migrer, il faut identifier la source réelle : OVH peut héberger le domaine, la messagerie, ou seulement une partie des services.
OVH distingue notamment des offres et plateformes comme MX Plan, Email Pro, Exchange et Zimbra, avec des accès et des méthodes de migration qui varient selon la source et la destination. (OVHcloud Aide)
| Source OVH | Comment la reconnaître | Méthode de migration possible | Points de vigilance | Page Axorys liée |
|---|---|---|---|---|
| OVH MX Plan | Offre mail souvent liée à un hébergement OVH | Migration IMAP vers Microsoft 365 | Contacts, calendriers et fonctions collaboratives à vérifier | Audit Microsoft 365 PME |
| OVH Email Pro | Plateforme Email Pro dans l’espace client OVH | Migration selon accès IMAP ou export spécifique | Contacts, calendriers, règles et limites selon configuration | Migration vers Exchange Online |
| OVH Exchange hébergé | Plateforme Exchange dans OVHcloud | Migration selon méthode compatible Exchange ou IMAP | Délégations, boîtes partagées, calendriers et droits à contrôler | Support Outlook et Exchange |
| Boîte IMAP standard | Accès serveur IMAP, souvent configuré dans Outlook | Migration IMAP Microsoft 365 | Les mails migrent mieux que les contacts et calendriers | Checklist après migration Microsoft 365 |
| Domaine chez OVH avec mails ailleurs | DNS chez OVH, messagerie hébergée par un autre fournisseur | Dépend de la messagerie réelle | Ne pas confondre registrar, DNS et hébergeur mail | Administration tenant Microsoft 365 |
| Alias ou redirections OVH | Adresses qui redirigent vers une autre boîte | Recréation dans Microsoft 365 | Les alias et redirections doivent être inventoriés | Migration vers Exchange Online |
Cette étape évite une erreur fréquente : lancer une migration “OVH vers Microsoft 365” sans savoir si l’on migre vraiment des boîtes, des alias, une plateforme Exchange OVH ou une simple messagerie IMAP.
Une migration mail ne transfère pas toujours tout.
Les messages peuvent être migrés, mais certains paramètres doivent être recréés. Selon OVH, certaines migrations portent sur les données des comptes e-mail, comme les e-mails, contacts, calendriers ou règles, tandis que des fonctionnalités liées à la plateforme comme les alias, délégations, groupes, contacts externes ou pieds de page doivent être recréées sur la nouvelle plateforme. (OVHcloud Aide)
La migration des messages ne garantit pas que tous les paramètres de messagerie soient recréés automatiquement.
| Donnée ou paramètre | Migration possible ? | Risque ou limite | Vérification à faire |
|---|---|---|---|
| Emails | Oui dans la plupart des cas | Messages manquants si erreur IMAP, limite ou dossier spécial | Comparer volume, dossiers et échantillons |
| Dossiers de messagerie | Oui selon méthode | Structure parfois différente après migration | Vérifier les dossiers principaux et archives |
| Pièces jointes | Oui avec les emails | Limites de taille ou messages non migrés | Tester plusieurs messages avec pièces jointes |
| Contacts | Selon source et méthode | Non couverts par une migration IMAP standard Microsoft | Prévoir export/import ou recréation |
| Calendriers | Selon source et méthode | Non couverts par une migration IMAP standard Microsoft | Vérifier rendez-vous, partages et fuseaux horaires |
| Règles de boîte | Variable | Règles absentes ou non compatibles | Recréer les règles importantes |
| Alias | Souvent à recréer | Messages envoyés à d’anciennes adresses non reçus | Inventorier et recréer dans Microsoft 365 |
| Délégations | Souvent à recréer | Accès assistants, direction ou service perdus | Recréer et tester les droits |
| Groupes | Souvent à recréer | Listes de diffusion ou groupes absents | Recréer groupes et membres |
| Signatures | Souvent à recréer | Signatures locales Outlook non transférées | Vérifier poste par poste ou solution centralisée |
| Répondeurs automatiques | Variable | Répondeur absent après bascule | Recréer si nécessaire |
| Redirections | À recréer ou revalider | Messages qui continuent vers l’ancien service | Inventorier et tester |
| Boîtes partagées | À préparer dans Microsoft 365 | Accès, délégations et historique incomplets | Créer, migrer si nécessaire, tester |
Microsoft précise aussi qu’une migration IMAP ne migre que les éléments présents dans la boîte de réception et les autres dossiers mail ; elle ne migre pas les contacts, calendriers ou tâches. (Microsoft Learn)
C’est pour cela qu’un projet OVH vers Microsoft 365 doit distinguer les données, les paramètres et les usages Outlook.
Pour la validation utilisateur après bascule, le support Outlook et Exchange devient souvent indispensable.
Une migration réussie suit un ordre logique.
Elle ne commence pas par le changement du MX. Elle commence par l’inventaire.
Microsoft indique que, pour une migration IMAP, les utilisateurs doivent d’abord exister dans Microsoft 365 ou Office 365 avec une boîte cible, et que le domaine doit être ajouté dans Microsoft 365 si l’entreprise veut continuer à utiliser ce domaine. (Microsoft Learn)
Voici une trajectoire simple pour une PME :
Microsoft documente l’ajout d’un domaine personnalisé à Microsoft 365 et les enregistrements DNS à ajouter selon les services utilisés. (Microsoft Learn)
Pour les migrations IMAP, Microsoft indique qu’un fichier CSV peut contenir une ligne par utilisateur à migrer, avec l’adresse cible Microsoft 365, l’identifiant source et le mot de passe ou les informations d’accès selon le scénario. (Microsoft Learn)
Après la bascule, l’administration tenant Microsoft 365 prend le relais : comptes, licences, boîtes, sécurité, DNS, support et reporting.
Le domaine est au centre de la migration.
Le domaine, c’est la partie après le @ dans les adresses mail. Par exemple : entreprise.fr.
Les DNS sont les enregistrements qui indiquent aux services internet comment utiliser ce domaine.
Le MX est l’enregistrement DNS qui indique où livrer les emails.
SPF, DKIM et DMARC servent à authentifier les emails du domaine.
Autodiscover aide Outlook à trouver automatiquement la bonne configuration Exchange Online.
La migration des données et la bascule DNS sont deux moments différents. Modifier le MX trop tôt ou sans test peut créer une interruption de messagerie.
Microsoft précise qu’après la migration IMAP, le routage des emails vers Microsoft 365 se fait en changeant l’enregistrement MX, qui indique aux autres systèmes de messagerie où livrer les messages. (Microsoft Learn)
Le TTL, ou Time To Live, correspond au délai pendant lequel une information DNS peut rester en cache. Microsoft recommande de réduire le TTL du MX avant la migration pour limiter les délais de propagation lors de la bascule. (Microsoft Learn)
Les enregistrements à préparer sont généralement :
Microsoft explique que SPF utilise un enregistrement TXT dans le DNS pour identifier les sources autorisées à envoyer des mails pour un domaine, ce qui aide à réduire l’usurpation utilisée dans le phishing, le BEC ou les ransomwares. (Microsoft Learn)
Pour DKIM, Microsoft précise qu’il faut ajouter le domaine personnalisé à Microsoft 365 avant de configurer la signature DKIM. (Microsoft Learn)
Pour DMARC, Microsoft indique que l’activation se fait par la création d’un enregistrement TXT dans le DNS du domaine. (Microsoft Learn)
Pour approfondir ces points après migration, consultez la page SPF, DKIM et DMARC Microsoft 365.
Une coupure longue vient rarement d’un seul problème.
Elle vient souvent d’une accumulation : inventaire incomplet, DNS modifié trop tôt, Outlook non testé, utilisateurs mal informés, anciens alias oubliés ou erreurs IMAP non traitées.
La prévention repose sur une règle simple : tester avant de basculer.
| Risque | Cause fréquente | Prévention | Preuve à conserver |
|---|---|---|---|
| Emails non reçus | MX modifié trop tôt ou incorrect | Vérifier le domaine, préparer le MX, tester après bascule | Capture DNS et test de réception |
| Emails envoyés vers l’ancienne boîte | Propagation DNS ou TTL trop long | Réduire le TTL avant bascule et surveiller les deux environnements | Horodatage du changement MX |
| Outlook ne se connecte plus | Profil Outlook ancien, Autodiscover incomplet | Tester Outlook sur quelques postes avant généralisation | Liste des postes validés |
| Contacts ou calendriers manquants | Limite de la méthode IMAP | Export/import ou recréation selon source | Liste des éléments validés |
| Mot de passe incorrect | Accès IMAP non connu ou réinitialisé | Valider les accès avant migration | Résultat du lot de test |
| Erreur IMAP | Serveur, authentification, quotas, limite de connexion | Créer un lot test et analyser les erreurs | Rapport de migration |
| DNS mal propagé | TTL trop long ou modification incomplète | Préparer le TTL et vérifier plusieurs résolveurs | Captures de vérification DNS |
| SPF/DKIM/DMARC incomplets | Enregistrements absents ou mal formés | Configurer après ajout du domaine | Rapport DNS et test d’envoi |
| Utilisateurs non informés | Absence de communication | Prévenir le jour, l’heure et les actions à faire | Message de communication |
| Anciennes redirections oubliées | Inventaire incomplet OVH | Lister alias et redirections avant migration | Inventaire validé |
Microsoft indique qu’après l’exécution d’un lot de migration, il faut vérifier que les emails ont bien été migrés, puis vérifier le routage avant d’arrêter la synchronisation avec l’ancien système. (Microsoft Learn)
Le dépannage Outlook et Exchange devient utile si certains postes ne se reconnectent pas correctement après la bascule.
Une migration réussie n’est pas seulement un transfert de mails.
Elle doit être validée côté utilisateur.
Une migration réussie n’est pas seulement un transfert de mails. Elle doit être validée côté utilisateur dans Outlook, sur mobile et sur les boîtes partagées.
À vérifier après la bascule :
L’authentification moderne désigne les mécanismes de connexion récents de Microsoft, utilisés notamment pour le MFA et la sécurité des comptes.
Autodiscover permet à Outlook de détecter les paramètres Exchange Online sans configuration manuelle complexe.
Les boîtes partagées doivent aussi être testées : accès, envoi “de la part de”, envoi “en tant que”, calendrier partagé, signatures et droits.
Pour les incidents post-bascule, consultez Outlook ne se connecte plus à Exchange Online et Autodiscover Exchange Online.
La migration IMAP est souvent utilisée quand la source mail peut être lue via le protocole IMAP.
IMAP signifie Internet Message Access Protocol. C’est un protocole qui permet d’accéder aux emails stockés sur un serveur.
Il est utile pour transférer les messages et dossiers mail.
Mais il ne couvre pas tout.
Une migration IMAP est utile pour transférer les emails, mais elle ne couvre pas toujours l’ensemble des usages Outlook : contacts, calendriers, règles, délégations ou boîtes partagées doivent être vérifiés à part.
Microsoft précise qu’une migration IMAP permet de migrer les contenus de boîtes depuis un système source vers Microsoft 365 ou Office 365 lorsque le système source prend en charge IMAP, mais que ce type de migration ne migre pas les contacts, calendriers ou tâches. (Microsoft Learn)
Les limites à anticiper :
Microsoft indique aussi que les migrations IMAP utilisent des lots de migration et qu’il faut vérifier le résultat après exécution. (Microsoft Learn)
Après la migration, une checklist après migration Microsoft 365 permet de ne pas oublier les contrôles Outlook, DNS, sécurité et utilisateurs.
La bascule vers Exchange Online est le bon moment pour renforcer la sécurité.
La migration vers Exchange Online est le bon moment pour sécuriser Microsoft 365, pas seulement pour changer de messagerie.
Après migration, il faut vérifier :
Defender for Office 365 aide à renforcer la protection contre le phishing, les liens malveillants et certaines pièces jointes dangereuses.
La sauvegarde Microsoft 365 doit aussi être clarifiée. Microsoft 365 offre des mécanismes de rétention et récupération, mais cela ne remplace pas automatiquement une stratégie de sauvegarde adaptée à l’entreprise.
Les anciens comptes OVH doivent être traités selon le plan : conservation temporaire, suppression, arrêt du service ou accès en lecture pour contrôle.
Pour approfondir : cybersécurité Microsoft 365, MFA Microsoft 365 PME, Defender for Office 365 PME et sauvegarde Microsoft 365 PME.
Une migration mail doit laisser des traces.
Pas seulement “c’est fait”.
Une migration mail doit produire des preuves : ce qui a été migré, ce qui ne l’a pas été, ce qui a été recréé, ce qui reste à corriger.
Un prestataire doit pouvoir fournir :
Exemple de preuve utile : un tableau indiquant pour chaque utilisateur la boîte source, la boîte cible, le statut de migration, les erreurs éventuelles, la validation Outlook et les actions restantes. C’est simple, traçable et exploitable pour le dirigeant comme pour le prestataire.
Pour cadrer ce type de projet, consultez l’accompagnement migration Exchange Online.
Une migration OVH vers Microsoft 365 repose sur un partage clair des responsabilités.
Le client valide les décisions métier. Le prestataire prépare, migre, teste et documente. Microsoft et OVH fournissent les plateformes et les interfaces.
| Sujet | Client | Prestataire | Microsoft / OVH |
|---|---|---|---|
| Accès au compte OVH | Fournit ou valide l’accès | Utilise l’accès selon périmètre | Fournit l’espace client et les services |
| Accès DNS | Valide le domaine concerné | Prépare et modifie les enregistrements | Fournit l’hébergement DNS ou les instructions |
| Inventaire des boîtes | Confirme les utilisateurs et usages | Réalise l’inventaire technique | Fournit les interfaces de consultation |
| Décision des boîtes à migrer | Décide ce qui doit être conservé | Conseille et documente | Ne décide pas le besoin métier |
| Création du tenant Microsoft 365 | Valide les informations | Prépare le tenant | Fournit la plateforme Microsoft 365 |
| Licences | Valide les utilisateurs concernés | Attribue ou vérifie les licences | Fournit les plans Microsoft 365 |
| Migration des données | Valide le périmètre | Lance, suit et corrige | Fournit les outils ou protocoles disponibles |
| Bascule MX | Valide le créneau | Modifie ou accompagne la modification | Fournit les DNS ou la cible MX |
| Tests utilisateur | Valide le bon fonctionnement métier | Teste Outlook, mobile, envoi, réception | Fournit les services mail |
| Sécurité post-migration | Valide les priorités | Configure MFA, DNS mail, sécurité | Fournit les fonctionnalités |
| Support après bascule | Remonte les incidents | Traite les demandes | Fournit support éditeur selon contrat |
| Fermeture ou conservation de l’ancien service | Décide la durée | Documente et accompagne | Permet la conservation ou fermeture selon offre |
Ce tableau évite les malentendus.
Une migration ne doit pas dépendre d’une seule personne qui connaît “à peu près” les mots de passe, les DNS et les boîtes actives.
Pour un accompagnement local, consultez la page prestataire d’infogérance à Paris.
Une petite migration peut parfois être gérée en interne.
Mais dès que la messagerie est critique, le risque augmente.
Il devient pertinent de confier la migration OVH vers Exchange Online à un prestataire quand :
Le prestataire ne sert pas seulement à “faire la migration”.
Il sert aussi à préparer, tester, documenter, sécuriser et accompagner les utilisateurs.
Après la bascule, l’infogérance Microsoft 365 après migration permet de suivre les comptes, les licences, les boîtes partagées, les incidents Outlook, les DNS mail, la sécurité et les sauvegardes.
Oui, une messagerie OVH peut être migrée vers Microsoft 365 dans de nombreux cas. La méthode dépend toutefois de l’offre utilisée : MX Plan, Email Pro, Exchange OVH, IMAP standard ou autre configuration. Il faut d’abord identifier la source réelle et le périmètre à migrer.
OVH MX Plan est une offre de messagerie OVH souvent utilisée avec un hébergement ou un domaine OVH. Exchange Online est la messagerie professionnelle de Microsoft 365, avec intégration Outlook, calendriers partagés, boîtes partagées, administration centralisée et sécurité Microsoft 365.
Les principaux DNS à préparer sont le MX pour router les mails vers Exchange Online, le TXT de vérification du domaine, SPF pour les sources d’envoi autorisées, DKIM pour la signature des messages, DMARC pour la politique d’authentification, et Autodiscover pour Outlook.
Cela dépend de la source OVH et de la méthode utilisée. Une migration IMAP standard migre les emails et dossiers mail, mais pas les contacts, calendriers ou tâches. Ces éléments doivent donc être vérifiés, exportés, importés ou recréés selon le cas.
Il faut réaliser un inventaire, lancer un lot de test, préparer le domaine Microsoft 365, réduire le TTL du MX, planifier la bascule DNS, informer les utilisateurs, tester l’envoi et la réception, puis valider Outlook et mobile après migration.
Ce n’est pas obligatoire, mais c’est conseillé si la messagerie est critique, si plusieurs boîtes doivent être migrées, si les DNS ne sont pas maîtrisés ou si Outlook doit être validé sur plusieurs postes. Un prestataire apporte un plan, des tests, des preuves et un support après bascule.
Une migration OVH vers Microsoft 365 doit être préparée avec méthode.
Il ne suffit pas de transférer des messages.
Il faut identifier la source OVH, vérifier ce qui peut être migré, recréer ce qui ne migre pas automatiquement, préparer le domaine, modifier les DNS au bon moment, valider Outlook et sécuriser Exchange Online après la bascule.
La distinction entre migration des données et bascule DNS est essentielle. Les emails peuvent être migrés avant que le MX ne route officiellement les nouveaux messages vers Microsoft 365.
Les preuves sont tout aussi importantes : boîtes migrées, erreurs, tests d’envoi, tests de réception, contrôles Outlook, SPF, DKIM, DMARC et validation utilisateur.
Votre PME utilise encore une messagerie OVH et souhaite passer à Microsoft 365 sans perte de données ni interruption ? Axorys peut organiser, migrer et valider votre environnement Exchange Online.