Come può la mia transizione multinazionale da una piattaforma di sviluppo all'altra?

Consideriamo entrambi gli scenari:

Migrazione tutto-a-una-parte

Durante la migrazione della base di codice, i tuoi clienti continueranno a utilizzare le tue app esistenti. Dato che la migrazione richiederà una quantità di tempo non trascurabile, ciò significa che è necessario disporre di un gruppo di manutenzione sulla vecchia base di codici, per la correzione dei bug e lo sviluppo delle funzionalità. Ogni modifica apportata alla vecchia base di codici deve avvenire nella nuova base di codici. Finirai per scrivere ogni riga di codice il doppio della lunghezza della migrazione, rendendo più costoso il tempo necessario per la migrazione. Quindi, tutto si riduce a: quale sarà il tempo di completamento per la migrazione completa? I costi di sviluppo saliranno alle stelle per tutto il tempo necessario per il completamento.

Migrazione pezzo per pezzo

In questo scenario avrai un controllo migliore sul doppio sforzo, ma avrai ancora molti costi aggiuntivi. La tua implementazione coinvolgerà due piattaforme separate, con due volte i problemi di distribuzione e le risorse aggiuntive del server richieste. A meno che tu non abbia un'app organizzata in modo modulare, scoprirai che spesso nell'altra piattaforma è presente una parte di codice diversa da quella che ti serve, causando ulteriori operazioni di porting e di manutenzione. Finché la migrazione non viene eseguita, il costo di sviluppo sarà più alto. Allo stesso tempo, la pressione delle funzionalità significa che ci vorrà molto tempo per completare la migrazione.

Conclusione

Dalla mia esperienza personale posso dirti due cose:

• Il passaggio ai linguaggi di programmazione raramente paga. Da un'analisi costi-benefici, è molto improbabile che sia redditizio passare a .NET da PHP. Quindi il mio consiglio principale è: non farlo. Cerca di risolvere i tuoi problemi con la tua base di codice esistente.
• Il pezzo per pezzo è l'approccio migliore, ma difficilmente riuscirai a farlo a livello dei moduli dell'applicazione. Scoprirai che dovrai sviluppare e mantenere funzionalità su entrambi i lati dell'architettura per tutto il tempo in cui la migrazione non è completa. Può essere una buona idea dare priorità alle funzionalità non basate su ciò di cui i clienti hanno più bisogno, ma su ciò che limiterà la quantità di doppio sforzo (riducendo così i costi).

Per ragioni finanziarie, la maggior parte delle aziende con cui ho lavorato è andata al secondo approccio, a ragione potrei aggiungere. Ci vuole un sacco di soldi, tempo e rischi per raggiungere il primo posto. L'utente per lo più capirebbe il n. 2 finché vedranno i tuoi progressi e l'interazione con loro. In questo snello & economia media, dubito che nessuno prenderebbe l'approccio numero uno.

Gli approcci del Big Bang sono raramente costruttivi per quanto riguarda gli utenti finali. Io sconsiglierei e, sinceramente, non posso credere che qualcuno lo considererebbe seriamente come un'opzione, visto il numero di domande interessate.

Sarei propenso ad optare per l'opzione due e gestire le rielaborazioni caso per caso. Ammettiamo che questo potrebbe richiedere più tempo di un approccio su carta, ma in realtà, si sta aprendo una quantità significativa di rischi aziendali prendendo l'approccio uno e non vorrei davvero essere in giro per le chiamate di supporto il primo giorno se c'è anche solo un piccolo problema alla fine dell'utente.

Inoltre, se la stragrande maggioranza delle applicazioni basate sui servizi Web sono già state scritte in php, come è l'esperienza .Net disponibile?

Penso che in entrambi i casi i tuoi utenti dovranno sperimentare cambiamenti, sia big bang (molte chiamate di supporto) o frammentarie (crescente familiarità). Sono incline a pensare che tu non abbia davvero calcolato esattamente quanto lavoro dovrà essere fatto per passare dall'essere completamente vicino a tutto il php a completamente .Net.

In primo luogo, sono d'accordo con tutto ciò che dice Joeri.

L'opzione numero uno è davvero orribile. Se si esegue questa operazione e non si continua il supporto come descritto da Joeri, si arresta il supporto potenzialmente per un paio di anni fino a quando il cliente lo vede. Dopo due anni ottengono efficacemente lo stesso sito con tutti gli stessi problemi che hanno imparato a conoscere e amp; odio per gli ultimi anni. Inoltre, il rischio che il mercato sia cambiato nel frattempo e ha reso l'applicazione obsoleta & ha bisogno di un importante rinnovamento. Inoltre, se interrompi il supporto per due anni, cosa pensi che succederà a tutte le richieste di servizio? Non andranno via. Almeno alcuni dei tuoi utenti "si arrabbiano" e sviluppano sistemi mission critical in (probabilmente) Access per colmare le lacune nei sistemi che stai riscrivendo - quindi continuerai a supportare due piattaforme ...

L'opzione due significa che sosterrai entrambe le tecnologie per un lungo periodo di tempo. Questo periodo di tempo sarà più lungo di quanto si pensi e si potrebbe finire con un ecosistema permanentemente frammentato - cioè una quantità significativa di codice PHP che non è economico da riscrivere miscelato con il codice .NET più recente.

Respingi strong contro chiunque lo stia suggerendo. Sarà molto più economico scrivere codice per integrare le applicazioni PHP con i prodotti suggeriti piuttosto che riscrivere tutto in .NET, quindi integrare il codice riscritto con i prodotti, non dimenticare, l'integrazione non si verificherà magicamente se utilizzi .NET. .

Un'altra cosa, prendi il numero di righe del codice PHP e inseriscilo in uno strumento COCOMO 2 per avere un'idea di quanto tempo e quanti sviluppatori avrai bisogno per completare la riscrittura.

Hai una terza opzione: -

Migrare il codice php sul server Windows e ISS (lo stesso di cui si prevede di eseguire .NET on!)

È quindi possibile aggiungere nuove applicazioni in .NET (e convertirle lentamente in .NET.) mentre si presentano agli utenti ciò che appare come un singolo sistema.