Migrer de Microsoft 365 vers Oworks : guide de projet

Ce guide suppose la décision prise. Sinon, le comparatif Oworks / Microsoft 365 est le bon point de départ.

À dire avant de commencer : ce qui ne migre pas

Une DSI qui découvre ces limites au milieu du projet perd confiance : dans le prestataire d'abord, dans le projet ensuite.

Teams ne se migre pas. Ce n'est pas une messagerie, et son équivalent dans Oworks est une autre application : Matrix avec le client Element pour la discussion, Meet pour les réunions (page Produit). L'historique s'exporte : les Teams Export APIs « allow you to export 1:1, group chat, meeting chats, and channel messages », sous permissions applicatives Chat.Read.All et ChannelMessage.Read.All, avec une licence Teams active. Mais c'est un export par API, pas une reprise : aucun chemin d'import dans une autre plateforme n'est documenté. Archive froide consultable, ou rien : la décision se prend tôt, et la date s'annonce.

SharePoint et OneDrive sont un chantier distinct. Microsoft lui-même, dans sa procédure d'annulation d'abonnement, renvoie vers une page de « manual migration of SharePoint Online content » : un transfert à organiser, pas un bouton.

Les dossiers publics sont une impasse à traiter en amont. La feuille de route de retrait d'EWS annonce leur import/export pour Q4 CY2026, mais leurs opérations génériques de lecture et d'écriture figurent dans la liste « Confirmed capabilities that won't be added ». S'ils portent encore un usage réel, c'est une reprise fonctionnelle, pas une migration.

Les carnets d'adresses personnels, les règles clientes et les signatures suivent le client, pas le serveur. Et les applications enregistrées dans Entra ID ne migrent nulle part : celles qui lisent du courrier sont à réécrire.

L'inventaire préalable

Rien ne se planifie avant lui, et tout se lit en PowerShell Exchange Online sans rien écrire.

Les boîtes. Taille par boîte, taille des archives, nombre d'éléments. Séparez les boîtes humaines des comptes de service et des comptes désactivés : la proportion de comptes morts est toujours sous-estimée.

Les boîtes partagées. Leur intérêt est ce qui casse : plusieurs accès, des droits, souvent un « envoyer en tant que ». Relevez les permissions explicites et les Send As bénéficiaire par bénéficiaire, car elles se perdent silencieusement.

Les boîtes de ressources. Une salle est une boîte aux lettres d'un type particulier, dotée d'une logique de réservation : par défaut, acceptation ou refus automatique selon les conflits, récurrences autorisées, durée maximale de 24 heures, réservation jusqu'à 180 jours à l'avance. Ces paramètres sont la fonction, pas un détail : relevez-les (Get-CalendarProcessing) avant de recréer les salles ailleurs, avec les listes de salles, « special distribution groups that contain only room mailboxes », qui ne se créent qu'en ligne de commande.

Les listes et les groupes, et la distinction qui compte. Une liste statique a des membres, des propriétaires, des droits d'envoi et parfois une modération : tout cela s'extrait et se recrée. Une liste dynamique n'a pas de membres : « A dynamic distribution group queries mail-enabled objects and builds the group membership based on the results. The group membership is recalculated whenever an email message is sent to the group. » Il faut d'abord la matérialiser avec Get-Recipient -RecipientPreviewFilter, puis choisir entre liste statique et règle reconstruite sur l'annuaire cible. Même question pour les groupes à appartenance dynamique d'Entra ID : « You can't manually add or remove a member of a dynamic membership group », licence Entra ID P1 par utilisateur membre, maximum de 15 000 groupes par locataire. Ce ne sont pas des objets qu'on déplace, ce sont des règles qu'on réécrit.

Les alias, les règles de transport, les connecteurs, les domaines acceptés. Get-TransportRule, Get-InboundConnector, Get-OutboundConnector, Get-AcceptedDomain. Chaque alias publié devra exister des deux côtés pendant la cohabitation, et aucun écran de synthèse ne les montre tous : c'est la première cause de rejet après une vague.

