Article : The Migration Factory

Sur le modèle de la « Software Factory » ou « usine à logicielle », l’usine à migration (Migration Factory) se définit par un ensemble de bonnes pratiques, méthodologies, outils et expérience permettant d’accroître la productivité et la prédictibilité au travers des projets de migration. Le terme « Migration Factory » est issu des différents engagements clients & partenaires réalisés au MTC et se décline en fonction des technologies (VB6, PHP, Java, Oracle Forms, pour ne citer que celles-là, vers .NET ou encore Lotus Notes vers Exchange/SharePoint). Pourquoi ce terme ? Parce qu’une problématique ou un projet de migration est différent d’un projet classique étant donné sa priorité, les contraintes spécifiques à la migration ou encore le changement induit. Dans les parties suivantes, j’explique les différents éléments à prendre en compte pour la mise en œuvre d’une usine à migration.

Comment aborder un projet de migration ?

Le projet de migration est toujours la bête noire de l’entreprise et ce pour plusieurs raisons différentes que je peux résumer de la sorte sans être exhaustif :

- Le projet de migration est pressenti comme un projet cher et long avec une issue incertaine,

- Peu gratifiant, car il faut reprendre des existants généralement bâtis sur des technologies ou des conceptions obsolètes (il n’est jamais facile de faire une autocritique d’un travail réalisé plusieurs années auparavant) et malgré tout cela fonctionne et donne satisfaction, alors pourquoi changer ?

- Il sera nécessaire de former les personnes aux nouvelles technologies, acquérir de nouvelles compétences et de nouveaux outils pour accompagner ce changement, ce qui là encore implique un investissement…

Aborder un sujet de migration de la sorte ne conduit nul part et ne résout rien car, malgré tout, la planification du cycle de vie d’une application d’entreprise pérenne devrait toujours inclure un ou plusieurs cycles de migration et d’évolution (aussi appeler dans certains cas, rénovation). Que l’application ne soit pas évolutive ou migrable n’est pas toujours dû à la technologie, mais peut-être dû aussi à une mauvaise conception ou anticipation des évolutions à venir. Les choix opérés par l’architecte sur la conception initiale sont déterminants.

Pour aborder positivement un projet de migration, il est nécessaire de comprendre les facteurs qui nous poussent à migrer. L’ensemble de ces facteurs (il y en a généralement plusieurs, voir une combinaison de facteurs) forment la réponse à la question « Pourquoi dois-je migrer ? » que la personne détenant les capacités d’investissement ne manquera pas de vous poser à juste titre.

A titre d’exemple, voici quelques facteurs de migration :

- Technologie vieillissante (exemple : Cobol, VB6…)

- Volonté d’évoluer vers de nouvelles technologies (exemple : s’ouvrir au Web 2.0…)

- Problèmes avec la technologie actuelle (exemple : performance…)

- Contraintes métier (exemple : consolidation des applications…)

- Réduction des coûts (exemple : nouvel environnement de développement plus productif…)

Lorsque les facteurs résultants (performance, coûts…) et les facteurs opportuns (opportunité, nouveaux marchés, nouveaux produits…) sont en adéquation, vous avez atteint le seuil de décision.

Migrer ou ne pas migrer ?

Comme l’écrivait Shakespeare dans Hamlet, Prince du Danemark, telle est bien la question. Avoir atteint le seuil de décision est bien, prendre la décision est mieux. Seule l’étude de faisabilité permet de répondre à la question « Migrer ou ne pas migrer ». La décision est prise en connaissance de cause puisque l’étude de faisabilité est une phase en amont du projet de migration qui ne doit pas être ni négligée ni mise de côté et doit permettre de connaître tous les tenants et aboutissants du projet de migration lorsque celui-ci débutera. Cette analyse de faisabilité nous permet de comprendre l’investissement, de maîtriser les coûts et de réduire les risques.

Cette phase de collecte d’informations permet de définir les objectifs et priorités du projet. Elle peut se décliner en plusieurs volets : technique, métier, environnemental…et tout autre sujet incontournable du domaine impacté par la migration. La conduite de l’analyse de faisabilité peut se faire par interview ou par l’utilisation d’outils dédiés suivant le volet.

Le volet métier, pour la migration d’une application, permet de comprendre :

- La pérennité de l’application,

- La criticité de l’application ou des données manipulées par l’application,

- L’interaction avec les acteurs externes (utilisateurs, autres systèmes…),

- Les règles métier impactées,

- Le rôle de l’application dans le business global de l’entreprise.

