Modernisation .NET

Le .NET hérité, remis à niveau sans arrêter l’activité

L’application fait encore tourner l’entreprise, et c’est précisément pour cela que personne ne veut y toucher. Nous migrons les systèmes WebForms, WCF, VB.NET et .NET Framework vers le .NET actuel une tranche à la fois, l’ancien et le nouveau fonctionnant côte à côte jusqu’à ce qu’il ne reste plus rien côté ancien.

Offres d’entrée au périmètre fixe Réserver un appel

Vous êtes probablement ici parce que

Une application WebForms ou WCF fait encore tourner une partie critique de l’activité, et ceux qui l’ont écrite sont partis.
Chaque estimation de modernisation s’est soldée par une réécriture pour laquelle vous ne pouvez pas vous permettre de geler la feuille de route.
Vous êtes coincés sur Windows Server et IIS parce que l’application ne peut tourner nulle part ailleurs.
Les revues de sécurité et de conformité signalent sans cesse une version de framework qui n’est plus prise en charge.

Notre façon de moderniser

Toujours la même démarche, parce que c’est la seule que nous ayons vue aboutir.

Évaluer par l’expérience, pas par la recherche

Nous avons écrit du code de production avec chacune des piles de la liste ci-dessous : l’évaluation relève donc du savoir acquis, pas d’une phase de recherche que vous financez.

Débloquer le build d’abord

Des projets au format SDK, des bibliothèques partagées en multi-ciblage et un pipeline qui tourne tout seul. C’est rentable avant même la fin de la migration, et cela rend reproductible tout ce qui suit.

Étrangler, jamais de big bang

La nouvelle pile est mise en place à côté de l’ancienne. Les tranches migrent derrière les mêmes URL, une à la fois, avec un retour arrière possible pour chacune.

Laisser votre équipe capable de finir

Chaque tranche est documentée comme un modèle. L’objectif : que vos propres développeurs prennent en charge les tranches suivantes, avec notre relecture.

Modernisation .NET

Chaque technologie de cette liste, livrée en production

Le .NET hérité n’est pas un problème unique. Une application WebForms, une couche de services WCF et un client WinForms bloquent chacun pour des raisons totalement différentes, et une estimation ne vaut que l’expérience réelle de celui qui la fait sur cette technologie. Nous avons écrit du code de production avec chacune d’elles, y compris en VB.NET que personne ne veut ouvrir : l’évaluation relève donc du savoir acquis, pas d’une phase de recherche que vous financez.

2002 – 2012ASP.NET WebFormsASP.NET Core avec Razor Pages ou Blazor
Le cycle de vie des pages, le ViewState et les contrôles serveur n’ont pas d’équivalent : le balisage est donc réellement réécrit. La logique métier qu’il recouvre, en général non, et l’essentiel du travail consiste à séparer les deux.
2003 – 2010Services ASMX et WCFAPI ASP.NET Core, gRPC ou CoreWCF
Les bindings, behaviors et contrats SOAP ne se portent pas. Quand les appelants sont des tiers que vous ne pouvez pas modifier, CoreWCF maintient le contrat pendant que tout ce qui se trouve derrière migre.
2007 – 2015Silverlight et clients à plugin navigateurUn front-end web ou une application mobile
Il n’y a rien vers quoi migrer : le runtime a disparu de tous les navigateurs. Ces projets commencent par une discussion de cadrage sur ce que l’application devait réellement faire.
2008 – 2019DataSets, EF6 et ADO.NET fait maisonEF Core, ou Dapper quand il se justifie
C’est dans la couche de données qu’une migration simple devient coûteuse. Traduction des requêtes, transactions et chargement différé se comportent tous différemment, et cela se manifeste en production plutôt qu’à la compilation.
2009 – 2016ASP.NET MVC 5 et Web API 2ASP.NET Core MVC
Ce qui se rapproche le plus d’une migration mécanique dans cette liste. Le vrai travail porte sur l’hébergement, la configuration, l’injection de dépendances et le pipeline de middlewares, pas sur vos contrôleurs.
2002 – aujourd’huiWinForms et WPF.NET desktop actuel, ou MAUI si l’application a sa place sur un téléphone
Les deux tournent toujours sur le .NET moderne : c’est donc rarement une réécriture. Ce qui bloque, ce sont les suites de contrôles tierces abandonnées et l’interopérabilité COM, et c’est la première chose que nous cherchons.
Toutes versionsBibliothèques de classes .NET Framework.NET actuel, en multi-ciblage pendant la migration
Les bibliothèques partagées sont ce qui permet à l’ancien et au nouveau système de tourner côte à côte. Les passer d’abord en multi-ciblage est généralement ce qui débloque tout le reste de cette liste.
En continupackages.config, anciens csproj, IIS sur Windows ServerProjets de style SDK, conteneurs, CI qui tourne toute seule
Peu glorieux, mais c’est ce qui rend le reste reproductible. Cela porte aussi ses fruits bien avant la fin de la migration, c’est pourquoi c’est souvent la bonne chose à faire en premier.

