Les organisations qui réussissent le mieux à utiliser les SIG se modernisent en permanence afin de tirer parti des nouvelles fonctionnalités, d’optimiser les investissements technologiques et d’atteindre leurs objectifs commerciaux. Même si la modernisation est un processus qui comprend de nombreuses définitions, elle implique souvent le déplacement (ou la migration) d’utilisateurs, de groupes ou de contenus d’un système SIG à un autre. Aujourd’hui, de nombreux projets de modernisation entraînent des migrations vers une infrastructure Cloud.
La taille et l’étendue des migrations ArcGIS Enterprise et Cloud peuvent varier en fonction des environnements individuels en question et des nombreuses façons dont le logiciel est déployé et géré par différentes organisations. Quelle que soit leur simplicité ou complexité, toutes les migrations nécessitent une compréhension du contexte de l’entreprise et de l’utilisateur, ainsi qu’un plan d’action avec une mesure de succès établie.
Voici quelques-uns des modèles de migration les plus courants :
Cette rubrique traite du pourquoi et du comment de la migration. Grâce aux idées exposées dans ce document, vous serez davantage en mesure d’évaluer si une migration est le bon choix pour votre organisation. Vous pourrez également connaître les actions à entreprendre en fonction du modèle de migration que vous choisissez. Cette vue d’ensemble aborde la migration de la même manière que vous élaborez et implémentez une stratégie géospatiale : comprendre, planifier et agir. Au lieu de suivre un scénario de migration en particulier, cette rubrique s’attache à fournir des informations et des conseils pertinents applicables à tous les scénarios.
Tout d’abord, vous devez vous demander pourquoi entreprendre une migration et vers quel environnement ou vers quelle configuration cible vous voulez réaliser la migration. Pour savoir pourquoi, la première étape consiste à identifier les objectifs commerciaux de la migration. Vous souhaitez établir des objectifs commerciaux spécifiques, afin de pouvoir mesurer les efforts encourus et voir plus tard si vous les avez atteints. Si les objectifs ne sont pas spécifiques, il devient difficile de savoir si vous avez réussi. Dans un exemple de passage d’un déploiement ArcGIS Enterprise sur site à un fournisseur Cloud commercial, les objectifs pourraient notamment être les suivants :
Ce sont de bons points de départ, qui sont généralement réalisables avec une migration vers le Cloud, mais ils sont trop généraux pour permettre de définir des actions et des approches spécifiques. La section suivante présente certaines raisons courantes pour lesquelles une organisation souhaite effectuer une migration, ainsi que les méthodes permettant de rendre ces objectifs plus spécifiques et utiles.
Les entreprises constatent souvent des améliorations de performances lorsqu’elles migrent leur infrastructure vers un fournisseur Cloud commercial en raison des optimisations de performances et des options proposées par la plupart des fournisseurs IaaS. Voici quelques-unes des façons dont l’infrastructure Cloud peut améliorer les performances :
Ces cinq points montrent comment un déploiement Cloud peut améliorer les performances de façon fonctionnelle, mais n’indiquent pas encore quelle aide spécifique et directe ces objectifs apporteront à une organisation.
Pour de meilleurs résultats, définissez les objectifs de performance du système à l’aide de critères de réussite.
Considérez l’objectif d’une organisation d’améliorer les performances du système en décomposant par objectif général, objectif ciblé ou objectif défini avec des critères de réussite :
La réduction des coûts ou la réduction potentielle des coûts est l’une des raisons les plus répandues pour lesquelles les organisations cherchent à passer à un fournisseur Cloud. Voici quelques avantages en termes de coûts de la migration vers le Cloud :
Un objectif axé sur le coût peut viser à réduire le coût global du système en passant à un modèle de mise à l’échelle basé sur la charge qui déploie des machines ArcGIS Server supplémentaires sous charge, mais les ralentit pendant les périodes de calme.
Les fournisseurs Cloud apportent également de nouvelles fonctionnalités et fonctions qui peuvent ne pas être disponibles ou réalisables dans une implémentation sur site. Exemples :
L’un des objectifs liés aux nouvelles fonctionnalités peut être d’améliorer nos processus de mise à jour des données SIG en transférant notre géodatabase vers un fournisseur de base de données géré, en publiant des services d’imagerie et en demandant à nos éditeurs d’utiliser des applications Web.
De nombreuses organisations sont incitées à migrer leur infrastructure vers le Cloud en raison d’un mandat de sécurité ou d’une stratégie organisationnelle.
Un objectif spécifique lié aux normes de sécurité peut être d’implémenter ArcGIS Enterprise dans un environnement réseau Zero Trust, y compris la gestion de l’accès entrant via une appliance WAF fournie en tant que composant PaaS.
Certains des objectifs fixés en matière de sécurité peuvent être atteints plus clairement que vos autres objectifs. Par exemple, le respect d’une norme de sécurité gouvernementale obligatoire comme FedRAMP ou de normes commerciales comme SOC-2 est une initiative vouée à réussir ou à échouer.
Une fois que vous avez fixé des objectifs clairs et spécifiques et établi une méthode pour mesurer le succès, il est temps de commencer à planifier la migration.
Une fois que vous avez une bonne compréhension de vos objectifs, de vos critères de réussite et de vos défis, l’étape suivante consiste à créer un plan d’action. Les huit étapes générales suivantes sont présentées ci-dessous à titre de point de départ.
Avant de procéder à une migration, vous devez connaître dans l’ensemble le contenu, les systèmes et les fonctions qui vont être migrés. Regardez au-delà d’une simple liste de fonctionnalités et de services. Examinez les traitements et les processus utilisés par votre organisation. Quelles sont les informations essentielles à votre mission et quelles sont les aptitudes ou les compétences nécessaires pour assurer la mission ?
Bien que l’état du système existant ne ressemble en rien à la conception du système cible, il est important de comprendre comment et pourquoi le système existant est construit tel qu’il est. Comprendre la technologie déployée et sa configuration vous permettra d’approfondir vos connaissances sur la façon dont vos utilisateurs interagissent avec votre système et sur la façon dont ils s’attendront à interagir avec celui-ci une fois la migration terminée.
Même si la migration n’est pas imminente, établissez une chronologie claire et respectez-la. Utilisez vos critères de réussite pour créer des jalons afin de déterminer si vous respectez votre calendrier et si chaque phase de la migration est réussie. Prévoyez suffisamment de temps pour tester les processus, valider l’acceptation du système cible et transférer les connaissances au personnel afin qu’il sache comment migrer ses processus vers les nouveaux modèles.
Identifiez clairement la personne responsable des différentes étapes et parties de la migration. Pensez à tout ce qui doit se produire pour y parvenir. Il ne s’agit pas seulement d’implémenter la technologie et de déplacer du contenu, mais aussi de comprendre comment chaque membre de votre organisation est affecté. Il sera alors nécessaire d’organiser des réunions initiales, de recueillir les commentaires des intervenants, de suivre une formation sur les nouveaux systèmes et d’orienter les procédures de gestion du changement qui se produiront après la conception, l’implémentation et le test du système.
Une fois les étapes précédentes terminées, il est temps de réaliser un inventaire dont le niveau de détail sera suffisant en cas d’audit. Aucun membre ne doit se sentir laissé pour compte parce qu’un petit détail, essentiel pour lui, a été négligé. L’identification des types de contenu inclus dans le système, des configurations et des URL utilisées par vos utilisateurs, ainsi que des composants logiciels installés, vous aidera à concevoir l’approche de migration en ayant davantage confiance en sa réussite.
Maintenant que vous connaissez mieux chaque élément de données, utilisateur, processus et traitement à migrer, vous devriez disposer des principaux composants requis pour concevoir le nouveau système. Donnez à un architecte le temps de recueillir les exigences des personnes avec lesquelles il peut être amené à travailler et permettez-lui de documenter minutieusement le nouveau système cible. Soyez conscient des différences majeures dans votre environnement cible, telles qu’un changement de domaine, un changement d’authentification, de nouvelles règles de sécurité, etc.
Différentes méthodes techniques différentes peuvent être employées au cours d’une migration d’entreprise. Certaines méthodes utilisent des fonctions prêtes à l’emploi d’ArcGIS Enterprise, telles que l’outil WebGIS DR ou la méthode Rejoindre le site. D’autres migrations peuvent nécessiter des méthodes plus pratiques, telles que les scripts Python, pour déplacer du contenu. Les conditions spécifiques de votre migration et les différences entre les environnements source et cible dicteront les méthodes dont vous avez besoin.
Enfin, veillez à documenter chaque partie du plan de migration afin de pouvoir vous y référer plus tard. Ce document est votre feuille de route pendant la migration et doit expliquer les activités prioritaires que vous allez entreprendre pour la mener à bien. Lors du déroulement de la migration, le plan peut permettre de suivre la progression par rapport à votre calendrier, de signaler la progression aux intervenants et de vérifier que toutes les étapes ont été entièrement achevées.
Une fois votre plan en main, il est temps d’agir. Toutes les étapes que vous avez suivies jusqu’à présent doivent fournir une image claire des actions qui doivent avoir lieu, de l’ordre des opérations et des mesures qui seront utilisées pour évaluer si la migration a réussi. Utilisez les étapes ci-dessous pour guider certaines des étapes clés.
Commencez par le système existant. Assurez-vous que toutes les modifications apportées aux données, à l’infrastructure, aux applications ou à tout autre élément requis sur le système source sont prêtes. Cela inclut la création de copies et de sauvegardes de vos données et machines virtuelles. Vous pouvez également définir le système source sur une configuration en lecture seule afin que les utilisateurs ne puissent pas créer de contenu pendant la migration.
Dans l’idéal, prenez le temps de nettoyer le contenu de ce système. Si vous parvenez à supprimer le contenu inutile ou inutilisé du système source, la migration même sera de plus faible ampleur et l’impact sur les utilisateurs sera plus court (l’accès restreint durera moins longtemps).
Utilisez la conception du système qui a été créée lors de la phase de planification pour déployer votre architecture cible. Une fois le système cible déployé, veillez à exécuter vos étapes normales de validation de l’environnement pour vérifier que le système fonctionne comme prévu. Des vérifications telles que la connexion à ArcGIS Enterprise à partir d’un navigateur ou d’un ordinateur de bureau, la création d’une carte ou d’une application Web, l’inscription d’une géodatabase d’entreprise et la publication d’un service sont utiles pour établir que les fonctions de référence fonctionnent correctement. Le transfert d’une petite quantité de données de test représentatives à partir du système source vous aidera à effectuer ces étapes. Notez que pour certaines méthodes telles que les migrations WebGIS DR, le système cible peut être configuré de manière à n’être entièrement accessible ou fonctionnel qu’à partir des machines cibles, et non à tous les utilisateurs.
Commencez à déplacer des utilisateurs, des groupes et du contenu du système source vers le système cible à l’aide des méthodes que vous avez choisies lors de la phase de planification. Veillez à réaliser de fréquentes vérifications au cours de ce processus et à consigner tous les cas d’échecs de migration ou de problèmes de contenu. Ces remarques seront essentielles si vous devez annuler une partie de la migration.
Demandez à certains utilisateurs existants qui ont été migrés vers le nouveau système au cours de la dernière étape de vérifier que leurs processus et traitements fonctionnent comme prévu avec le nouveau système. Demandez également si leurs contenus apparaissent et s’ils ne sont pas altérés. Faites-en un processus itératif : une fois qu’un groupe avec des processus et besoins similaires a vérifié que tout fonctionne comme prévu, intégrez un nouveau groupe. Essayez de réduire les variables autant que possible, de sorte que si vous rencontrez un problème, il sera plus facile d’identifier l’origine.
Parfois, il est plus logique de migrer en l’état depuis l’ancien système vers le nouveau sans procéder à des modernisations. Imaginons par exemple que vous vouliez vous assurer que les processus des utilisateurs fonctionneront toujours dans un nouvel environnement Cloud avant de mettre à niveau la version déployée d’ArcGIS Enterprise. Si c’est le cas maintenant que les utilisateurs, le contenu et les processus ont été vérifiés, vous pouvez commencer à mettre à niveau ou à ajouter toute technologie que vous ne pouviez pas gérer lors de l’implémentation initiale. Prenez le temps de revérifier les processus avec vos utilisateurs par la suite.
Une autre méthode de migration courante utilise la fenêtre de migration comme une opportunité de mettre à niveau le système. Une fois la migration terminée (dans la même version du logiciel), une mise à niveau peut être effectuée pendant le temps d’arrêt des utilisateurs, combinant la mise à niveau et la migration en un seul traitement.
Non seulement chaque étape du traitement jusqu’à présent doit être documentée à titre de référence, mais vous devez également documenter toutes les nouvelles étapes opérationnelles et de maintenance que vous allez exécuter et la manière dont elles seront réalisées. Des tâches telles que la surveillance, les mises à niveau, l’application de correctifs, les tests, les réglages et le plan de gouvernance que vous avez l’intention de suivre pour vous assurer que le système continue de fonctionner comme prévu.
Maintenant que tout est en place, effectuez toutes les activités supplémentaires de transfert de connaissances, de formation ou de gestion du changement que vous avez encore prévues. Elles peuvent concerner les utilisateurs, les consommateurs, les administrateurs ou les intervenants.
À ce stade, vous devriez disposer d’un nouveau système opérationnel qui répond aux besoins croissants de votre organisation. Comme indiqué précédemment, les migrations vont souvent de pair avec la modernisation. Ne considérez pas ce processus comme terminé, mais comme le début d’un processus continu de modernisation de votre SIG. Regardez ce que l’avenir vous réserve maintenant que vous avez terminé la migration et réfléchissez aux améliorations qui pourraient être apportées au fil du temps pour maintenir votre système à jour.