Cambiare software di protocollo informatico: come non perdere tutti i dati?

Migrazione software protocollo informatico: cambiare sistema senza perdere la storia dei documenti

Cambiare software di protocollo informatico non significa spostare una cartella di file in formato PDF da un server a un altro.

Il rischio più insidioso durante una migrazione non è necessariamente perdere un file. È trasferirlo e ritrovarlo nel nuovo sistema senza riuscire più a ricostruire con sufficiente precisione quando era stato registrato, con quale numero di protocollo, da chi proveniva, a quale fascicolo apparteneva, quali allegati aveva e quali relazioni documentali erano state costruite intorno a esso.

Il file può quindi sopravvivere alla migrazione mentre una parte della sua storia scompare.

Per questo una migrazione software protocollo informatico va progettata come il trasferimento di un sistema documentale, non come una semplice operazione di copia.

La distinzione è particolarmente importante per le Pubbliche Amministrazioni. Il D.P.R. 445/2000 disciplina la registrazione di protocollo e il sistema di gestione informatica dei documenti, mentre le Linee Guida AgID sulla formazione, gestione e conservazione dei documenti informatici costituiscono il riferimento tecnico pubblicato dall’Agenzia per formazione, protocollazione, gestione e conservazione.

Prima di sostituire un gestionale, quindi, non basta verificare se tutti i documenti possano essere importati.

Occorre accertare che nel nuovo ambiente restino identificabili, comprensibili, reperibili e correttamente inseriti nel loro contesto documentale.

È su questa differenza che si misura la qualità di una migrazione.

Migrazione software protocollo informatico: cosa deve essere realmente trasferito

Un sistema di protocollo non contiene soltanto file.

Le Linee Guida AgID descrivono la registrazione informatica attraverso dati in forma elettronica allegati o connessi al documento e precisano che, al termine della registrazione, il documento è identificato da un insieme di dati che può integrarsi fin da questa fase con classificazione e organizzazione delle aggregazioni documentali.

Nel vecchio sistema possono quindi essere presenti:

• documenti e relativi allegati;

• registrazioni di protocollo;

• numero e data di protocollo;

• mittenti e destinatari;

• oggetti;

• impronte dei documenti informatici;

• classificazioni;

• fascicoli e altre aggregazioni documentali;

• collegamenti tra documenti;

• assegnazioni;

• AOO e strutture organizzative;

• registrazioni particolari;

• utenti, ruoli e autorizzazioni;

• annullamenti e relativa storicizzazione;

• PEC, allegati e ricevute;

• registri;

• eventuali informazioni collegate ai workflow;

• documentazione già trasferita al sistema di conservazione.

Non tutti questi elementi saranno necessariamente presenti in ogni installazione, ma il perimetro deve essere conosciuto prima di progettare l’importazione.

Contare semplicemente i file prima e dopo il trasferimento significa verificare soltanto uno strato del problema.

Due archivi possono contenere lo stesso numero di file ed essere documentalmente molto diversi.

Checklist per cambiare software di protocollo informatico

1. Censire il patrimonio prima di parlare di importazione

La prima fase non riguarda il nuovo software. Riguarda quello che esiste già.

Prima di progettare la migrazione software protocollo informatico occorre conoscere la consistenza dell’ambiente precedente: anni di protocollo presenti, numero di registrazioni, documenti e allegati, fascicoli, eventuali AOO, classificazioni utilizzate, registrazioni particolari, PEC, anagrafiche, autorizzazioni e integrazioni.

Chiedere soltanto quanti gigabyte occupa l’archivio significa misurare il contenitore, non il contenuto.

Il censimento dovrebbe permettere di individuare almeno:

1. registrazioni di protocollo suddivise per anno;

2. documenti e allegati associati;

3. fascicoli e altre aggregazioni documentali;

4. piano o piani di classificazione utilizzati;

5. registri e repertori presenti;

6. AOO e strutture organizzative;

7. PEC, messaggi, allegati e ricevute;

8. collegamenti tra documenti;

