Como minha transição multinacional de uma plataforma de desenvolvimento para outra?

Estou trabalhando no departamento de TI de uma grande empresa internacional. Estamos desenvolvendo diferentes aplicativos de Intranet para o negócio (Reclamações, Descontos, Service Desk etc.). Agora, decidimos migrar da plataforma PHP para o .NET (a integração com o MS CRM Dynamics, Exchange e MS Office é um dos motivos). Como existem cerca de 20 aplicativos diferentes que a empresa está usando na plataforma PHP atual, teremos que apresentar a melhor maneira de movê-los para a nova plataforma. Não quero entrar em detalhes sobre como converter o código, etc, pois enquanto migramos, queremos melhorar todos esses aplicativos.

Então, criamos duas maneiras principais de mover esses aplicativos:

1. Suporte apenas uma plataforma. O que isso significaria? Crie a página inicial e migre literalmente todos os aplicativos para o .NET (sem aprimorá-los enquanto fazemos isso). Após a execução da Nova intranet, começaríamos a reconstruir os aplicativos migrados e melhorá-los. Isso nos pouparia a desenvolver intranet em .NET e, ao mesmo tempo, precisaria oferecer suporte à plataforma PHP.

2. Suporte as duas plataformas por algum tempo. Isso significaria criar apenas uma página inicial e 1 ou 2 novos aplicativos (que não existem em nossa plataforma PHP). Tornando-os disponíveis para os usuários, mas não decolando da plataforma PHP (incorporaríamos menus e links para facilitar a movimentação dos usuários entre os aplicativos na página PHP e o novo). Em seguida, começaríamos a reescrever os aplicativos PHP enquanto os aprimoramos.

Agora não tenho certeza do que seria melhor, por um lado (opção 1) potencialmente facilitaremos tudo para os usuários, não forçando-os a usar duas plataformas diferentes ao mesmo tempo. Embora eles não vejam nenhuma melhoria em ter a nova plataforma, além de tudo parecer melhor, a funcionalidade dos aplicativos na nova plataforma será a mesma por algum tempo. Também acho que adicionaríamos a nós mesmos (departamento de TI) mais trabalho, pois basicamente escreveríamos todos os aplicativos duas vezes.
Por outro lado, na opção dois (2) usuários teriam pior experiência, pois duas plataformas parecem diferentes, mas perceberiam os benefícios da nova plataforma à medida que novas aplicações estão sendo movidas.

Algum de vocês se deparou com algo assim? O que você escolheria? Ou talvez haja uma maneira ainda melhor e diferente das que apresentei? Gostaria de saber o que você pensa e como você abordaria isso.

Vamos considerar os dois cenários:

Migração tudo de uma vez

Enquanto você estiver migrando sua base de código, seus clientes continuarão usando seus aplicativos existentes. Como a migração levará um tempo não trivial, isso significa que você precisará de uma equipe de manutenção na antiga base de código, para correção de bugs e desenvolvimento de recursos. Todas as alterações feitas na antiga base de código precisam ocorrer na nova base de código. Você acabará escrevendo cada linha de código duas vezes, desde que a migração não seja concluída, tornando mais caro o tempo que leva para migrar. Então, tudo se resume a: qual será o tempo de resposta para a migração completa? Seus custos de desenvolvimento dispararão enquanto durar o tempo de resposta.

Migração peça por peça

Nesse cenário, você terá melhor controle sobre o esforço duplo, mas ainda terá muitos custos adicionais. Sua implantação envolverá duas plataformas separadas, com o dobro dos problemas de implantação e recursos adicionais do servidor necessários. A menos que você tenha um aplicativo organizado de maneira modular, muitas vezes você encontrará um código presente na outra plataforma que não seja a que você precisa, causando esforço adicional de portabilidade e manutenção. Enquanto a migração não for concluída, seu custo de desenvolvimento será maior. Ao mesmo tempo, a pressão do recurso significará que você levará muito tempo para concluir a migração.

Conclusão

Por experiência pessoal, posso lhe dizer duas coisas:

• Alternar linguagens de programação raramente compensa. De uma análise de custo-benefício, é muito improvável que seja rentável mudar para .NET do PHP. Então, meu principal conselho é: não. Tente resolver seus problemas com sua base de código existente.
• Peça por peça é a melhor abordagem, mas é difícil fazê-lo no nível dos módulos de aplicativos. Você descobrirá que precisará desenvolver e manter recursos nos dois lados da arquitetura enquanto a migração não for totalmente concluída. Pode ser uma boa idéia priorizar recursos não com base no que os clientes mais precisam, mas no que limitará a quantidade de esforço duplo (reduzindo o custo).

Por razões financeiras, a maioria das empresas em que trabalhei seguiu a segunda abordagem, com razão, devo acrescentar. É preciso muito dinheiro, tempo e riscos para eles alcançarem o primeiro lugar. O usuário entenderia principalmente o número 2 desde que visse seu progresso e interação com eles. Nesta economia enxuta e média, duvido que alguém adotaria a abordagem número 1.

As abordagens do big bang raramente são construtivas no que diz respeito aos usuários finais. Aconselho contra isso e, para ser sincero, não acredito que alguém possa considerá-lo seriamente como uma opção, dado o número de solicitações em questão.

Eu estaria inclinado a ir com a opção dois e lidar com re-trabalhos caso a caso. É certo que isso pode levar mais tempo do que abordar um no papel, mas, na realidade, você está abrindo uma quantidade significativa de riscos de negócios adotando a abordagem um e eu realmente não gostaria de estar presente para as chamadas de suporte no primeiro dia, se houver apenas um pequeno problema no final do usuário.

Além disso, se a grande maioria dos aplicativos baseados em serviços da Web já está escrita em php, como está o conhecimento .Net disponível?

Eu acho que de qualquer maneira seus usuários terão que sofrer mudanças, seja big bang (solicite muitas chamadas de suporte) ou fragmentados (aumentando a familiaridade). Estou inclinado a pensar que você realmente não avaliou exatamente quanto trabalho terá que ser feito para passar de quase todo o php para completamente o .Net.

Em primeiro lugar, concordo com tudo o que Joeri diz.

A primeira opção é realmente horrível. Se você fizer isso e não continuar o suporte, como Joeri descreve, desligará o suporte por um par de anos, tanto quanto o cliente vê. Depois de dois anos, eles obtêm efetivamente o mesmo site com todos os mesmos problemas que aprenderam a odiar nos últimos anos. Além disso, o risco de que o mercado tenha mudado nesse meio tempo e tornado o aplicativo obsoleto e com necessidade de uma grande reformulação. Além disso, se você desligar o suporte por dois anos, o que você acha que acontecerá com todas as solicitações de serviço? Eles não vão embora. Pelo menos alguns de seus usuários "vão à falência" e desenvolvem sistemas de missão crítica (provavelmente) no acesso para preencher as lacunas nos sistemas que você está reescrevendo - então você ainda acaba suportando duas plataformas ...

A opção dois significa que você apoiará as duas tecnologias por um longo período de tempo. Esse período de tempo será mais longo do que você imagina e você pode acabar com um ecossistema permanentemente fragmentado - ou seja, uma quantidade significativa de código PHP que não é econômico para reescrever misturado com o código .NET mais recente.

Empurre com força contra quem está sugerindo isso. Será muito mais barato escrever código para integrar os aplicativos PHP aos produtos que você sugere do que reescrever tudo no .NET e integrar o código reescrito aos produtos, não se esqueça, a integração não acontecerá magicamente se você usar o .NET .

Mais uma coisa, pegue o número de linhas de código PHP e coloque-o em uma ferramenta COCOMO 2 para ter uma idéia de quanto tempo e quantos desenvolvedores serão necessários para concluir a reescrita.

Você tem uma terceira opção: -

Migrar o código php para o servidor Windows e ISS (o mesmo que você planeja executar o .NET!)

Você pode adicionar novos aplicativos ao .NET (e converter lentamente alguns mais antigos ao .NET) enquanto apresenta aos usuários o que parece ser um único sistema.