Zmiana systemu DMS: dlaczego eksport wszystkich dokumentów do PDF może nie wystarczyć?

Eksport do PDF wygląda jak najprostszy sposób zamknięcia starego systemu DMS: pobieramy dokumenty, zapisujemy je na serwerze, sprawdzamy liczbę plików i wyłączamy dotychczasowe rozwiązanie. Problem pojawia się kilka miesięcy później, gdy trzeba ustalić, kto zaakceptował umowę, jaka wersja dokumentu była obowiązująca, kiedy zmieniono kategorię sprawy albo z jakim kontrahentem powiązany był konkretny załącznik.

PDF zachowuje treść dokumentu. Nie musi jednak zachowywać informacji, które w systemie DMS nadawały temu dokumentowi znaczenie biznesowe.

Dlatego przy zmianie DMS pytanie nie powinno brzmieć: „czy mamy wszystkie pliki?”. Znacznie ważniejsze jest: czy po wyłączeniu starego systemu nadal będziemy potrafili odtworzyć dokument wraz z jego kontekstem, historią i powiązaniami?

PDF przechowuje dokument, ale niekoniecznie przechowuje jego kontekst

Typowy DMS przechowuje znacznie więcej niż sam plik. Obok dokumentu mogą znajdować się między innymi:

• numer sprawy lub teczki,
• typ dokumentu,
• właściciel dokumentu,
• kontrahent,
• data wpływu i data rejestracji,
• status procesu,
• kategoria archiwizacyjna,
• termin obowiązywania,
• numer umowy albo zamówienia,
• informacje o akceptacji,
• historia kolejnych wersji,
• komentarze,
• relacje z innymi dokumentami,
• dane dotyczące podpisu elektronicznego,
• logi operacji wykonanych przez użytkowników.

Po zwykłym eksporcie do katalogu z plikami część tych danych może zniknąć.

Dobrym przykładem są umowy. W DMS firma ma 20 tys. dokumentów, które można filtrować według kontrahenta, rodzaju umowy, daty zakończenia i osoby odpowiedzialnej. Po migracji wszystkie pliki znajdują się w strukturze katalogów jako PDF-y. Formalnie dokumentacja została wyeksportowana. Operacyjnie firma straciła jednak możliwość szybkiego znalezienia umów kończących się w ciągu 30 dni.

Można próbować przenieść część metadanych do nazw plików:

2026-00125_ACME_umowa_serwisowa_2026-12-31.pdf

Takie rozwiązanie sprawdza się przy niewielkim archiwum i prostych wymaganiach. Ma jednak wyraźne ograniczenia. Nazwa pliku nie zastąpi kilkunastu pól metadanych, a przy rozbudowanej dokumentacji szybko powstają problemy z długością nazw, znakami specjalnymi, powtarzalnością i zmianą wartości.

Lepszym rozwiązaniem może być eksport:

PDF + metadane w CSV, XML lub JSON + identyfikator łączący rekord z dokumentem.

Przykładowo dokument DOC-0001428.pdf może mieć odpowiadający mu rekord:

DOC-0001428 | umowa | ACME Sp. z o.o. | 2026-04-12 | ważna | właściciel: Jan Kowalski | sprawa: SPR-2841

To podejście ma sens, jeżeli nowe rozwiązanie potrafi zaimportować takie dane albo firma potrzebuje zachować archiwum możliwe do przeszukiwania.

Sam PDF może wystarczyć wtedy, gdy dokumenty są już historyczne, praktycznie nie są wyszukiwane według metadanych, nie uczestniczą w aktywnych procesach i firma potrzebuje jedynie zachować ich czytelną treść przez wymagany okres.

Nie wystarczy natomiast tam, gdzie dokument jest elementem procesu. Umowa bez daty obowiązywania, faktura bez powiązania ze sprawą albo dokument jakościowy bez numeru wersji nadal istnieje, ale traci część swojej wartości użytkowej.

Najwięcej problemów wychodzi przy wersjach, workflow i śladzie audytowym

Drugim częstym błędem jest założenie, że ostatnia wersja pliku przedstawia całą historię dokumentu.

W wielu systemach DMS jeden rekord może zawierać kilka lub kilkanaście wersji. Użytkownik widzi wersję aktualną, ale system pamięta wcześniejsze. Przy zwykłym eksporcie często pobierana jest tylko ostatnia.

Wyobraźmy sobie procedurę jakościową:

• wersja 1 obowiązywała od stycznia do marca,
• wersja 2 od kwietnia do sierpnia,
• wersja 3 obowiązuje obecnie.