Et surtout : les intégrations. C'est là que se trouvent les surprises, parce que personne n'en détient la liste.

Commencez par les applications métier et les copieurs qui envoient du courrier. Microsoft documente quatre méthodes : Client SMTP submission (authentifié sur une boîte, « 10,000 recipients per day. 30 messages per minute »), SMTP relay (connecteur entrant authentifié par certificat ou par IP publique statique, car « Dynamic IP addresses aren't supported or allowed »), Direct Send (anonyme, et qui « Can't deliver email to external recipients ») et High Volume Email. Chacune laisse une trace différente : une boîte dédiée, un connecteur entrant, une IP dans le SPF. Les relever une par une est la seule cartographie fiable. Et SMTP AUTH « is disabled for organizations created after January 2020 », donc un copieur qui fonctionne aujourd'hui le fait grâce à une activation explicite, qu'il faut retrouver.

Les flux Power Automate ensuite. Le connecteur Office 365 Outlook exige « access to an Office 365 mailbox that has the REST API enabled » et refuse les comptes « on a dedicated (on-premise) mail server ». Un flux qui envoie du courrier par ce connecteur ne se repointe pas : il se réécrit.

Pour les scripts et les applications maison, Microsoft fournit de quoi les trouver sans deviner : les EWS Usage Reports et l'EWS Analyzer. À lancer pendant l'inventaire, pas pendant la bascule.

Le volet identité

C'est la partie qu'on oublie parce qu'elle fonctionne. Vos comptes vivent dans Entra ID, et la messagerie en dépend pour l'authentification, le second facteur et l'accès conditionnel. Cet accès conditionnel cible des applications cloud, exige une licence Entra ID P1, et s'applique « after first-factor authentication is completed ». Un serveur de messagerie tiers n'est pas une application cloud d'Entra ID : les politiques écrites pour Exchange Online ne s'appliqueront pas à Oworks. Ce n'est pas une perte de fonction, c'est un transfert de responsabilité, et il faut savoir vers qui.

À instruire en atelier :

