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 Access | Cosa succede in migrazione |
|---|---|
| Tabelle e dati | Si convertono con lo strumento, poi vanno verificati |
| Indici e relazioni | Si convertono, poi vanno controllati |
| Query di selezione | La maggior parte diventa una vista del database |
| Query di aggiornamento, con parametri e a campi incrociati | Non si convertono e vanno riscritte |
| Maschere e report | Non si convertono: restano in Access, oppure vanno rifatti |
| Macro e codice VBA | Non 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
- Fai una copia e lavora su quella. Il file originale non si tocca finché la migrazione non è provata.
- 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.
- Controlla i dati. Duplicati, tipi di dato usati male, campi di testo che contengono date. Meglio scoprirlo ora.
- Esegui la valutazione. Il report dello strumento segnala cosa non si converte correttamente.
- Prova la migrazione su una copia e confronta i dati, tabella per tabella.
- Collega le maschere al nuovo database e fai provare a chi lavora ogni giorno.
- Pianifica il passaggio in un momento di basso carico, con la possibilità di tornare indietro.
- 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.