Jeżeli podczas migracji zachowana zostanie wyłącznie wersja 3, po roku trudno będzie wykazać, jakie wymagania obowiązywały w momencie wykonania konkretnej czynności w lutym.

Podobnie wygląda sytuacja z akceptacją dokumentów. Sam PDF faktury nie mówi, że:

1. dokument wpłynął 4 maja,
2. dział zakupów potwierdził zgodność z zamówieniem 5 maja,
3. kierownik zaakceptował koszt 6 maja,
4. księgowość skierowała dokument do płatności 7 maja.

Jeżeli taka historia ma znaczenie dowodowe, kontrolne albo operacyjne, trzeba zdecydować, czy będzie migrowana jako dane strukturalne, raport historyczny czy inny trwały zapis.

Szczególnej uwagi wymagają podpisy elektroniczne. Konwersja podpisanego pliku do PDF może zmienić charakter dokumentu. Jeżeli źródłem był podpisany elektronicznie PDF, XML albo inny plik zawierający podpis, nie należy automatycznie zakładać, że jego wydruk lub ponowny zapis do PDF zachowa możliwość technicznej weryfikacji podpisu.

W praktyce przed migracją warto podzielić dokumenty co najmniej na trzy grupy:

• dokumenty, dla których wystarczy aktualna treść,
• dokumenty wymagające zachowania wersji i metadanych,
• dokumenty wymagające zachowania oryginalnego pliku wraz z podpisem, znacznikiem czasu albo innymi danymi technicznymi.

Nie każda firma musi przenosić pełne logi systemowe. Dla archiwalnych materiałów marketingowych byłoby to zwykle niepotrzebne. Inaczej wygląda jednak dokumentacja regulowana, dokumentacja kadrowa, umowy, dokumenty finansowe czy procedury podlegające audytowi.

Pełna migracja historii również ma koszt. Eksport kilku milionów logów i ich odwzorowanie w nowym DMS może być znacznie trudniejsze niż przeniesienie samych dokumentów. Dlatego nie chodzi o zasadę „migruj wszystko”. Trzeba ustalić minimalny zestaw danych, który pozwoli odtworzyć proces w zakresie rzeczywiście potrzebnym firmie.

Migrację trzeba zaprojektować od strony nowego systemu, nie starego archiwum

Najbezpieczniejsza kolejność jest odwrotna od tej, którą wybiera wiele firm. Najpierw trzeba ustalić, jak dokumenty mają działać po migracji, a dopiero potem przygotowywać eksport.

Załóżmy, że przedsiębiorstwo przechodzi ze starego DMS zawierającego 300 tys. dokumentów. W poprzednim systemie funkcjonuje 40 pól metadanych. Nowy system wykorzystuje tylko 18.

Najgorsze rozwiązanie to mechaniczne skopiowanie 40 pól albo, w drugą stronę, rezygnacja ze wszystkich i pozostawienie samych PDF-ów.

Trzeba wykonać mapowanie.

Przykładowo:

• Kontrahent_ID → ID kontrahenta,
• Data_wygasniecia → Data końca obowiązywania,
• Opiekun → Właściciel dokumentu,
• Numer_sprawy → Identyfikator procesu.

Przy okazji wychodzą problemy, których nie widać podczas prostego kopiowania plików. W starym systemie jeden użytkownik wpisywał nazwę kontrahenta jako „ABC”, inny jako „ABC Sp. z o.o.”, a kolejny jako „ABC spółka z ograniczoną odpowiedzialnością”. Nowy system może wymagać jednej wartości powiązanej z kartoteką kontrahentów.

Migracja jest więc również momentem porządkowania danych. Trzeba jednak uważać z automatycznym „czyszczeniem”. Zmiana historycznych danych może utrudnić późniejsze wyjaśnienie, dlaczego określony rekord wyglądał wcześniej inaczej.

Przed wyborem sposobu migracji trzeba sprawdzić możliwości, jakie oferuje nowy program do zarządzania dokumentami: obsługiwane formaty importu, możliwość zachowania własnych identyfikatorów, import metadanych, wersjonowanie, relacje między dokumentami oraz sposób przechowywania dokumentów podpisanych elektronicznie. To właśnie ograniczenia systemu docelowego często decydują, czy dane można przenieść bezpośrednio, czy trzeba przygotować warstwę pośrednią.

W praktyce dobrze działa migracja etapowa.

Najpierw próbka. Nie 50 losowych PDF-ów, tylko reprezentatywny zestaw obejmujący różne przypadki: dokument z kilkoma wersjami, dokument podpisany, rekord z brakującym polem, dokument powiązany z inną sprawą, duży załącznik oraz dokument zawierający polskie znaki w nazwie.