1. Quel annuaire fait autorité après la bascule ? Oworks porte l'identité avec Keycloak, en OIDC, SAML et LDAP. Trois scénarios : Keycloak devient la source de vérité ; Keycloak fédère un annuaire existant (Active Directory, LDAP ou Entra ID) ; ou Entra ID reste fournisseur d'identité et Keycloak le fédère. Le choix décide du reste et ne se reprend pas facilement.
2. Que deviennent les mots de passe et le second facteur ? Microsoft ne restitue pas d'empreintes de mots de passe et aucun chemin de reprise n'est documenté : soit on fédère, soit on réinitialise, et une réinitialisation générale se planifie avec la permanence de support.
3. Quel cycle de vie des comptes ? Arrivée, mutation, départ passent souvent par un outil RH qui pousse vers Entra ID. Après la bascule, la messagerie n'est plus derrière Entra ID : la chaîne est à redessiner. Et si l'accès conditionnel portait des règles réelles (authentification héritée, restriction par pays, conformité de l'appareil), il faut identifier ce qui les remplace.

Un point de séquence : ne supprimez pas à la bascule les applications Entra ID qui accèdent aux boîtes. Vous en aurez besoin pour l'extraction elle-même.

La cohabitation sur le même domaine

Le mécanisme général est décrit dans Partager un domaine entre deux messageries : une autorité, un relais, et des comptes qui basculent sans toucher au DNS. Il est le même ici. Côté Microsoft 365, trois points s'y ajoutent.

Le domaine accepté passe en « relais interne ». En Authoritative, « Emails for unknown recipients are rejected ». En Internal relay, « Email is delivered to known recipients in Office 365 or is relayed to your own email server if the recipients aren't known to Microsoft 365 or Office 365 ». La commande est Set-AcceptedDomain -Identity contoso.com -DomainType InternalRelay. Conséquence assumée : vous perdez le rejet des destinataires invalides au périmètre, puisque c'est Authoritative qui active le Directory-Based Edge Blocking.

Il faut deux connecteurs, un par sens. « You need two connectors to route email between Microsoft 365 or Office 365 and your email servers » et « Without connectors, email will not flow […] » Le sortant désigne un smart host ; l'entrant authentifie votre serveur par certificat (la méthode recommandée) ou par IP publique exclusive. Un détail qui fait perdre des journées. Quand plusieurs connecteurs existent, Microsoft les sélectionne dans un ordre documenté : domaine exact, puis tous les domaines acceptés, puis correspondance avec joker. Un connecteur hérité d'un ancien hybride peut donc capter votre trafic sans que rien n'ait l'air anormal.

Le libre/occupé ne traversera pas. Microsoft ne fédère les disponibilités qu'avec ses propres systèmes : la page de référence décrit l'échange « between users in on-premises Exchange and Exchange Online », obtenu par un déploiement hybride complet. Aucune variante n'existe pour un système tiers.

La conséquence est à assumer plutôt qu'à contourner : pendant la cohabitation, les disponibilités seront dégradées entre les deux mondes. Le découpage des vagues ne suit donc pas l'organigramme mais le graphe des réunions et des partages : on fait basculer ensemble les groupes qui se réunissent entre eux. Un comité de direction, un secrétariat et ses délégations, un service qui partage un agenda : une vague.

Le transfert des données

Trois chemins sont documentés pour sortir le contenu d'une boîte. Aucun n'est un outil de migration : ce sont des interfaces.

IMAP, avec OAuth obligatoire. L'authentification de base est morte : « We removed the ability to use Basic authentication in Exchange Online for Exchange ActiveSync (EAS), POP, IMAP, Remote PowerShell (RPS), Exchange Web Services (EWS), Offline Address Book (OAB), Autodiscover, Outlook for Windows, and Outlook for Mac », et personne, pas même le support Microsoft, ne peut la réactiver. Un lecteur IMAP doit donc présenter un jeton OAuth 2.0 en SASL XOAUTH2. La procédure est documentée de bout en bout : enregistrer une application dans Entra ID, lui accorder la permission applicative IMAP.AccessAsApp, obtenir le consentement de l'administrateur, enregistrer le principal de service côté Exchange (New-ServicePrincipal), puis autoriser chaque boîte explicitement (Add-MailboxPermission -AccessRights FullAccess). Cette dernière étape structure les lots : le périmètre d'une vague est la liste des boîtes que l'application a le droit de lire. IMAP ne transporte ni agendas, ni contacts, ni règles serveur.

Les API d'import/export de boîtes de Microsoft Graph. Le chemin le plus fidèle : les éléments s'exportent « as an opaque stream in full fidelity », et l'API couvre « users' primary, shared, and archive mailboxes on Exchange Online ». Mais cette pleine fidélité n'a de sens que vers un autre Exchange : ailleurs, c'est un flux à convertir.

L'étranglement est documenté, et il commande le plan. Les limites du service Outlook dans Graph s'appliquent « to each app ID and mailbox combination » : « 10,000 API requests in a 10-minute period », « Four concurrent requests », « 150 megabytes (MB) upload (PATCH, POST, PUT) in a 5-minute period », et elles couvrent explicitement les ressources de l'API d'import/export. La limite étant par boîte, le parallélisme se gagne en traitant plusieurs boîtes à la fois, pas en poussant une boîte plus fort. Microsoft note aussi que « User throttling is the most restrictive throttling method », parce qu'« any application-level usage will easily exceed the throttling policy ». En revanche, aucun débit de sortie n'est documenté : les durées publiées concernent les déplacements internes de Microsoft et les scénarios d'arrivée, et les transposer serait malhonnête.

L'export de conformité, pour l'archive plutôt que pour la bascule. La nouvelle expérience eDiscovery de Purview exporte les boîtes « in PST files or as individual messages ». Trois contraintes : une licence E3 ou E5 pour l'utilisateur qui exporte ; des paquets qui « expire 14 days after you create the export » ; et « If an export runs for more than seven days without completing, it automatically cancels. » Attention aussi à l'outillage : l'ancienne Content Search et l'eDiscovery Export Tool ont été retirés le 31 août 2025, donc toute procédure interne antérieure est à refaire.

Le retrait d'EWS est un argument de calendrier, pas seulement une contrainte. Microsoft annonce : « October 2026: EWS starts to be disabled globally for all organizations » et « April 2027: EWS is fully disabled. » Le motif est de sécurité : l'incident Midnight Blizzard de janvier 2024 « involved EWS and elevated the urgency of the EWS deprecation effort », et le périmètre a été élargi des applications tierces à toutes celles de Microsoft. Conséquence : tout outil de migration bâti sur EWS est condamné, quel que soit son éditeur. Et pour qui resterait chez Microsoft, les intégrations EWS sont à réécrire de toute façon : même inventaire, autre destination.

Côté Oworks, la FAQ annonce une migration depuis la console, source Microsoft 365 comprise. De tout fournisseur, exigez et vérifiez avant de vous engager : sur quel protocole il lit la source, puisque c'est lui qui fixe le plafond (les limites rappelées plus haut s'appliquent par boîte et par application) ; une migration par lots dont chacun se relance seul après incident, sans reprendre les précédents ; un journal par boîte disant ce qui est passé et ce qui a échoué. Demandez aussi un essai sur un lot représentatif de votre parc plutôt qu'une démonstration sur des comptes neufs : vos plus grosses boîtes, vos agendas les plus partagés, une boîte partagée, une salle. Le périmètre repris au-delà du courrier se constate sur cet essai, il ne se promet pas.

