Les versions du framework .NET se succèdent de façon régulière et annoncée. Pour chaque nouvelle version, la question se pose rapidement de porter ou de migrer les applications.

Effectivement, Microsoft fait bien évoluer son framework en conservant la compatibilité avec les versions précédentes. Mais, à chaque nouvelle version, des éléments structurants sont ajoutés, et d’autres sont modifiés parfois significativement.

Porter ?

Changer de framework ? C’est pas bien compliqué !, a-t-on pu lire çà et là. Il suffit :

  • d’ouvrir le projet dans Visual Studio,
  • de compiler le projet,
  • de supprimer les warnings émis par le compilateur. Et voilà !

Bon, tout cela est un peu naïf ! Mais, cela a le mérite de dessiner une première approche, que l’on pourrait qualifier de portage, et qui consiste à modifier l’application à la marge, pour qu’elle fonctionne sur la nouvelle version du framework.

Un portage n’est pas aussi simple qu’il y paraît de prime abord. En effet, les évolutions mineures du framework ne sont souvent pas si mineures que cela. Et la compatibilité ascendante est rarement parfaite. Ces petites différences peuvent avoir un impact important sur le fonctionnement et les performances de l’application.

Ou migrer ?

Une nouvelle version de framework, ce n’est pas seulement de la continuité ; c’est aussi une part de rupture. Ainsi, il peut s’agir d’une technologie entièrement nouvelle, à fort potentiel, comme LINQ dans .NET 3.5. Il peut s’agir également d’une nouvelle technologie rendant obsolète une technologie de l’ancienne version. C’est le cas de Windows Communication Foundation (WCF) dans .NET 3.0 qui supplante Web Services Enhancement (WSE) bâti sur .NET 2.0. Enfin, une technologie de l’ancienne version peut avoir subi des améliorations significatives dans la nouvelle version.

Toutes ces évolutions majeures sont porteuses d’opportunités pour l’application et ses utilisateurs. En profiter, c’est engager une stratégie de migration, consistant à modifier l’application de manière plus importante, pour bénéficier de ces opportunités.

Alors, porter ou migrer ?

On l’a vu, porter est bien loin d’être sans risque. En comparaison, les apports pour l’application sont finalement bien minimes. Prendre autant de risques pour aussi peu de gains, on peut se demander si le jeu en vaut bien la chandelle ! Et puis, finalement, porter, ce n’est pas vraiment changer de framework.

En allant au bout de la démarche, on est amené à tirer profit du nouveau framework, donc à migrer. La migration est de plus modulable en termes d’effort, sans être forcément plus risquée qu’un portage. Mais, cette fois, on tire vraiment profit des changements.

Et puis, toute migration commence par un portage … Pourquoi s’arrêter en si bon chemin ?