Problèmes pris en charge
- COM / ActiveX / OCX ne peut pas encore être abandonné ;
- un composant 32 bits bloque le passage au 64 bits ;
- la bonne interface entre des actifs C++ et .NET reste incertaine ;
- la migration doit être progressive et préserver les spécifications actuelles.
Principes de la démarche
Pour valoriser les actifs existants, il est souvent plus naturel de ne pas supposer dès le départ un remplacement total.
Nous clarifions d’abord :
- si l’actif est un simple composant d’interface ou s’il porte des règles métier ;
- s’il peut rester dans le même processus ;
- où franchir la limite 32/64 bits ;
- s’il faut l’encapsuler ou l’isoler dans un autre processus.
Sujets particulièrement adaptés
- systèmes existants comprenant COM / ActiveX / OCX ;
- interfaces entre C++ et C# ;
- encapsulation avec C++/CLI ;
- architectures franchissant la limite 32/64 bits ;
- plans de remplacement progressif.
Situations adaptées
- l’actif porte des règles métier ou des spécifications d’équipement et ne peut pas être remplacé simplement ;
- il faut d’abord prolonger sa durée de vie et clarifier ses interfaces ;
- un remplacement futur est souhaité, mais une transition sûre est nécessaire aujourd’hui.
État recherché
Le but n’est pas forcément de supprimer tout ce qui est ancien, mais de conserver les actifs utiles tout en simplifiant les interfaces complexes.
Nous visons ainsi :
- une architecture plus facile à maintenir ;
- un ordre de remplacement clairement établi ;
- un coût de migration futur réduit.