La miniature pour les réseaux :
- Accueil /
- Actualités
- /
Migrer Exchange vers le cloud 365 : une opération simple ?
Vu de Microsoft c’est extrêmement simple il suffirait d’utiliser des procédures natives pour que la migration d’un serveur local On-premise vers un service Cloud 365 se fasse de manière quasi automatique.
Comme souvent avec Microsoft la réalité est toute autre…
La migration reste une opération qui nécessite beaucoup de rigueur notamment pour tracer tous les paramètres qui ne seront pas migrés. On trouve ainsi par exemple les droits sur les calendriers ou l’incompatibilité avec les évènements récurrents.
Comme souvent avec Microsoft la réalité est toute autre…
Evidement nous avons cherché la difficulté puisqu’il s’agissait, dans ce cas, de migrer un serveur d’un de nos clients d’Exchange vers office 365. Malgré de bons et loyaux services pendant près de 14 années sans faillir, et surtout sans payer une quelconque souscription mensuelle, il fallut se rendre à l’évidence, et migrer ce serveur qui n’était plus officiellement supporté.
Des mises à jours imposées
En tant qu’infogérant, nous privilégions les solutions robustes et maitrisables. Ce dernier point est important car malgré tous ses atouts fonctionnels, le cloud 365 induit une perte de maitrise puisqu’une partie des composants est maintenue et mis à jour par Microsoft, qu’on le souhaite ou non… Dans nombre de cas ce sera utile et pertinent mais on n’échappera pas à nombre de contraintes techniques induites qui feront apparaitre des incompatibilités avec des versions antérieurs de composants logiciels installés localement (par exemple Azure AD connect) et donc des exigences de mises à jour à des échéances décidées unilatéralement par Microsoft.L'utilisation d'outils de migration
Bien évidemment, nous appuyons notre démarche sur des outils tiers tels que Cloudiway sans lesquels il ne serait quasiment pas possible de réaliser une migration fiable et transparente pour les utilisateurs. Malgré cela, nombre d’opérations doivent être réalisées manuellement, tant pour des actions de vérifications, de mise en conformité que de reconfiguration.
La migration reste une opération qui nécessite beaucoup de rigueur notamment pour tracer tous les paramètres qui ne seront pas migrés. On trouve ainsi par exemple les droits sur les calendriers ou l’incompatibilité avec les évènements récurrents.
Des vérifications manuelles qui restent nécessaires
Côté client final, il est rare que les boites mails existantes soient toutes à
jour, utilement conservées et configurées de manière standardisée conformément au process attendu pour tous les paramètres (adresse X500 par exemple). Ceci induira un nécessaire et fastidieux exercice de vérification/modification qui, par essence, ne peut être que manuel.
Les postes de travail constituent de fait un point de vigilance dans cette opération puisqu’il est courant, qu’en amont de cela, les postes ne disposent pas d’une suite Office parfaitement à jour. Les difficultés de cohabitation voire l'impossibilité de configurer 2 boites mail (sur exchange et sur 365) pour un même utilisateur complique encore un peu le process général.
Par ailleurs, une fois la migration réalisée le décommissionnement de l’ancien serveur Exchange ne se fait pas juste en « éteignant » le serveur comme on pourrait le croire puisqu’un process de décommissionnement logiciel doit s’appliquer et qui bien évidement induit des contraintes nouvelles comme, par exemple, la nécessaire existence d’un catalogue global compatible Windows 2012 maximum… alors même que ce dernier est en version 2019.
Les postes de travail constituent de fait un point de vigilance dans cette opération puisqu’il est courant, qu’en amont de cela, les postes ne disposent pas d’une suite Office parfaitement à jour. Les difficultés de cohabitation voire l'impossibilité de configurer 2 boites mail (sur exchange et sur 365) pour un même utilisateur complique encore un peu le process général.
Par ailleurs, une fois la migration réalisée le décommissionnement de l’ancien serveur Exchange ne se fait pas juste en « éteignant » le serveur comme on pourrait le croire puisqu’un process de décommissionnement logiciel doit s’appliquer et qui bien évidement induit des contraintes nouvelles comme, par exemple, la nécessaire existence d’un catalogue global compatible Windows 2012 maximum… alors même que ce dernier est en version 2019.
L'infogérance déportée
L’infogérance telle que nous la réalisons après la migration en cloud induit finalement presque plus de travaux d’administration que nous en avions sur le serveur on-premise, à la fois du fait de la forte complexité de l’ensemble mais surtout des modifications incessantes apportées par Microsoft tant sur les fonctionnalités, les limites techniques que sur les changements administratifs des modèles de licences.
Rêve et réalité
Les services Cloud présentent d’évidence d’énormes atouts du fait de leur richesse fonctionnelle et de leur présumée disponibilité (en réalité je suis en désaccord sur ce point puisque la disponibilité statistique chez nos clients sur 10 ans s’avère très nettement supérieure à celles des cloud provider public). Par contre, penser que parce que c’est « dans les nuages » tout va fonctionner comme par magie relève d’une illusion au même titre que de croire au père noël.
Selon Derek Rohde, président de Jordenen, notre client sur une opération récente de ce type : « Grâce à Openteam, Jordenen a pu être catapultée dans le 21ème siècle avec une transition parfaite et transparente pour les utilisateurs ».
Selon Derek Rohde, président de Jordenen, notre client sur une opération récente de ce type : « Grâce à Openteam, Jordenen a pu être catapultée dans le 21ème siècle avec une transition parfaite et transparente pour les utilisateurs ».