9. documentazione già trasferita in conservazione;

10. eventuali integrazioni e workflow che producono o utilizzano informazioni documentali.

Questa fotografia iniziale diventa il riferimento per il collaudo.

Senza sapere cosa esiste prima è molto più difficile dimostrare, alla fine, che il trasferimento sia stato completo.

2. Capire cosa può essere realmente esportato

“Il vecchio software permette l’export” non è una risposta sufficiente.

Bisogna sapere cosa esporta, in quale formato e mantenendo quali relazioni.

Un CSV contenente numero, data e oggetto può apparire soddisfacente fino a quando si scopre che non conserva i riferimenti agli allegati, ai fascicoli, alle classificazioni o ad altre informazioni necessarie per interpretare correttamente il documento.

Per questo, nella migrazione software protocollo informatico, un progetto di migrazione della gestione documentale dovrebbe prevedere un mapping dei dati:

dato di origine → eventuale trasformazione → dato di destinazione

Non tutti i sistemi utilizzano lo stesso modello informativo.

Un campo presente nel precedente gestionale può non avere un equivalente diretto nel nuovo. In quel caso bisogna decidere consapevolmente se mapparlo, trasformarlo, conservarlo come informazione storica oppure escluderlo perché non rilevante per il patrimonio da preservare.

La decisione va presa prima dell’importazione, non scoperta a trasferimento concluso.

3. Preservare l’identità delle registrazioni storiche

Su questo punto è importante distinguere la norma dalla soluzione tecnica adottata per la migrazione software protocollo informatico.

L’articolo 53 del D.P.R. 445/2000 stabilisce che numero e data di protocollo siano generati automaticamente dal sistema e registrati in forma non modificabile. La stessa disposizione disciplina anche mittente o destinatario, oggetto, eventuale data e protocollo del documento ricevuto e impronta del documento informatico nei casi previsti.

Le Linee Guida AgID prevedono inoltre tracciamento e storicizzazione delle operazioni e disciplinano l’annullamento delle informazioni registrate in forma immodificabile.

La normativa non stabilisce, però, una procedura universale di migrazione applicabile indistintamente a qualsiasi software.

La conseguenza progettuale è che lo storico deve continuare a essere rappresentato come storico.

Una registrazione effettuata, per esempio, il 14 marzo 2021 con protocollo n. 0004873 deve restare riconoscibile nel nuovo ambiente come quella registrazione originaria.

Importarla come se si trattasse semplicemente di un nuovo documento da protocollare rischierebbe di sovrapporre una nuova identità amministrativa a quella già esistente.

Il sistema di destinazione deve quindi permettere di distinguere con chiarezza le registrazioni storiche importate dalle registrazioni prodotte dopo il passaggio al nuovo applicativo.

4. Migrare i metadati insieme ai documenti

Un PDF chiamato documento_4873.pdf racconta ben poco.

Sono i dati associati al documento a permettere di identificarlo, collocarlo e interpretarlo nel sistema.

AgID dedica l’Allegato 5 delle Linee Guida proprio ai metadati e prevede metadati anche per documenti e aggregazioni documentali informatiche. La classificazione, inoltre, costituisce parte integrante dei metadati previsti per i documenti amministrativi informatici.

Durante la migrazione software protocollo informatico bisogna quindi verificare se il modello di destinazione sia in grado di rappresentare adeguatamente le informazioni provenienti dal vecchio sistema.

Quando un campo non trova una corrispondenza diretta, occorre stabilire se:

• creare o utilizzare un campo equivalente;

• applicare una trasformazione documentata;

• mantenerlo come informazione storica;

• escluderlo sulla base di una valutazione motivata.

Il criterio non dovrebbe essere semplicemente “importiamo ciò che il nuovo software prevede”.

Il punto è capire quali informazioni servono affinché il patrimonio trasferito continui a essere correttamente leggibile e utilizzabile.

5. Non trasformare i fascicoli in mucchi di documenti

Una migrazione software protocollo informatico può trasferire centinaia di migliaia di file e produrre comunque un archivio peggiore del precedente.