Le déroulé par vagues, et le retour arrière

La première vague se choisit sur sa représentativité, pas sur sa complaisance. Il faut y trouver un poste en Outlook classique, un poste au nouvel Outlook, un téléphone, une boîte partagée avec délégation, une salle de réunion, une liste critique et un utilisateur qui a trente règles de tri. Un service volontaire et simple ne vous apprend rien.

Sur les clients, Outlook classique se connecte nativement à Oworks, en MAPI over HTTP, EWS et ActiveSync, carnet d'adresses hors connexion compris et sans complément sur le poste. Cela vaut pour Microsoft 365 Apps, Outlook 2021 et Outlook 2024, quelle que soit l'édition d'Oworks. Outlook 2016 et 2019 relèvent le courrier en IMAP. Le nouvel Outlook pour Windows ne gère pas MAPI : c'est une limite documentée par Microsoft, pas par Oworks, et elle se compte à l'inventaire. Le détail est traité dans Garder Outlook sans Exchange.

Après chaque vague, dans l'heure : un envoi et une réception depuis l'extérieur sur chaque alias du lot ; SPF, DKIM et DMARC en pass ; une invitation acceptée dans les deux sens ; une boîte partagée ouverte par son délégué ; une liste critique testée en envoi réel ; un copieur et une application métier qui envoient ; la file du serveur de courrier vide. Dans la semaine : volumétrie comparée à la source, courrier rejeté dans les journaux, et relevé des utilisateurs qui n'ont pas ouvert leur boîte. Ce sont eux qui découvriront un problème dans trois semaines.

Le retour arrière se prépare avant la première vague, et il n'est pas gratuit. Repointer le routage d'un compte rétablit la livraison en quelques minutes, mais le courrier reçu depuis la bascule est sur la nouvelle plateforme, et le rapatrier suppose une synchronisation inverse. Deux règles limitent les dégâts : garder la boîte Microsoft 365 intacte, en lecture seule (donc garder sa licence) et dimensionner les vagues pour qu'un retour arrière tienne dans une matinée. Une vague dont vous ne sauriez pas revenir est trop grosse. Ne fondez pas votre plan de retour arrière sur une resynchronisation inverse, même si votre fournisseur en propose une : au moment où vous en auriez besoin, c'est un outil de plus à faire fonctionner. La boîte d'origine laissée intacte est le seul retour arrière qui ne dépende de rien. Concrètement, cela veut dire conserver la licence Microsoft le temps de la vague : un coût à budgéter, pas un oubli.

