Salta al contenuto
Guida

Migrare a Business Central da un gestionale legacy o da Excel: il percorso per la PMI

Come una PMI passa a Dynamics 365 Business Central da un gestionale datato, da un ERP on-premise o dai fogli Excel: analisi processi, bonifica dati, migrazione anagrafiche e saldi, go-live e affiancamento.

SynSphere Italia 10 min di lettura
Migrare a Business Central da un gestionale legacy o da Excel: il percorso per la PMI

C’è un momento, in quasi ogni PMI cresciuta, in cui il gestionale smette di reggere il passo. A volte è un software anni Duemila che gira su un server sotto la scrivania, di cui solo un consulente esterno sa ancora mettere mano al database. A volte è un ERP on-premise robusto ma rigido, con la fatturazione elettronica appiccicata a fatica e i report che richiedono export manuali. E in moltissimi casi — più di quanto si ammetta — il “gestionale” è in realtà una cartella di fogli Excel: clienti su un file, listino su un altro, scadenzario su un terzo, ognuno con la sua versione “vera” che cambia a seconda di chi lo apre.

Il passaggio a Microsoft Dynamics 365 Business Central è la strada con cui molte di queste aziende mettono ordine. Ma migrare a un ERP cloud non è “spostare i dati”: è l’occasione per ridisegnare i processi, fare pulizia delle anagrafiche e ripartire con basi solide. Questa guida spiega come si fa concretamente, fase per fase, distinguendo i tre punti di partenza tipici. Per la decisione “quale gestionale scegliere” e il confronto con i prodotti italiani vedi la guida operativa a Business Central per le PMI; per la checklist generale di qualsiasi migrazione legacy→cloud (non solo gestionale) vedi la checklist migrazione gestionale legacy. Qui ci concentriamo sul percorso verso Business Central.

I tre punti di partenza (e perché contano)

Il piano di migrazione cambia molto a seconda di dove parti. Inquadrare bene il punto di partenza è il primo passo, perché determina dove si concentrano fatica e rischio.

Da un gestionale legacy datato. Software vecchio, spesso senza vendor attivo o con licenze ormai fuori supporto. Il problema principale è l’estrazione dei dati: database proprietari, schemi poco documentati, campi usati “creativamente” negli anni. Qui il lavoro grosso è tirare fuori i dati in modo pulito e capire cosa significano davvero.

Da un ERP on-premise strutturato. I dati sono più ordinati e accessibili, ma la sfida si sposta sui processi: l’azienda ha workflow consolidati, personalizzazioni storiche, abitudini radicate. La migrazione è anche un progetto di change management, non solo tecnico.

Da Excel (o da carta + Excel). Apparentemente il caso più semplice — i dati sono già in formato tabellare — ma in realtà il più insidioso. Negli Excel manca quasi sempre la disciplina del dato: codici cliente duplicati, partite IVA scritte in dieci formati diversi, nessun vincolo di integrità. Il vantaggio è che non c’è uno storico contabile complesso da migrare; lo svantaggio è che bisogna costruire da zero strutture che un ERP dà per scontate (piano dei conti, causali, anagrafiche normalizzate).

Fase 1 — Analisi dei processi e mappatura

Prima di toccare un solo dato, si parte dai processi. L’errore più comune è voler replicare in Business Central esattamente ciò che si faceva prima: si finisce per riprodurre anche le inefficienze e le scorciatoie nate dai limiti del vecchio strumento.

Si mappano i flussi reali dell’azienda — ciclo attivo (offerta → ordine → DDT → fattura), ciclo passivo, magazzino, contabilità, scadenzario — e si decide cosa tenere, cosa semplificare e cosa abbandonare. Business Central copre nativamente la stragrande maggioranza dei processi di una PMI: l’obiettivo è far aderire l’azienda agli standard del prodotto dove ha senso, riservando le personalizzazioni ai pochi processi che sono davvero un vantaggio competitivo.

Il deliverable è una mappa chiara di “stato attuale → stato futuro” e l’elenco delle entità dati da migrare. È anche il momento per coinvolgere i key user di ogni area (amministrazione, vendite, magazzino): sono loro a conoscere le eccezioni che nessun manuale documenta.