Następnie trzeba sprawdzić:

• czy zgadza się liczba dokumentów,
• czy zgadzają się identyfikatory,
• czy można wyszukiwać po wymaganych metadanych,
• czy zachowano właściwą wersję,
• czy działają powiązania między dokumentami,
• czy dokumenty podpisane można nadal zweryfikować,
• czy daty nie zmieniły się podczas importu,
• czy uprawnienia zostały odwzorowane zgodnie z założeniami.

Dopiero po takim teście ma sens masowa migracja.

Trzeba też ustalić, co zrobić ze starym DMS. Natychmiastowe wyłączenie go po imporcie jest wygodne finansowo, ale ryzykowne. Rozsądniejszy może być okres przejściowy, podczas którego system pozostaje dostępny tylko do odczytu. Długość takiego okresu zależy od skali i znaczenia dokumentacji. Przy krytycznym repozytorium kilka tygodni równoległej weryfikacji jest znacznie bezpieczniejsze niż wyłączenie starego środowiska dzień po migracji.

Najbardziej irytujący problem zwykle pojawia się przy detalach: brakujących załącznikach, polach wielokrotnego wyboru, niestandardowych formatach dat czy rekordach tworzonych przez dawno usuniętych użytkowników. Dlatego wynik migracji trzeba kontrolować nie tylko przez porównanie liczby plików. 300 000 rekordów w starym systemie i 300 000 PDF-ów w nowym nie oznacza jeszcze poprawnej migracji.

FAQ

Czy przy zmianie DMS trzeba migrować wszystkie dokumenty?
Nie zawsze. Dokumenty, których okres przechowywania już minął i które zgodnie z obowiązującymi zasadami mogą zostać usunięte, nie powinny być automatycznie przenoszone tylko dlatego, że znajdują się w starym systemie. Najpierw trzeba zastosować zasady retencji oraz wymagania prawne właściwe dla konkretnego rodzaju dokumentacji.

Czy PDF/A jest lepszy od zwykłego PDF przy archiwizacji?
PDF/A został zaprojektowany z myślą o długoterminowym przechowywaniu dokumentów, dlatego w wielu zastosowaniach archiwalnych będzie lepszym wyborem. Nie rozwiązuje jednak problemu utraty metadanych, workflow, historii wersji czy relacji między rekordami. Format pliku i kompletność migracji to dwa oddzielne zagadnienia.

Czy wystarczy zachować stary DMS tylko do odczytu?
Czasem tak. Jeżeli migracja pełnej historii byłaby bardzo kosztowna, stary system może przez określony czas działać jako archiwum tylko do odczytu. Trzeba jednak uwzględnić koszt licencji, infrastruktury, kopii zapasowych i utrzymania technologii. To rozwiązanie przejściowe staje się problemem, jeśli po kilku latach system wymaga nieobsługiwanego serwera, starej wersji bazy danych albo niedostępnych komponentów.

Jak sprawdzić, czy migracja się udała?
Nie wystarczy porównać liczby plików. Trzeba porównać liczbę rekordów i załączników, sumy kontrolne plików tam, gdzie jest to uzasadnione, metadane, wersje, powiązania oraz próbki dokumentów z różnych kategorii. Szczególną kontrolą powinny zostać objęte rekordy nietypowe i krytyczne biznesowo.

Czy można po prostu wyeksportować wszystko do PDF i zachować bazę danych starego DMS?
Technicznie jest to możliwe, ale sama kopia bazy nie gwarantuje możliwości odczytania informacji za kilka lat. Dane mogą wymagać konkretnej wersji aplikacji, schematu bazy albo dodatkowych komponentów. Jeśli baza ma pełnić funkcję archiwum, trzeba udokumentować sposób jej odtworzenia i przetestować go poza działającym środowiskiem produkcyjnym.

Pierwszą czynnością przed zmianą DMS nie powinien być eksport plików. Najpierw wybierz 20–50 reprezentatywnych dokumentów i spisz wszystko, co trzeba będzie o nich wiedzieć po wyłączeniu starego systemu: treść, metadane, wersje, podpisy, powiązania i historię akceptacji. Następnie sprawdź, które z tych informacji potrafi przyjąć system docelowy. Dopiero na tej podstawie zaprojektuj eksport. To usuwa najpoważniejszy błąd migracji: poprawne przeniesienie tysięcy PDF-ów, które po odłączeniu starego DMS przestają być pełnowartościowymi dokumentami biznesowymi.