Après la bascule

Les licences : ne résiliez pas trop tôt. Une boîte sans licence n'est pas une boîte en lecture seule, c'est une boîte qui s'éteint, et avec elle votre chemin de retour. Microsoft documente le cycle de vie d'un abonnement : Active, Expired, Disabled, Deleted, avec, pour la plupart des offres, 30 jours en Expired et 90 jours en Disabled. En Disabled, « Data is accessible to admins only » : on peut encore extraire, pas rendre le service. Deux pièges : une annulation dans la fenêtre de politique « moves directly to the Disabled status » ; et « If you explicitly delete a subscription, it skips the Expired and Disabled statuses and SharePoint Online data and content, including OneDrive, is deleted immediately ». D'où la règle : on résilie après la recette de la dernière vague, pas après sa bascule.

Les données à récupérer avant fermeture. Microsoft fixe une borne, et ses deux pages ne disent pas tout à fait la même chose : « Any customer data that you leave behind might be deleted after 90 days and will be deleted no later than 180 days after cancellation » sur la page du cycle de vie, « might be deleted after 30 days » sur celle d'annulation. Prenez la plus courte comme hypothèse de travail. À sortir avant : les boîtes des comptes partis et les boîtes inactives, les dossiers publics, les contenus SharePoint et OneDrive, les journaux d'audit soumis à conservation, et l'export Teams si vous l'avez décidé. Enfin : « Data is deleted and Microsoft Entra ID is removed, if not in use by other services » : vérifiez ce que ce locataire porte encore par ailleurs.

Les adresses onmicrosoft.com ne disparaissent pas. Microsoft est net : « You can't remove .onmicrosoft.com domains from your account. When you remove a domain, user accounts revert to the default .onmicrosoft.com address as the primary SMTP/UserprincipalName. » Retirer votre domaine fait donc basculer les comptes sur cette adresse, et tout ce qui pointe encore vers eux cesse de fonctionner. Effet voulu, mais à la date voulue. Le retrait exige un ménage préalable : le domaine ne doit être ni le domaine par défaut, ni utilisé par des utilisateurs, boîtes partagées, boîtes de ressources, contacts, groupes, listes ou équipes, ni servir à la connexion d'un administrateur. Microsoft recommande PowerShell au-delà de quelques centaines d'utilisateurs : « If not all users are properly moved, the domain can't be removed. » Et dans le bon ordre : « […] you must remove the domain before you cancel your subscription. »

Un projet de sortie se mesure enfin à ce qu'il laisse : un annuaire dont vous connaissez la source de vérité, une liste d'intégrations à jour, et des équipes capables d'exploiter la plateforme. La démarche en cinq temps de la page États et administrations finit sur le mot « transfert » : c'est le plus important.

Sources

Toutes les pages Microsoft ont été consultées le 8 novembre 2026.

Flux de courrier et cohabitation

• Manage accepted domains in Exchange Online : définitions Authoritative et Internal relay, obligation de connecteur, activation du Directory-Based Edge Blocking, Set-AcceptedDomain.
• Set up connectors to route mail between Microsoft 365 or Office 365 and your own email servers : deux connecteurs, un par sens ; prérequis TLS et certificat ; ordre de sélection entre connecteurs multiples.
• Shared free/busy in Exchange hybrid deployments : partage des disponibilités entre Exchange sur site et Exchange Online, OAuth et relations d'organisation, fin de prise en charge de Federation Trust/EWS pour le libre/occupé.
• How to set up a multifunction device or application to send email using Microsoft 365 or Office 365 : quatre méthodes d'envoi, limites de chacune, SMTP AUTH désactivé pour les organisations créées après janvier 2020, IP dynamiques non prises en charge.