Fase 2 — Bonifica e mappatura dei dati anagrafici

Questa è la fase che decide il successo della migrazione, ed è quasi sempre sottostimata. La regola d’oro: i dati sporchi non migliorano migrando. Anzi, un ERP rigoroso fa emergere subito ogni incoerenza che il vecchio sistema (o Excel) tollerava.

La bonifica delle anagrafiche significa, in pratica:

  • Deduplicare clienti e fornitori (lo stesso soggetto presente più volte con codici diversi è la norma nei sistemi vecchi).
  • Normalizzare i campi fiscali: partita IVA, codice fiscale, codice destinatario SDI / PEC, indirizzi. Questi dati devono essere corretti al 100%, perché alimentano la fatturazione elettronica.
  • Razionalizzare i codici articolo: unificare doppioni, decidere la nuova codifica, ripulire articoli obsoleti che non servono nel nuovo sistema.
  • Mappare ogni campo del vecchio sistema verso il campo corrispondente di Business Central (la cosiddetta field mapping), gestendo i casi in cui un campo non ha un equivalente diretto.

Per chi parte da Excel, qui si costruiscono anche le strutture portanti che prima non esistevano: piano dei conti, causali contabili, gruppi di registrazione IVA, listini. È lavoro contabile più che informatico, da fare con il commercialista o con il responsabile amministrativo.

Un consiglio pratico: la bonifica conviene farla prima dell’import, lavorando sui file di staging, non dentro Business Central a migrazione avvenuta. Correggere a valle è molto più costoso.

Fase 3 — Migrazione di anagrafiche, saldi e storico

Una volta che i dati sono puliti e mappati, si esegue la migrazione vera e propria. Business Central offre strumenti nativi (configurazione assistita, pacchetti di configurazione, modelli Excel per l’import) che rendono il caricamento massivo gestibile senza sviluppo custom per i dati standard.

Vale la pena distinguere tre tipi di dato, perché si trattano in modo diverso:

  • Anagrafiche (clienti, fornitori, articoli, contatti): si migrano sempre, normalizzate. Sono il fondamento.
  • Saldi di apertura: non si migra di norma ogni singola registrazione storica, ma i saldi alla data di go-live (saldi contabili, partite aperte clienti/fornitori, giacenze di magazzino, valore cespiti). Così il nuovo sistema parte da un punto corretto senza trascinarsi decenni di scritture.
  • Storico: lo storico operativo (fatture passate, ordini chiusi, movimenti) di norma resta consultabile sul vecchio sistema o viene archiviato, e si migra solo se c’è una reale necessità gestionale o normativa. Migrare tutto lo storico è costoso e raramente ripaga: conviene partire “leggeri” e mantenere il legacy in sola lettura per il periodo di conservazione richiesto.

La scelta della data di go-live è strategica: tipicamente si sceglie l’inizio di un esercizio o di un periodo IVA, per avere saldi di apertura netti e semplificare la quadratura.

Fase 4 — Configurazione, parametrizzazione e fatturazione elettronica

In parallelo alla migrazione dati si configura il sistema: numerazioni documenti, layout di stampa, condizioni di pagamento, magazzini e ubicazioni, profili utente e permessi. Per il contesto italiano è centrale la configurazione della fatturazione elettronica via SDI, della liquidazione IVA e dei regimi fiscali, appoggiandosi al localization pack Microsoft e ai plugin partner per la compliance italiana.

Si configurano anche le integrazioni: Business Central si collega nativamente a Microsoft 365 (Outlook, Excel, Teams) e a Power BI per la reportistica, e via API o connettori a e-commerce, banche (CBI) e altri applicativi. Più integrazioni significa meno doppie imputazioni manuali, uno dei vantaggi concreti del passaggio.

Fase 5 — Test, go-live e affiancamento

Prima del go-live si esegue una fase di test e validazione: si verifica che i saldi migrati quadrino con il vecchio sistema, si emette qualche documento di prova end-to-end (ordine → DDT → fattura elettronica → SDI), si controllano i report. È buona norma una sessione di test con dati reali con i key user, per intercettare le ultime sorprese.

