Stiamo spostando un front-end aziendale basato su Access in un'app basata sul Web

We want to move to a web-based app so we can eliminate the dependency on our physical location for hiring new sales force members.

Se questa è la motivazione principale del tuo progetto, ti preghiamo di considerare non per riscrivere l'applicazione. Se ho il diritto, avremo ancora una base di utenti definita e non voglio che la tua app sia aperta a milioni di utenti (è per questo che le applicazioni web sono le migliori). Vuoi anche accedere ai dati solo attraverso canali protetti.

In una situazione del genere, suppongo che sarà almeno 100 volte più economico e veloce fornire a tutti i membri della forza vendita un laptop Windows e un accesso VPN alla rete, e installare l'applicazione direttamente sulle loro macchine. Se la distribuzione di aggiornamenti sembra essere un problema, pensa a scrivere una configurazione conforme MSI per la tua applicazione e utilizza i criteri di Windows per la distribuzione automatica.

Inoltre, raccomando vivamente questo articolo di Joel sull'argomento "riscrive": link

Naturalmente, dal momento che il backend è un database relazionale completo a cui è possibile accedere simultaneamente da molte applicazioni diverse, può essere un approccio aggiungere funzionalità nuove attraverso un front-end web, a patto che la nuova funzionalità non è molto limitata alle funzionalità esistenti nell'applicazione Access. Scegli la tecnologia che meglio si adatta al tuo attuale knowledge stack.

Ovviamente, senza conoscere la complessità della tua applicazione (e le interfacce con Outlook, IE, ecc. suggerisco che è complesso), raccomanderei il percorso .NET, dal momento che sembra che tu abbia già familiarità con un molti degli strumenti di Visual Studio che sarebbero coinvolti. (SQL Server, VB.Net, ecc.)

Anche se non sono anti-open source, (mi piace anche FREE), dipende da cosa vuoi mordere. Gli sviluppatori del tuo negozio hanno più esperienza nel regno di Visual Studio o nel dominio LAMP? Il costo delle licenze per Visual Studio è quello che spinge le persone in quella direzione, o c'è un valido motivo tecnico (tutti devono comunque imparare tutte le nuove cose, e LAMP ci dà [valore significativo qui] e [valore bonus significativo qui] che renderlo una scelta migliore mentre attraversiamo il processo di cambiamento)?

Dipende molto da quanti soldi sono stati preventivati, quanto tempo hai a fare il lavoro e cosa effettivamente farà la nuova applicazione che potrebbe essere diversa dall'applicazione esistente. A volte gli strumenti "gratuiti" in realtà costano di più nel tempo necessario per apprenderli e integrarli con ciò che già possiedi.

Per prima cosa, tieni presente che lo stack LAMP potrebbe essere libero di andare avanti, ma che i costi di proprietà sono sempre gli stessi. Hai ancora bisogno di alimentare la potenza e la larghezza di banda dei server e hai ancora bisogno di manodopera qualificata per mantenere le cose funzionanti e sicure. Una volta raggiunta una scala abbastanza grande, è praticamente un lavaggio.

In questo caso direi che, sebbene rendere alquanto basato sul web possa avere un senso, probabilmente stai guardando qualcosa con un servizio centrale con diverse UI. Inoltre, la cosa su cui penso più del web è mobile - come la gestisci? Il web è ieri, il mobile è domani.

Nella misura in cui rispondo alla domanda, non penso che ci sia una diretta, dati i fatti che conosciamo. Ma in generale in questi giorni è spesso necessario guardare ad approcci ibridi poiché molto spesso è necessario utilizzare bit e pezzi di stack diversi per la migliore e più economica funzionalità.

Qual è il problema con l'applicazione esistente e in che modo lo spostamento verso un'applicazione Web lo risolverà? Le linee di codice 120K sono significative. Se hai già sviluppatori addestrati nelle tecnologie che stai già utilizzando, e sta funzionando bene, perché dovresti cambiare? Senza rispondere a questa domanda, qualsiasi valutazione di potenziali soluzioni non ha senso. Immagino che affidabilità e velocità siano due problemi?

Usi il termine "stack LAMP" in modo approssimativo. Ho sempre scelto tecnologie che sono multipiattaforma, invece di quelle che ti bloccano in un unico fornitore. Open-source è buono se la licenza si adatta al modo in cui prevedi di usarlo.

Sembra che tu abbia una vasta conoscenza specifica di Microsoft presso la tua organizzazione, quindi potresti non voler pagare il prezzo della riqualificazione.

Come ha detto @Wyatt Barnett, una volta sviluppata un'applicazione, se la tecnologia che si utilizza è adeguata all'attività, il costo di manutenzione non è correlato al nome di marca di tale tecnologia.

Per quanto appropriato, le linee di codice da 120K sarebbero un incubo da gestire in PHP e potrebbero essere lente in Ruby. Scegli qualcosa di popolare in modo da poter trovare gli sviluppatori in base alle tue esigenze. Vorrei andare con Java o C # /. Net. Al giorno d'oggi molte persone usano Spring con Java.

Sono nel mezzo di una migrazione simile, tranne che abbiamo scelto di terminare con un'applicazione front-end .net invece di una basata sul web.

Quello che abbiamo scelto di fare è stato prima migrare la logica di business dal front-end di Access e riscriverla in C #. Ci è voluto un po ', ma alla fine abbiamo mantenuto la maggior parte della logica aziendale mantenendo lo stesso front-end. Una volta che i moduli sono stati ridotti alla visualizzazione visiva, abbiamo iniziato a spostare sezioni dell'applicazione su un'applicazione .net. Siamo ora nella fase finale di distribuzione della nostra applicazione come app .net completa senza dipendenze da MS Access.

Ho lavorato su un numero significativo di conversioni "legacy to current" nel corso degli anni. Le più riuscite sono state quelle che hanno migrato la funzionalità alla nuova piattaforma a un tasso misurato.