Transfert des données et protocoles

• Deprecation of Exchange Web Services in Exchange Online : calendrier d'octobre 2026 et avril 2027, motif de sécurité, écarts de parité, dossiers publics et boîtes de groupe, outils d'inventaire EWS.
• Deprecation of Basic authentication in Exchange Online : protocoles concernés, impossibilité de réactivation, orientation vers OAuth 2.0.
• Authenticate an IMAP, POP or SMTP connection using OAuth : enregistrement d'application, IMAP.AccessAsApp, consentement administrateur, New-ServicePrincipal, Add-MailboxPermission, SASL XOAUTH2.
• Overview of the mailbox import and export APIs in Microsoft Graph : export en pleine fidélité, boîtes principales, partagées et d'archive, avertissement sur la sauvegarde.
• Microsoft Graph service-specific throttling limits : limites du service Outlook par couple application/boîte (10 000 requêtes par 10 minutes, quatre requêtes concurrentes, 150 Mo en téléversement par 5 minutes) ; limites des API d'export Teams.
• Microsoft 365 and Office 365 migration performance and best practices : trois familles d'étranglement, prééminence du user throttling, facteurs de performance. Page consacrée aux migrations vers Microsoft 365.
• Export search results in eDiscovery : formats PST et .msg, licence E3/E5 requise, expiration des paquets à 14 jours, annulation automatique au-delà de sept jours.
• Export Content search results : retrait de l'expérience eDiscovery classique et de l'eDiscovery Export Tool le 31 août 2025.

Objets de messagerie et annuaire

• Get-DynamicDistributionGroup : appartenance recalculée à chaque envoi, prévisualisation des membres par Get-Recipient -RecipientPreviewFilter.
• Manage rules for dynamic membership groups in Microsoft Entra ID : appartenance par règle, impossibilité d'ajout manuel, licence Entra ID P1 par utilisateur membre, maximum de 15 000 groupes par locataire.
• Create and manage room mailboxes : boîte de salle comme type de boîte de ressource, réglages de réservation par défaut (24 heures, 180 jours), listes de salles créées en ligne de commande uniquement. Page de la version serveur d'Exchange ; elle renvoie vers Manage resource mailboxes in Exchange Online pour le service en ligne.
• Microsoft Entra Conditional Access : signaux et décisions, application après le premier facteur, licence Entra ID P1, comportement à l'expiration des licences.

Teams, SharePoint, et fin de locataire

• Overview of security and compliance (Microsoft Teams) : dépendance de Teams à Exchange Online et SharePoint, flux d'ingestion des données.
• Export content with the Microsoft Teams Export APIs : périmètre d'export des messages, permissions applicatives requises, licence Teams active, messages supprimés accessibles 21 jours.
• What happens to my data and access when my Microsoft 365 for business subscription ends? : états Active, Expired, Disabled, Deleted et leurs durées ; accès administrateur seul en Disabled ; suppression de l'annuaire Entra ID.
• Cancel your Microsoft business subscription : retrait du domaine avant l'annulation, suppression immédiate des contenus SharePoint et OneDrive en cas de suppression explicite, section « Save your data ».
• Remove a domain from Microsoft 365 : prérequis au retrait d'un domaine, durée de l'opération, impossibilité de retirer onmicrosoft.com et repli des comptes sur cette adresse.
• Office 365 Outlook connector : boîte Office 365 avec API REST requise, comptes sur serveur dédié non pris en charge, absence d'authentification par principal de service.

Oworks

• Produit : briques de la suite, protocoles d'accès (MAPI over HTTP, EWS, ActiveSync, IMAP, SMTP, CalDAV, CardDAV), identité Keycloak (OIDC, SAML, LDAP), multi-organisation.
• États et administrations : démarche en cinq temps, cohabitation sur le même domaine, bascule au rythme du client.
• FAQ : déclaration de la source de migration depuis la console, dont Microsoft 365.