Il go-live può essere “big bang” (tutto in un colpo a una data) — la modalità più comune per le PMI — oppure graduale per moduli. Subito dopo il passaggio è cruciale l’affiancamento (hypercare): nelle prime settimane gli utenti vanno supportati da vicino, perché è lì che emergono i casi non previsti e si consolidano le nuove abitudini. La formazione non è un evento una tantum ma accompagna l’avvio.

Rischi tipici (e come evitarli)

Dall’esperienza sul campo, i rischi ricorrenti in una migrazione a Business Central sono pochi e prevedibili:

  • Sottostimare la bonifica dati. È la prima causa di slittamento. Dedica tempo e risorse vere alla pulizia, prima dell’import.
  • Voler migrare tutto lo storico. Aumenta costi e complessità senza un ritorno proporzionato. Migra saldi, archivia il resto.
  • Replicare il vecchio invece di adottare lo standard. Personalizzazioni eccessive rendono fragili gli aggiornamenti cloud e gonfiano i costi.
  • Trascurare formazione e affiancamento. Un ERP perfetto ma usato male produce dati sbagliati dal giorno uno.
  • Scegliere male la data di go-live. Un avvio a metà esercizio complica le quadrature.

Perché farlo con un partner

Migrare a Business Central è un progetto che intreccia competenze informatiche, contabili e di processo: estrarre dati da sistemi proprietari, normalizzare anagrafiche fiscali, configurare la fatturazione SDI, formare le persone. Una PMI raramente ha tutte queste competenze in casa, e farlo “in economia” è la ricetta per un avvio doloroso.

Come partner Microsoft (Cloud Solution Provider), in SynSphere accompagniamo le PMI italiane lungo l’intero percorso: dall’analisi dei processi alla bonifica dei dati, dalla migrazione di anagrafiche e saldi al go-live, fino all’affiancamento e all’assistenza applicativa continuativa. Le licenze Business Central (Essentials, Premium, Team Members, per-utente/mese via CSP) le gestiamo direttamente come parte del progetto.

Vuoi capire come sarebbe il passaggio per la tua azienda? Parti dalla pagina licenze Dynamics 365 e dalla scheda Dynamics 365 Business Central, poi parla con un nostro consulente: valutiamo insieme il punto di partenza e disegniamo un piano per fasi su misura.

Domande frequenti

Quanto tempo serve per migrare una PMI a Business Central?

Dipende molto dal punto di partenza e dalla qualità dei dati. Una PMI con processi standard e dati ordinati può completare il percorso in pochi mesi; chi parte da un legacy datato con anagrafiche da bonificare o da molti fogli Excel non strutturati richiede più tempo, perché la fase di pulizia e mappatura dei dati è quella che pesa di più. La stima realistica si fa solo dopo l’analisi dei processi.

Devo migrare tutto lo storico contabile e i documenti passati?

Nella maggior parte dei casi no. Si migrano le anagrafiche normalizzate e i saldi di apertura alla data di go-live (saldi contabili, partite aperte, giacenze, cespiti), mentre lo storico operativo resta consultabile sul vecchio sistema o viene archiviato in sola lettura per il periodo di conservazione richiesto. Migrare tutto lo storico è costoso e raramente ripaga: conviene partire leggeri.

Si può passare a Business Central partendo solo da fogli Excel?

Sì, ed è uno scenario molto comune nelle PMI. I dati Excel sono già tabellari, ma vanno normalizzati (deduplica, formati fiscali, codifiche) e soprattutto vanno costruite da zero le strutture che un ERP richiede: piano dei conti, causali, gruppi IVA, listini. È un lavoro contabile più che informatico, da fare con il responsabile amministrativo o il commercialista, ma del tutto fattibile con un approccio per fasi.

Qual è l’errore più frequente in una migrazione a Business Central?

Sottostimare la bonifica dei dati. I dati sporchi non migliorano migrando: un ERP rigoroso fa emergere subito ogni duplicato o incoerenza che il vecchio sistema tollerava. Conviene investire tempo nella pulizia delle anagrafiche prima dell’import, lavorando sui file di staging e non correggendo a valle dentro Business Central.

Prodotti SynSphere correlati

I prodotti del catalogo SynSphere richiamati in questo articolo.