Comment ma multinationale peut-elle passer d'une plateforme de développement à une autre?

Je travaille dans le département informatique d'une grande entreprise internationale. Nous développons différentes applications Intranet pour l'entreprise (réclamations, remises, Service Desk, etc.). Nous avons maintenant décidé de migrer de la plate-forme PHP vers .NET (l'intégration avec MS CRM Dynamics, Exchange et MS Office est parmi de nombreuses raisons). Comme l'entreprise utilise environ 20 applications différentes sur la plate-forme PHP actuelle, nous devrons trouver le meilleur moyen de les déplacer toutes vers la nouvelle plate-forme. Je ne veux pas entrer dans les détails sur la façon de convertir le code, etc., car pendant que nous migrons, nous voulons améliorer toutes ces applications.

Nous avons donc trouvé 2 façons principales de déplacer ces applications:

1. Prend en charge une seule plateforme. Qu'est-ce que cela signifierait? Créez la page d'accueil et migrez littéralement toutes les applications telles qu'elles sont vers .NET (sans les améliorer pendant que nous le faisons). Après l'exécution de New intranet, nous commencerions à reconstruire les applications migrées et à les améliorer. Cela nous éviterait de développer un intranet en .NET tout en prenant en charge la plate-forme PHP.

2. Prend en charge les deux plates-formes pendant un certain temps. Cela signifierait construire juste une page d'accueil et 1 ou 2 nouvelles applications (qui n'existent pas sur notre plateforme PHP). Les mettre à la disposition des utilisateurs mais ne pas retirer la plate-forme PHP (nous incorporerions des menus et des liens pour faciliter le passage des applications entre la page PHP et la nouvelle). Ensuite, nous commencerions à réécrire les applications PHP tout en les améliorant.

Maintenant, je ne sais pas ce qui serait mieux, d'une part (option 1), nous allons potentiellement tout faciliter pour les utilisateurs en ne les obligeant pas à utiliser deux plates-formes différentes en même temps. Bien qu'ils ne verront aucune amélioration de la nouvelle plate-forme, à part tout ce qui est plus joli, la fonctionnalité des applications sur la nouvelle plate-forme sera la même pendant un certain temps. De plus, je pense que nous nous ajouterions (IT Dep) plus de travail car nous écririons essentiellement chaque application deux fois.
D'un autre côté, dans l'option deux (2), les utilisateurs auraient une expérience pire que deux plates-formes différentes, mais ils se rendraient compte des avantages de la nouvelle plate-forme à mesure que de nouvelles applications sont déplacées.

L'un d'entre vous a-t-il rencontré quelque chose comme ça? Que choisiriez-vous? Ou peut-être existe-t-il une manière encore meilleure et différente de celles que j'ai présentées? J'aimerais savoir ce que vous pensez et comment aborderiez-vous cela.

Prenons les deux scénarios:

Migration tout à la fois

Pendant que vous migrez votre base de code, vos clients continueront à utiliser vos applications existantes. Étant donné que la migration prendra un temps non négligeable, cela signifie que vous devrez disposer d'une équipe de maintenance sur l'ancienne base de code, pour la correction des bogues et le développement des fonctionnalités. Chaque modification que vous apportez dans l'ancienne base de code doit se produire dans la nouvelle base de code. Vous finirez par écrire chaque ligne de code deux fois aussi longtemps que la migration ne sera pas effectuée, ce qui la rendra plus chère plus la migration prendra de temps. Donc, tout se résume à: quel sera le délai d'exécution pour la migration complète? Vos coûts de développement monteront en flèche aussi longtemps que durera le délai d'exécution.

Migration pièce par pièce

Dans ce scénario, vous aurez un meilleur contrôle sur le double effort, mais vous aurez toujours beaucoup de coûts supplémentaires. Votre déploiement impliquera deux plates-formes distinctes, avec deux fois plus de problèmes de déploiement et des ressources serveur supplémentaires requises. À moins que vous ne disposiez d'une application très modulaire, vous constaterez que souvent un morceau de code est présent dans l'autre plate-forme que celle sur laquelle vous en avez besoin, ce qui entraîne des efforts de portage et de maintenance supplémentaires. Tant que la migration ne sera pas effectuée, vos coûts de développement seront plus élevés. En même temps, la pression des fonctionnalités signifie que cela va vous prendre beaucoup de temps pour terminer la migration.

Conclusion

Par expérience personnelle, je peux vous dire deux choses:

• Changer de langage de programmation est rarement payant. D'après une analyse coûts-avantages, il est très peu probable qu'il soit rentable de passer de PHP à .NET. Donc, mon principal conseil est: ne le faites pas. Essayez de résoudre vos problèmes avec votre base de code existante.
• Morceau par morceau est la meilleure approche, mais vous aurez du mal à le faire au niveau des modules d'application. Vous constaterez que vous devrez développer et maintenir des fonctionnalités des deux côtés de l'architecture tant que la migration n'est pas entièrement effectuée. Il peut être judicieux de hiérarchiser les fonctionnalités non pas en fonction de ce dont les clients ont le plus besoin, mais en fonction de ce qui limitera la quantité d'effort double (réduisant ainsi les coûts).

Pour des raisons financières, la plupart des entreprises dans lesquelles j'ai travaillé ont opté pour la deuxième approche, pourrais-je ajouter à juste titre. Il leur faut beaucoup d'argent, de temps et de risques pour atteindre la première place. La plupart des utilisateurs comprendraient # 2 tant qu'ils voient vos progrès et votre interaction avec eux. Dans cette économie maigre et moyenne, je doute que quiconque adopte l'approche n ° 1.

Les approches Big Bang sont rarement constructives en ce qui concerne les utilisateurs finaux. Je le déconseille et pour être honnête, je ne peux pas croire que quiconque l'envisagerait sérieusement comme une option compte tenu du nombre de demandes concernées.

Je serais enclin à opter pour l'option deux et à gérer les retouches au cas par cas. Certes, cela peut prendre plus de temps que l'approche sur papier, mais en réalité, vous ouvrez une quantité importante de risques commerciaux en adoptant l'approche 1 et je ne voudrais vraiment pas être là pour les appels de support le premier jour s'il y a même juste un petit problème au niveau de l'utilisateur.

De plus, si la grande majorité de vos applications basées sur les services Web sont déjà écrites en php, comment est l'expertise .Net disponible?

Je pense que dans un cas comme dans l'autre, vos utilisateurs vont devoir faire face à des changements, que ce soit le big bang (cue beaucoup d'appels d'assistance) ou au coup par coup (familiarisation croissante). Je suis enclin à penser que vous n'avez pas vraiment évalué exactement combien de travail devra être fait pour passer d'une quasi-totalité de php à complètement .Net non plus.

Premièrement, je suis d'accord avec tout ce que dit Joeri.

La première option est vraiment horrible. Si vous faites cela et ne poursuivez pas l'assistance comme décrit par Joeri, vous interrompez l'assistance pendant potentiellement quelques années pour autant que votre client le voit. Après deux ans, ils obtiennent effectivement le même site avec tous les mêmes problèmes qu'ils connaissent et détestent depuis quelques années. Plus le risque que le marché ait changé entre-temps et rende l'application obsolète et nécessite une refonte majeure. De plus, si vous fermez le support pendant deux ans, que va-t-il arriver à toutes les demandes de service? Ils ne partiront pas. Au moins certains de vos utilisateurs "deviendront des voyous" et développeront des systèmes critiques dans Access (probablement) pour combler les lacunes dans les systèmes que vous réécrivez - alors vous finirez toujours par prendre en charge deux plates-formes ...

L'option deux signifie que vous soutiendrez les deux technologies pendant une période prolongée. Cette période sera plus longue que vous ne le pensez et vous pourriez vous retrouver avec un écosystème fragmenté en permanence - c'est-à-dire une quantité importante de code PHP qui n'est pas économique à réécrire mélangé avec du code .NET plus récent.

Repousser fort contre celui qui suggère cela. Il sera beaucoup moins cher d'écrire du code pour intégrer les applications PHP avec les produits que vous proposez que de tout réécrire dans .NET puis d'intégrer le code réécrit avec les produits, n'oubliez pas, l'intégration ne se fera pas comme par magie si vous utilisez .NET .

Encore une chose, prenez le nombre de lignes de code PHP et mettez-le dans un outil COCOMO 2 pour avoir une idée du temps et du nombre de développeurs dont vous aurez besoin pour terminer la réécriture.

Vous avez une troisième option: -

Migrez le code php vers votre serveur Windows et ISS (le même que celui sur lequel vous prévoyez d'exécuter .NET!)

Vous pouvez ensuite ajouter de nouvelles applications dans .NET (et convertir lentement certaines anciennes en .NET) tout en présentant à vos utilisateurs ce qui ressemble à un seul système.