Le volet technique doit permettre de comprendre la complexité technique et quantifier finement le périmètre de la migration. Par exemple dans le cadre de la migration d’une application, l’évaluation technique donnera les mesures telles que le nombre de lignes de code, le nombre de fichiers source, les dépendances, les diagrammes, etc.

Enfin, l’évaluation de l’environnement permet de comprendre l’impact de la migration sur les outils, les personnes et les méthodologies, comme par exemple l’environnement de développement, les compétences des personnes chargées d’effectuer la migration ou la reprise post-migration, etc.

Scenarii de migration

Afin de faire une estimation de charge du projet de migration, il est nécessaire d’évaluer les différents scenarii de migration possibles. En général, un scénario global est retenu mais les sous-parties d’un projet de migration peuvent être adressées avec des scenarii différents du scénario global.

Les 4 scenarii de migration :

- Portage

- Réutilisation

- Réécriture

- Remplacement

Le portage est propice lorsque le besoin fonctionnel n’est pas remis en cause, que les modifications à apporter sont modérées et qu’il est nécessaire d’apporter de nouvelles fonctionnalités. Dans ce scénario, ce sont généralement les coûts de maintenance/production ou des raisons stratégiques (ouverture vers les nouvelles technologies) qui représentent les facteurs de migration prépondérants. Le portage est le principe selon lequel l’existant sera porté d’une technologie X à une technologie Y, en général pour bénéficier des avantages de la technologie Y non présents dans la technologie X.

La réutilisation est considérée lorsque le fonctionnel est satisfaisant ou que les coûts sont relativement faibles. Dans le cas d’une application, il peut s’agir aussi d’une mauvaise séparation des couches applicatives, ce qui peut-être subi plutôt que choisi. La réutilisation, lorsqu’elle est techniquement possible, induit généralement un investissement minimal et permet d’accéder rapidement aux fonctionnalités de la nouvelle plateforme technologique. Bien que séduisante, la réutilisation peut engendrer des effets de bord ou des dégradations de service qui sont généralement dus à la technologie ou la conception initiale ne répondant plus aux principes que les nouvelles technologies (imaginer que migrer simplement une application client/serveur vers du Web peut se faire par réutilisation est généralement une utopie).

La réécriture est envisagée lorsque les indicateurs sur les règles métier, le fonctionnel, la qualité, etc. sont au rouge. En effet, à quoi sert de migrer une application de mauvaise qualité ou dont les coûts de maintenance sont élevés pour obtenir une application basée sur les nouvelles technologies mais trainants de graves problèmes de conception ? En général, la réécriture est le scénario pour lequel l’investissement est le plus important (mais ce n’est pas toujours vrai d’où la nécessité absolue d’une étude de faisabilité) mais il a l’avantage, pour l’architecte, de repartir à 0 en bénéficiant des nouvelles façons de faire (conception, design patterns…) plus évoluées et plus adaptées.

Le remplacement est étudié dans le cas où l’application ne répond plus aux besoins métier de l’entreprise. Plus généralement, ce scénario est utilisé sur des parties d’un système ayant bénéficié d’apports tiers externes comme un composant graphique d’un éditeur de logiciels tiers par exemple. Le remplacement peut avoir un effet « boule de neige » car les dépendances de l’application, système ou module à remplacer peuvent impacter au-delà du périmètre d’un lot de migration ou du projet complet (exemple : remplacer Oracle par SQL Serveur).

Retrouvez cette première partie au travers d'un web cast:

Stratégies et enjeux de la migration vers .Net

L’analyse de faisabilité

Comme nous l’avons déjà mentionné, l’analyse de faisabilité doit permettre de prendre la décision de migrer ou ne pas migrer en connaissance de cause. Cette étape incontournable est la première de tout projet de migration et fait parti du plan projet. L’investissement réalisé sur cette phase peut conduire à la conclusion de ne pas migrer, et peut être considéré comme perdu. Malgré tout la prise de décision ne doit pas se faire sans cet investissement minimum. De plus, il est très difficile d’estimer le temps de l’analyse (et donc l’investissement initial) étant donné qu’il est dépendant de beaucoup d’inconnus. En conclusion, l’analyse de faisabilité ne répond pas réellement à migrer ou ne pas migrer mais plutôt à comment et que migrer. Pour cette raison, la décision de migrer doit reposer sur des facteurs opportuns et résultants suffisamment forts pour que la décision de migrer soit une décision stratégique prise en amont de l’étude de faisabilité par les décideurs influents ou sponsors. De toute façon, il faut toujours envisager de migrer un jour ou l’autre et donc l’investissement réalisé dans l’analyse de faisabilité n’est jamais perdu.

