Application vieillissante. Plan de migration ?

Gromic

Bonjour,

Je travail sur une application métier développée en JavaWeb dans les années 1990-2000 par IBM avec leurs outils DB2 (avec Persistence Builder), Visual Age (IDE indissociable du projet initial), un framwork maison qui est difficil à faire évoluer sans effet de bord ingérable.
J'aimerais apporter du neuf à l'application avec des nouvelles technologies sans quitter le JavaWeb, ni DB2.

De votre expériences est-il envissagable de faire une migration en douceur, création d'un projet v2 et faire cohabiter les deux le temps de la migration ?

4 réponses

Grafikart
Réponse acceptée

Alors je ne connais pas les technos dont tu parle. Mais une migration progressive ce n'est pas évident du tout car tu dois garder les fondations (base de données) de l'ancienne application qui est pas forcément pratique :(

Alexandre #lbac
Réponse acceptée

Salut,

Je ne connais pas non plus les technologies dont tu parles, mais je bosse actuellement sur la refonte globale d'un site datant de 2008, donc vieille base de donnée, mauvaises méthodes d'enregistrement, données en dur, etc... Et je t'assure que pour un réel gain de temps, la cohabitation n'est pas envisageable.

Fais toi un script pour transférer toutes les données et ensuite commences le code de la nouvelle interface pour l'affichage

MacFly
Réponse acceptée

Salut,

Clairement si tu es sur DB2 garde cette base, après il est probablement possible de migrer l'application sur n’importe quelle techno.
A ta place je réduirai les contraintes a l’incompressible et comme grafikart le souligne, la base de donnée c'est la base...
Partant de la trouve des outils qui te correspondent ayant un connecteur DB2.

L'essentiel dans ce plan de migration est de dissocier les modules applicatifs de la couche de persistance.
Tu es sur DB2 avec tel techno, OK, passe a une autre techno, mais garde DB2.
Quand cela sera fait, si tu veux tu pourra changer la base de donnée.

Gromic
Auteur

Merci pour vos retours.

DB2 est tellement ancré que c'est compliqué de faire sans. C'est une DB de 200-300 tables/Vues.
Je vais proposer 1 dev sur l'ancienne application et une équipe sur la nouvelle, une fois au niveau de l'ancienne faire le process de migration.