Succede quando i documenti arrivano tutti, ma arrivano isolati.

Le Linee Guida AgID stabiliscono che la classificazione organizzi logicamente i documenti e che, nelle Pubbliche Amministrazioni, i flussi documentali siano gestiti anche mediante fascicoli informatici predisposti secondo il piano di classificazione e l’organizzazione delle aggregazioni documentali.

Nel collaudo bisogna quindi verificare non soltanto l’esistenza del singolo file, ma anche le associazioni rilevanti:

• documento principale e allegati;

• documento e fascicolo;

• classificazione;

• collegamenti tra registrazioni;

• eventuali sottoaggregazioni;

• relazioni tra corrispondenza ricevuta e documenti prodotti;

• altri collegamenti gestiti dal sistema precedente.

Lo stesso principio riemerge nella conservazione: le Linee Guida richiamano il rispetto dell’organizzazione che fascicoli e serie possedevano nell’archivio corrente.

Un archivio non è una pila di file. È una struttura di relazioni.

6. Distinguere la classificazione storica da quella futura

Il cambio di piattaforma può coincidere con una revisione del piano di classificazione.

Sono però due operazioni diverse.

AgID stabilisce che la classificazione abbia la funzione di organizzare logicamente i documenti e che, per la PA, sia un’attività obbligatoria nel sistema di gestione informatica dei documenti dell’AOO.

Se dal momento del go-live viene adottata una classificazione diversa, è quindi importante che lo storico rimanga comprensibile secondo il contesto con cui era stato originariamente organizzato.

La migrazione software protocollo informatico non dovrebbe diventare una riclassificazione retroattiva indiscriminata.

La nuova struttura può migliorare la gestione futura senza cancellare la chiave con cui è stato costruito il passato.

7. Ridisegnare utenti e permessi senza trascinarsi autorizzazioni obsolete

Utenti, ruoli e autorizzazioni richiedono una verifica separata.

Le Linee Guida prevedono, tra i requisiti minimi di sicurezza del sistema di protocollo, l’identificazione e autenticazione univoca degli utenti, l’accesso alle risorse da parte dei soli soggetti abilitati e il tracciamento degli eventi di modifica con individuazione dell’autore.

Questo non implica che anni di permessi debbano essere copiati automaticamente nel nuovo software.

La migrazione software protocollo informatico è anzi un buon momento per separare:

• ciò che deve restare disponibile come informazione storica;

• ciò che deve diventare una reale autorizzazione operativa nel nuovo ambiente.

Un utente non più presente nell’organizzazione, per esempio, può essere rilevante per comprendere lo storico delle attività senza dover necessariamente conservare un account utilizzabile.

Preservare la storia non significa preservare privilegi superati.

8. Verificare PEC, allegati e ricevute

Se il precedente software gestiva anche la posta elettronica certificata, la PEC non dovrebbe essere trattata come un unico file da esportare.

Bisogna individuare messaggio, allegati, ricevute e relazioni con registrazione di protocollo e fascicolo.

Su questo tema AgID fornisce anche una precisazione utile: le ricevute di accettazione e consegna della PEC non devono essere protocollate autonomamente, ma devono essere associate alla registrazione di protocollo del documento trasmesso o ricevuto a cui si riferiscono.

In fase di migrazione software protocollo informatico, quindi, non basta sapere che le ricevute esistono.

Bisogna verificare che sia possibile ricostruire correttamente il rapporto tra comunicazione, documento e relative evidenze di trasmissione.

9. Non confondere gestione documentale e conservazione

Cambiare software di protocollo non significa automaticamente cambiare sistema di conservazione.

Le Linee Guida sono esplicite: il sistema di conservazione è almeno logicamente distinto dal sistema di gestione informatica dei documenti. Inoltre, il sistema di gestione trasferisce al sistema di conservazione documenti, fascicoli, serie e relativi metadati secondo le regole previste.

Prima della migrazione software protocollo informatico è quindi necessario distinguere chiaramente:

ciò che si trova ancora nel sistema di gestione documentale da ciò che è già stato trasferito in conservazione.

Se insieme al software di protocollo viene cambiato anche il servizio o il sistema di conservazione, il progetto assume un perimetro ulteriore e richiede una specifica analisi dei processi e degli oggetti coinvolti.

Per lo stesso motivo, un backup del database non equivale alla conservazione digitale.

Sono strumenti con finalità e regole diverse.

10. Verificare i registri di protocollo

Il cambio di software non deve creare una zona grigia tra l’ultimo giorno gestito dal sistema precedente e il primo giorno del nuovo.

Le Linee Guida AgID vigenti stabiliscono che il registro giornaliero di protocollo sia versato entro la giornata lavorativa successiva nel sistema di conservazione, garantendo l’immodificabilità del contenuto.

Nella migrazione software protocollo informatico, prima del passaggio è quindi opportuno controllare che i registri previsti siano stati prodotti, siano reperibili e che vi sia continuità tra i due ambienti.

Nel 2026 AgID ha inoltre avviato una consultazione pubblica su un documento di indirizzo dedicato alla produzione, conservazione e scarto dei registri annuale, giornaliero e di emergenza. La consultazione è stata formalmente avviata con il provvedimento n. 72/2026.

Il materiale sottoposto a consultazione va però distinto dalle Linee Guida vigenti e non deve essere utilizzato per sostituire automaticamente le regole già applicabili.

11. Fare una migrazione software protocollo informatico di prova prima del go-live

La prima importazione non dovrebbe essere quella definitiva.

Un ambiente di test consente di individuare anomalie quando è ancora possibile correggerle senza coinvolgere il sistema operativo.

Il campione deve essere sufficientemente eterogeneo:

• documenti recenti e molto vecchi;

• protocolli annullati;

• record con più allegati;

• fascicoli complessi;

• PEC;

• documenti firmati digitalmente;

• differenti classificazioni;

• registrazioni appartenenti a diverse AOO, se presenti;

• documenti sottoposti a restrizioni di accesso;

• record collegati ad altri documenti.

Il confronto utile è:

sistema origine → dato esportato → sistema destinazione

È in questo passaggio che emergono anomalie che un semplice conteggio non mostra: date trasformate, campi troncati, caratteri non gestiti, allegati separati dal documento principale, relazioni mancanti o valori modificati durante il mapping.

12. Definire un collaudo che possa anche fallire

“Importazione completata con successo” è un messaggio tecnico.

Non dimostra che l’archivio sia stato migrato correttamente.

I criteri di accettazione dovrebbero essere stabiliti prima dell’import definitivo e comprendere controlli quantitativi e qualitativi.

Tra gli indicatori utili:

• registrazioni attese e importate;

• documenti e allegati;

• fascicoli;

• record non importati;

• anomalie;

• metadati trasformati;

• classificazioni;

• permessi;

• reperibilità dei documenti;

• leggibilità dei file;

• collegamenti tra oggetti documentali.

Quando le impronte storicamente memorizzate sono disponibili e tecnicamente confrontabili, il loro controllo può essere utilizzato anche come ulteriore verifica dell’integrità.

Il 100% nella colonna “file copiati” è soltanto uno degli indicatori.

La migrazione software protocollo informatico è riuscita quando il nuovo sistema permette di comprendere e utilizzare correttamente il patrimonio trasferito.

13. Definire con precisione il momento della migrazione software protocollo informatico

Il passaggio deve avere un punto di separazione inequivocabile.

Occorre stabilire:

1. l’ultima registrazione effettuata nel sistema precedente;

2. il momento dell’export definitivo;

3. il blocco delle nuove operazioni sul vecchio ambiente;

4. l’importazione delle informazioni residue;

5. le verifiche finali;

6. l’attivazione del nuovo protocollo;

7. la gestione delle eventuali anomalie;

8. le procedure da utilizzare in caso di indisponibilità.

Per le Pubbliche Amministrazioni il tema interessa anche la continuità del servizio e le procedure di emergenza previste dal sistema di gestione documentale.