L’analyse de faisabilité doit permettre de faire les bons choix pour le projet de migration (objectifs & priorités) :

- Analyse de l’architecture existante et cible

- Inventaire à migrer (y compris les tests ou l’environnement de test)

- Mesures, indicateurs…

- Problèmes à anticiper pendant la migration

- Estimation de temps et de coûts pour la migration

- Scenarii de migration

L’analyse de faisabilité sur un ensemble de systèmes (ou applications) permet d’ordonnancer la migration. Pour cela, il est possible de servir d’un quadrant de migration tel que celui présenté ci-dessous :

Le processus de migration

Le processus de migration dépend en partie des technologies en jeu. Malgré tout, les grandes phases d’un projet de migration sont récurrentes et c’est d’ailleurs l’industrialisation de ces phases qui permet de mettre en place l’usine à migration. L’étude de faisabilité fait parti d’une phase de planification plus globale identique à un projet classique.

La planification définit les éléments suivants :

- Définition des objectifs de la migration (exemple : amélioration de la performance)

- Définition des attendus (exemple : l’application doit calculer 5 fois plus vite)

- Définition des contraintes (exemple : à configuration matérielle équivalente)

- Evaluation des risques

- Planification des tâches ; Ordre de migration des modules de l’application

- Prototype de migration (si possible) permettant de détecter les problèmes aux plus tôt, de se familiariser avec les technologies et de commencer par un projet simple.

La planification des tâches, comme dans tout projet, permet d’ordonner les étapes spécifiques du projet de migration, à savoir :

- Définition du périmètre projet

o Composants & fonctionnalités à migrer

o Objectifs de la migration

o Analyse de l’application

o Evaluation des architectures existante et future

o Analyse et conception des nouvelles fonctionnalités

o Choix de la stratégie de migration (totale ou par étapes, horizontale ou verticale si applicable)

o Inventaire

- Préparation

- Migration

- Tests

- Valider l’équivalence fonctionnelle

- Ajout & test des nouvelles fonctionnalités

- Déploiement

La préparation consiste à se mettre dans les meilleures conditions avant le lancement de la migration. Cette étape optionnelle permet d’améliorer l’efficacité de la migration. Lorsque le seuil de migrabilité est atteint (seuil optimum pour la migration), la phase de migration est enclenchée.

Dans toutes les étapes du projet de migration, il convient d’utiliser les bons outils et de capitaliser sur l’expérience des projets migrés.

Les bonnes pratiques

Les bonnes pratiques listées ci-dessous sont issues de différents projets de migration et peuvent servir de guide le cas échéant.

- Un projet de migration est prioritaire ; C’est aussi parmi les projets les plus complexes.

- Migrer dans les conditions favorables de migrabilité (base stable, peu d’évolutions…)

- Commencer par une application critique pour le métier mais faiblement complexe techniquement : un projet de migration réussi est très motivant pour la suite et démontre la capacité à faire évoluer l’existant.

- Mixer les équipes avec les personnes ayant une bonne connaissance du fonctionnelle et d’autres ayant une bonne connaissance des technologies cibles ; Créer une osmose de manière à amener les fonctionnels sur les nouvelles technologies et les experts technologiques au fonctionnel.

Usines à migration

Le premier type d’usine à migration spécifiée est l’usine à migration de Visual Basic 6.0 vers .NET. D’autres usines à migration définies par le Microsoft Technology Center de Paris vont continuer à apparaître sur les technologies suivantes :

- PHP vers ASP.NET

- FoxPro vers .NET

- Java vers .NET

- Oracle Forms vers .NET

- Delphi vers .NET

Pour tout renseignement ou information, prenez contact avec le MTC Paris : mtcparis@microsoft.com ou directement avec Frédéric Queudret (Architecte MTC) : fredeq@microsoft.com.

L’usine à migration de Visual Basic 6.0 vers .NET

Références

- Interview sur l'atelier d'étude de faisabilité: https://www.microsoft.com/france/msdn/vbasic/migration/atelier-de-migration-de-vb6-a-vbnet.mspx 

- Processus de mise à niveau de WSS 2.0 à 3.0 : https://blogs.msdn.com/fredeq/pages/article-sur-le-processus-de-mise-niveau-et-migration-de-wss-2-0-3-0.aspx

- Convert a Java Web Application to ASP.NET using JLCA : https://msdn.microsoft.com/msdnmag/issues/07/05/Migration/

- Mise en œuvre d’une stratégie de migration de Visual Basic 6.0 vers Visual Basic .NET : https://www.microsoft.com/france/msdn/vbasic/ressources/appmigrationstrat.mspx