Migrazione di un database Access al cloud: cosa si porta dietro e cosa no

La migrazione di un database Access al cloud consiste nel trasferire le tabelle su un database server, come Azure SQL, e decidere poi cosa fare di maschere, report e macro. I dati si spostano con strumenti ben documentati. La parte che richiede più lavoro è tutto il resto, perché in Access dati e programma sono spesso un’unica cosa.

Molti gestionali aziendali sono nati così: qualcuno capace ha creato un file Access per un’esigenza precisa, poi il file è cresciuto per anni. Oggi sta in una cartella di rete, ne dipendono più persone e chi l’ha creato magari non lavora più in azienda.

Perché il file Access arriva al limite

Access è un buono strumento per ciò per cui è nato, ma ha limiti chiari quando diventa il cuore dell’azienda:

  • Dimensione. Secondo le specifiche Microsoft, un database può arrivare a 2 GB, meno lo spazio degli oggetti di sistema. Molte aziende non ci arrivano, ma chi ci arriva ha un problema improvviso.
  • Utenti. Il limite ufficiale è 255 utenti contemporanei, ma è un massimo teorico. Le lentezze e i rischi per il file si possono presentare molto prima, specialmente se la rete non è stabile.
  • Solo in ufficio. Il file è legato alla rete aziendale. Da fuori servono soluzioni di ripiego.
  • Sicurezza limitata. Chi ha accesso alla cartella ha in pratica accesso al file. Non è possibile gestire bene chi vede cosa.
  • Backup deboli. Spesso il backup è una copia del file, fatta quando capita.

Mettere il file su Dropbox o OneDrive non è una migrazione

È il primo tentativo di molti, ma non risolve il problema, anzi può crearne di nuovi. Access lavora leggendo e scrivendo direttamente sul file, e questo modo di funzionare non è adatto alla sincronizzazione: copie in conflitto e file danneggiati sono un rischio reale. Anche nelle discussioni della community Microsoft l’indicazione è di passare a un vero database su server.

Spostarlo in cloud significa passare a un database vero e proprio, gestito da un servizio che si occupa di accessi e backup.

Cosa si porta dietro da solo e cosa no

Microsoft offre uno strumento apposito, SQL Server Migration Assistant per Access. Permette di valutare il database, convertire le tabelle in SQL Server o Azure SQL e trasferire i dati.

Questa tabella riassume la documentazione Microsoft sulla conversione:

Parte di AccessCosa succede in migrazione
Tabelle e datiSi convertono con lo strumento, poi vanno verificati
Indici e relazioniSi convertono, poi vanno controllati
Query di selezioneLa maggior parte diventa una vista del database
Query di aggiornamento, con parametri e a campi incrociatiNon si convertono e vanno riscritte
Maschere e reportNon si convertono: restano in Access, oppure vanno rifatti
Macro e codice VBANon si convertono: restano in Access, oppure vanno riscritti

Il punto è questo: lo strumento sposta i dati, non il programma. Maschere, report e codice sono quasi sempre ciò che le persone chiamano “il gestionale”, e sono proprio quelli che non migrano da soli.

Le due strade dopo aver spostato i dati

Strada 1: i dati nel cloud, Access come interfaccia

Microsoft documenta la possibilità di collegare le tabelle Access a SQL Server o Azure SQL. Le persone continuano a usare le stesse maschere, ma i dati stanno su un database vero.

Pro: è rapida, e chi lavora non deve imparare niente di nuovo. Ottieni subito backup e accessi migliori.

Contro: Access resta da installare su ogni PC e può diventare lento se le query non sono pensate per lavorare in rete. Il programma resta inoltre legato a Windows e alla persona che lo conosce.

Strada 2: dai dati nel cloud a una webapp

Si sostituiscono maschere e report con un’applicazione web, utilizzabile da browser, su qualsiasi dispositivo. Si può fare un modulo alla volta, mentre Access continua a funzionare sugli stessi dati.

Pro: nessuna installazione, accesso da ovunque, permessi per ruolo e possibilità di aggiungere un’app per chi è fuori sede.

Contro: è un investimento più importante, e bisogna decidere quali funzioni conservare.

Le due strade non si escludono. Anzi, spesso la prima è il primo passo della seconda: metti al sicuro i dati subito e sostituisci l’interfaccia per gradi, come spiega la nostra guida alla modernizzazione del software legacy.

Come si fa la migrazione, in sintesi

  1. Fai una copia e lavora su quella. Il file originale non si tocca finché la migrazione non è provata.
  2. Separa i dati dal programma. Se tutto è in un unico file, va diviso tra tabelle e maschere. Le linee guida Microsoft prevedono anche una fase di preparazione del database.
  3. Controlla i dati. Duplicati, tipi di dato usati male, campi di testo che contengono date. Meglio scoprirlo ora.
  4. Esegui la valutazione. Il report dello strumento segnala cosa non si converte correttamente.
  5. Prova la migrazione su una copia e confronta i dati, tabella per tabella.
  6. Collega le maschere al nuovo database e fai provare a chi lavora ogni giorno.
  7. Pianifica il passaggio in un momento di basso carico, con la possibilità di tornare indietro.
  8. Metti in sola lettura il vecchio file, in modo che nessuno continui a scriverci per sbaglio.

Se tratti dati personali, verifica anche dove saranno ospitati i dati e qual è il contratto con il fornitore cloud. Bastano poche domande, ma vanno fatte prima.

Tre problemi che incontri quasi sempre

  • Tipi di dato diversi. Date, campi Sì/No e testi lunghi non si comportano allo stesso modo. Serve un controllo soprattutto su filtri e ordinamenti.
  • Query lente. Una query scritta per Access può spostare molti dati sulla rete. Dopo la migrazione può risultare più lenta di prima, se non viene rivista.
  • Automatismi dimenticati. Macro che partono all’apertura, esportazioni verso Excel, stampe: spesso non sono documentate e nessuno se ne ricorda finché non smettono di funzionare.

Se i dati sono anche su Excel

Di solito Access non è solo. Accanto al database ci sono fogli Excel con parti di informazione, e questa è una buona occasione per unirli. Ne parliamo in quando Excel non basta più. Anche i programmi VB6 usano spesso Access come database: in questi casi le due migrazioni vanno pensate insieme.

Domande frequenti

Posso continuare a usare Access dopo la migrazione?

Sì. Le tabelle possono stare su un database cloud, mentre le maschere restano in Access. È un buon punto di partenza, ma mantieni i limiti dell’interfaccia desktop.

Quanto tempo serve?

Il trasferimento dei dati è la parte più rapida. Il tempo dipende soprattutto dalla qualità dei dati, dalla quantità di codice VBA e da quante query vanno riviste. Per questo conviene analizzare il file prima di fare una stima.

Devo per forza usare Azure?

No. Azure SQL è la strada più lineare con gli strumenti Microsoft, ma esistono altri database gestiti. La scelta dipende da cosa dovrà collegarsi ai dati in futuro, da dove vuoi ospitarli e dai costi ricorrenti. Se devi spostare anche il resto, leggi migrare il server aziendale in cloud.

Chi ha creato il file non è più in azienda. È un problema?

Rende il lavoro più lento, ma non impossibile. Il file contiene già molte informazioni, e il resto si ricostruisce parlando con chi lo usa ogni giorno.