Il giorno del passaggio non dovrebbe essere il momento in cui vengono prese decisioni importanti.

Se il go-live è sorprendentemente ordinario, significa che buona parte del lavoro difficile è stata fatta prima.

14. Aggiornare il Manuale di gestione documentale

Cambiare applicativo può modificare strumenti, procedure, autorizzazioni e modalità operative.

Il Manuale di gestione documentale non può quindi essere considerato un documento separato dall’evoluzione del sistema.

AgID stabilisce che il Manuale descriva il sistema di gestione informatica dei documenti e fornisca le istruzioni per il corretto funzionamento del servizio di protocollo, gestione dei flussi documentali e archivi.

Quando il nuovo software modifica elementi descritti nel Manuale, occorre verificarne l’aggiornamento in modo che procedure documentate e funzionamento reale rimangano coerenti.

La migrazione software protocollo informatico, sul piano tecnico, e quella organizzativa devono arrivare allo stesso traguardo.

Cosa verificare con il nuovo fornitore prima di firmare

La qualità dell’interfaccia conta, ma racconta soprattutto come verranno gestiti i documenti futuri.

Per valutare una migrazione software protocollo informatico, la parte più interessante della software selection è quella che normalmente non compare nella schermata iniziale della demo.

Prima della scelta conviene ottenere indicazioni precise su:

• modalità con cui verrà analizzato il sistema precedente;

• formati di esportazione accettati;

• oggetti documentali effettivamente migrabili;

• gestione dei metadati;

• mapping tra sorgente e destinazione;

• rappresentazione delle registrazioni storiche;

• ricostruzione di fascicoli e collegamenti;

• gestione di PEC, allegati e ricevute;

• disponibilità di un ambiente di test;

• criteri di collaudo;

• gestione e documentazione delle anomalie;

• eventuale mantenimento temporaneo del precedente archivio in sola lettura;

• procedura da seguire se il collaudo non viene superato;

• possibilità futura di esportare nuovamente documenti e dati.

Quest’ultimo punto merita particolare attenzione.

La possibilità di entrare agevolmente in una piattaforma è importante. La capacità di uscirne in futuro senza trasformare i propri dati in ostaggi tecnologici lo è altrettanto.

Mantenere temporaneamente consultabile il vecchio sistema

Lo spegnimento immediato del precedente applicativo non è necessariamente l’unica strategia possibile.

Nel contesto di una migrazione software protocollo informatico, in alcuni progetti può essere utile mantenerlo per un periodo definito in sola consultazione, mentre tutte le nuove attività vengono eseguite nel nuovo sistema.

Può essere una scelta prudente quando lo storico è molto esteso, esistono personalizzazioni particolari o alcune informazioni richiedono ulteriori verifiche dopo il go-live.

La fase transitoria deve però essere governata.

Il rischio da evitare è la nascita di due sistemi operativi paralleli, con utenti incerti su dove registrare i nuovi documenti o quale archivio rappresenti la fonte corretta.

Un eventuale periodo di consultazione del legacy deve quindi avere regole, responsabilità e una conclusione definita.

Migrazione completa o gestione separata di una parte dello storico

Portare ogni oggetto nel nuovo applicativo non è necessariamente l’unico modello tecnico possibile.

In alcune situazioni può essere opportuno integrare totalmente lo storico. In altre può essere valutato il mantenimento di parte della documentazione pregressa in un ambiente legacy governato e consultabile oppure nel sistema di conservazione, a seconda della natura dei documenti e dello stato dei relativi processi.

Per una PA, una scelta di questo tipo non può essere guidata soltanto da costi e comodità tecnica. Deve tenere conto delle esigenze archivistiche, dei vincoli applicabili, dell’organizzazione delle aggregazioni documentali, della reperibilità e delle responsabilità definite dall’ente.

Il criterio da evitare è migrare soltanto ciò che risulta più semplice importare.

Prima viene stabilito cosa deve rimanere disponibile, comprensibile e correttamente gestito. Poi si decide attraverso quale soluzione tecnica.

