¿Cómo puede mi transición multinacional de una plataforma de desarrollo a otra?

Estoy trabajando en el departamento de TI de una gran empresa internacional. Estamos desarrollando diferentes aplicaciones de Intranet para el negocio (Quejas, Reembolsos, Service Desk, etc.). Ahora decidimos migrar de la plataforma PHP a .NET (la integración con MS CRM Dynamics, Exchange y MS Office puede ser una de las muchas razones). Como hay alrededor de 20 aplicaciones diferentes que la empresa está utilizando en la plataforma PHP actual, tendremos que encontrar la mejor manera de moverlas a la nueva plataforma. No quiero entrar en detalles sobre cómo convertir el código, etc., ya que mientras migramos queremos mejorar todas estas aplicaciones.

Así que se nos ocurrieron 2 formas principales de mover estas aplicaciones:

1. Admite solo una plataforma. ¿Qué significaría? Cree una página de inicio y, literalmente, migre todas las aplicaciones como están a .NET (sin mejorarlas mientras lo hacemos). Después de que se ejecute Nueva intranet, comenzaríamos a reconstruir las aplicaciones migradas y a mejorarlas. Eso nos ahorraría el desarrollo de la intranet en .NET al tener que admitir la plataforma PHP.

2. Admite ambas plataformas por algún tiempo. Eso significaría construir solo una página de inicio y 1 o 2 nuevas aplicaciones (que no existen en nuestra plataforma PHP). Poner esto a disposición de los usuarios pero no quitar la plataforma PHP (incorporaríamos menús y enlaces para facilitar a los usuarios moverse entre las aplicaciones en la página PHP y la nueva). Luego comenzaríamos a reescribir las aplicaciones PHP mientras las mejoramos.

Ahora no estoy seguro de qué sería mejor, por un lado (opción 1) potencialmente haremos todo más fácil para los usuarios al no obligarlos a usar dos plataformas diferentes al mismo tiempo. Aunque no verán ninguna mejora al tener la nueva plataforma, aparte de que todo se vea mejor, la funcionalidad de las aplicaciones en la nueva plataforma será la misma por algún tiempo. También creo que agregaríamos a nosotros mismos (IT dep) más trabajo, ya que esencialmente escribiríamos cada aplicación dos veces.
Por otro lado, en la opción dos (2) usuarios tendrían peor experiencia ya que dos plataformas se ven diferentes, pero se darían cuenta de los beneficios de la nueva plataforma a medida que se mueven nuevas aplicaciones.

¿Alguno de ustedes se ha encontrado con algo así? ¿Qué elegirías? ¿O tal vez hay una forma diferente y mejor de las que he presentado? Me gustaría saber qué piensas y cómo abordarías eso.

Consideremos los dos escenarios:

Migración de todo a la vez

Mientras migra su base de código, sus clientes seguirán usando sus aplicaciones existentes. Dado que la migración tomará una cantidad de tiempo no trivial, esto significa que necesitará tener un equipo de mantenimiento en la antigua base de código, para la corrección de errores y el desarrollo de características. Cada cambio que realice en la antigua base de código debe suceder en la nueva base de código. Terminará escribiendo cada línea de código el doble de tiempo que la migración no se haya realizado, lo que lo hace más costoso cuanto más tiempo demore en migrar. Entonces, todo se reduce a: ¿cuál será el tiempo de respuesta para la migración completa? Sus costos de desarrollo se dispararán mientras dure el tiempo de respuesta.

Migración pieza por pieza

En este escenario, tendrá un mejor control sobre el doble esfuerzo, pero aún tendrá muchos costos adicionales. Su implementación involucrará dos plataformas separadas, con el doble de problemas de implementación y recursos de servidor adicionales requeridos. A menos que tenga una aplicación muy modularmente organizada, encontrará que a menudo hay un código en la otra plataforma que no es la que necesita, lo que causa un esfuerzo adicional de portabilidad y mantenimiento. Mientras no se realice la migración, su costo de desarrollo será mayor. Al mismo tiempo, la presión de la función significará que le llevará mucho tiempo terminar la migración.

Conclusión

Por experiencia personal puedo decirte dos cosas:

• Cambiar los lenguajes de programación rara vez vale la pena. A partir de un análisis de costo-beneficio, es muy poco probable que sea rentable cambiar a .NET desde PHP. Entonces mi consejo principal es: no lo hagas. Intenta resolver tus problemas con tu código base existente.
• Pieza por pieza es el mejor enfoque, pero tendrá dificultades para hacerlo a nivel de módulos de aplicación. Descubrirá que tendrá que desarrollar y mantener características en ambos lados de la arquitectura mientras la migración no esté completa. Puede ser una buena idea priorizar funciones que no se basan en lo que más necesitan los clientes, sino en lo que limitará la cantidad de doble esfuerzo (reduciendo así el costo).

Por razones financieras, la mayoría de las empresas con las que he trabajado adoptaron el segundo enfoque, con razón podría agregar. Se necesita mucho dinero, tiempo y riesgos para lograr el # 1. El usuario entendería en su mayoría el n. ° 2, siempre y cuando vea su progreso e interacción con ellos. En esta economía magra y media, dudo que alguien adopte el enfoque # 1.

Los enfoques del Big Bang rara vez son constructivos en lo que respecta a los usuarios finales. Aconsejaría en contra y, para ser honesto, no puedo creer que nadie lo considere seriamente como una opción dada la cantidad de aplicaciones en cuestión.

Me inclinaría a ir con la opción dos y manejar las reelaboraciones caso por caso. Es cierto que esto puede llevar más tiempo que el enfoque uno en papel, pero en realidad, está abriendo una cantidad significativa de riesgo comercial al tomar el enfoque uno y realmente no me gustaría estar cerca para las llamadas de soporte el primer día, incluso si hay solo un pequeño problema al final del usuario.

Además, si la gran mayoría de sus aplicaciones basadas en servicios web ya están escritas en PHP, ¿cómo está disponible la experiencia .Net?

Creo que de cualquier manera sus usuarios tendrán que experimentar un cambio, ya sea big bang (muchas llamadas de soporte) o poco a poco (mayor familiaridad). Me inclino a pensar que realmente no ha evaluado exactamente cuánto trabajo tendrá que hacer para pasar de ser casi completamente php a completamente .Net tampoco.

En primer lugar, estoy de acuerdo con todo lo que dice Joeri.

La primera opción es realmente horrible. Si haces esto y no continúas con el soporte como describe Joeri, cierras el soporte potencialmente durante un par de años hasta donde lo ve tu cliente. Después de dos años, obtienen efectivamente el mismo sitio con todos los mismos problemas que han llegado a conocer y odiar durante los últimos años. Además, existe el riesgo de que el mercado haya cambiado en el ínterin y que la aplicación quede obsoleta y necesite una renovación importante. Además, si cierra el soporte durante dos años, ¿qué cree que sucederá con todas las solicitudes de servicio? No se irán Al menos algunos de sus usuarios se "volverán deshonestos" y desarrollarán sistemas de misión crítica en (probablemente) Acceso para tapar los huecos en los sistemas que está reescribiendo, y aún así terminará admitiendo dos plataformas ...

La opción dos significa que admitirá ambas tecnologías durante un período prolongado de tiempo. Este período de tiempo será más largo de lo que piensa y podría terminar con un ecosistema fragmentado permanentemente, es decir, una cantidad significativa de código PHP que no es económico reescribir mezclado con el código .NET más nuevo.

Empuje hacia atrás contra quien sugiera esto Será mucho más barato escribir código para integrar las aplicaciones PHP con los productos que sugiera que reescribir todo en .NET y luego integrar el código reescrito con los productos, no lo olvide, la integración no ocurrirá mágicamente si usa .NET .

Una cosa más, tome el número de líneas de código PHP y póngalo en una herramienta COCOMO 2 para tener una idea de cuánto tiempo y cuántos desarrolladores necesitará para completar la reescritura.

Tienes una tercera opción: -

Migre el código php a su servidor de Windows e ISS (¡el mismo en el que planea ejecutar .NET!)

Luego puede agregar nuevas aplicaciones en .NET (y convertir lentamente algunas más antiguas a .NET) mientras presenta a sus usuarios lo que parece un sistema único.