Pas de réécriture en big bang

Rien sur cette liste n’est remplacé d’un seul coup. L’approche qui fonctionne, c’est l’étrangleur (strangler pattern) : mettre en place la nouvelle pile à côté de l’ancienne, migrer une tranche à la fois derrière les mêmes URL, et faire tourner les deux jusqu’à ce qu’il ne reste plus rien côté ancien. Sur le papier, cela paraît plus lent, et c’est la seule version de ce type de projet que nous ayons vue aboutir.

Offres d’entrée au périmètre fixe

Une première étape qu’un responsable peut valider

Chaque mission peut commencer par l’une de ces offres. Chacune a un nom et un périmètre écrit avant de démarrer : la première décision reste modeste, et vous voyez comment nous travaillons avant de vous engager sur quoi que ce soit de plus important.

2 semaines

Évaluation de modernisation

Chaque projet, dépendance et hypothèse d’hébergement de la solution, mis en regard de ce qu’il deviendra, et chiffré sous forme de plan « étrangleur » finançable phase par phase.

Ce qui est inclus

Inventaire des projets, packages, contrôles tiers et de l’interop COM
Ce qui se transpose mécaniquement, ce qui doit vraiment être réécrit, et ce qui ne devrait pas survivre
Plan de migration par phases, classé par risque et chiffré
Une restitution pour ceux qui financent le projet

Ce que vous obtenez

Un plan chiffré et phasé à présenter au budget, et qui vous reste, que nous réalisions le travail ou non.

Se renseigner sur cette offre

3 semaines

Modernisation du build et du pipeline

Des projets au format SDK, une gestion des packages à jour et un pipeline de CI qui tourne tout seul. L’étape ingrate qui rend toutes les suivantes reproductibles.

Ce qui est inclus

Anciens csproj et packages.config convertis
Bibliothèques partagées en multi-ciblage pour la migration
Build et tests en CI à chaque modification
Build et déploiement conteneurisés là où c’est pertinent

Ce que vous obtenez

Une solution qui se construit de la même façon partout, prête pour le début de la migration, et rentable avant même qu’elle commence.

Se renseigner sur cette offre

6 à 8 semaines

Migration d’une première tranche

Une partie délimitée de l’application migrée vers le .NET moderne, fonctionnant à côté de l’ancien système derrière les mêmes URL, et éprouvée en production.

Ce qui est inclus

Tranche choisie pour sa valeur et la netteté de son découpage
Nouvelle pile mise en place à côté de l’ancienne
Trafic basculé tranche par tranche, avec retour arrière possible
Le modèle documenté pour que votre équipe puisse le reproduire

Ce que vous obtenez

Le modèle « étrangleur » éprouvé sur votre propre système, avec de vrais utilisateurs sur la nouvelle version, et une estimation mesurée pour la suite.

Se renseigner sur cette offre

Chaque offre fait l’objet d’un devis à prix fixe une fois le périmètre étudié — et un prix fixe reste fixe : si cela nous prend plus de temps, c’est notre problème, pas le vôtre.

Les questions que posent nos clients

Devons-nous réécrire notre application WebForms ?

Le balisage, oui : le cycle de vie des pages et le ViewState n’ont pas d’équivalent dans le .NET moderne. La logique métier en dessous, généralement pas, et séparer les deux représente l’essentiel du travail. C’est pour cela que l’évaluation vient en premier.

Nos services WCF peuvent-ils conserver leurs appelants actuels ?

Souvent, oui. Lorsque les appelants sont des tiers que vous ne pouvez pas modifier, CoreWCF maintient le contrat SOAP pendant que tout ce qui se trouve derrière migre vers le .NET moderne.

Combien de temps prend une migration depuis .NET Framework ?

Cela dépend bien davantage de la couche de données et des dépendances tierces que de la taille du code. L’évaluation de deux semaines existe précisément pour répondre à cette question, avec une estimation par phases plutôt qu’une supposition.

Travaillez-vous sur du VB.NET ?

Oui. Nous avons livré du VB.NET en production et nous savons le lire, le porter ou l’encapsuler, y compris les parties que personne dans l’équipe actuelle ne veut ouvrir.

Toujours sur .NET Framework ?

Dites-nous ce que fait l’application et sur quoi elle tourne. Nous vous dirons ce qu’implique réellement la migration, et quelle devrait être la première tranche.

Réserver un appel Envoyer un message