Migrazione della gestione documentale: migliorare senza riscrivere il passato

Cambiare piattaforma porta spesso in superficie problemi che il lavoro quotidiano aveva reso quasi invisibili.

Anagrafiche duplicate, metadati compilati in modo incoerente, fascicoli organizzati secondo criteri differenti, autorizzazioni stratificate, PEC gestite fuori dal sistema e workflow interrotti da passaggi manuali possono emergere proprio durante l’analisi preliminare.

La migrazione software protocollo informatico può diventare una buona occasione per intervenire su questi attriti.

Bisogna però distinguere nettamente tre operazioni: preservare lo storico, bonificare ciò che può essere corretto e progettare meglio il futuro.

Una classificazione utilizzata in passato non diventa automaticamente errata perché oggi ne viene adottata una diversa. Allo stesso modo, la necessità di migliorare un processo futuro non autorizza a rendere meno comprensibile il modo in cui i documenti sono stati organizzati negli anni precedenti.

La migrazione deve migliorare il sistema, non riscriverne retroattivamente la memoria.

Migrazione software protocollo informatico: perché scegliere Arcadoc

Dopo aver analizzato ciò che rende complesso un cambio di piattaforma, il criterio di scelta diventa più concreto.

Il software di destinazione non deve soltanto protocollare correttamente i nuovi documenti. Deve permettere di costruire una gestione documentale nella quale lo storico trasferito possa continuare a essere utilizzato insieme ai nuovi flussi.

Arcadoc parte proprio da questa integrazione. Protocollo informatico e gestione documentale costituiscono il nucleo della piattaforma, al quale possono essere affiancati PEC Manager, Workflow documentale e Conservazione a norma. Non si tratta quindi di trasferire lo storico in un nuovo contenitore per poi ricostruire altrove fascicoli, comunicazioni e processi: la nuova organizzazione documentale può essere progettata nello stesso ecosistema in cui continueranno a essere gestiti i documenti. È un aspetto che pesa più di quanto possa sembrare durante una demo.

L’interfaccia del nuovo software si impara. Una migrazione incompleta, invece, può lasciare per anni documenti difficili da ricercare, collegamenti da ricostruire e informazioni distribuite tra vecchio e nuovo sistema.

Con Arcadoc il progetto può partire dall’archivio esistente e arrivare alla configurazione del nuovo ambiente mantenendo nella stessa piattaforma protocollo, fascicolazione, ricerca documentale, AOO, livelli di accesso e gestione degli allegati.

PEC Manager: la PEC entra davvero nel processo documentale

Uno dei vantaggi dell’ecosistema Arcadoc è particolarmente evidente nella gestione della posta elettronica.

Con PEC Manager è possibile gestire più caselle PEC e PEO dalla piattaforma, avviare la protocollazione dei messaggi in entrata e utilizzare la protocollazione integrata per quelli in uscita. Le ricevute PEC vengono inoltre associate automaticamente al messaggio originario.

Il risultato è una gestione più continua della corrispondenza: la PEC non rimane confinata nella casella di posta mentre protocollo e fascicolo vivono altrove.

Questo diventa particolarmente utile dopo una migrazione, perché consente di evitare di ricreare quella frammentazione tra strumenti che spesso rende più difficile seguire il percorso di un documento.

Meno passaggi tra applicazioni significa anche meno punti in cui il contesto documentale rischia di disperdersi.

Se stai valutando di sostituire il tuo attuale software di protocollo, il primo passo può essere l’analisi dell’archivio esistente: struttura dei dati, registrazioni, metadati, fascicoli, PEC e relazioni da preservare.

Da questa analisi è possibile definire un percorso di migrazione verso Arcadoc costruito sul patrimonio documentale reale dell’organizzazione.

Il risultato da cercare non è semplicemente avere gli stessi file dentro un software nuovo. È poter cambiare piattaforma senza perdere il filo che tiene insieme la storia dei documenti.

Facciamo una chiacchierata per approfondire meglio! Clicca qui e scrivici!