Indlægget henvender sig til sekretærer i myndigheder, der arbejder i EZD PUW, samt til kasserere (skarbnik), distriktschefer (starosta) og borgmestre: migrering af dokumenthåndteringen er først og fremmest en organisatorisk og budgetmæssig beslutning – og først derefter en teknisk.
Hvilke frister gælder reelt
I debatten om EZD blandes tre forhold sammen, som har meget forskellig vægt.
Den planlagte pligt fra 1. januar 2028. Digitaliseringsministeriet skriver om den "i henhold til de foreslåede bestemmelser": statslige og kommunale myndigheder skal fremover arbejde med EZD-klasse-systemer. NASK angiver i præsentationen "Politikken for indførelse af EZD i Polen" af 18. marts 2026 den samme dato og tilføjer udtrykkeligt, at der er tale om pligten til EZD, "ikke EZD RP". Det er en bebudelse, ikke en vedtaget bestemmelse. Datoen bør man lægge til grund i planlægningen og løbende tjekke, om den er ændret.
Ændringen af arkivloven. Ministerrådet vedtog lovforslaget den 28. juli 2026, det blev fremsat for Sejmen den 30. juli (tryksag nr. 3000), og den 15. september fremlagde udvalgene deres betænkning. Forslaget giver scannede papirdokumenter samme retsvirkning som originalerne, fastsætter krav til systemerne og rydder op i reglerne for kassation af dokumentation. Det skal træde i kraft 12 måneder efter offentliggørelsen. Det indeholder ikke datoen 1. januar 2028 og indfører ikke i sig selv en pligt til at indføre et system.
Tidsplanen for EZD PUW. Ifølge samme NASK-præsentation: støtte til migrering fra EZD PUW til EZD RP fra 1. kvartal 2028, stop for videreudvikling af EZD PUW i 2. kvartal 2029, afslutning af migreringsstøtten den 31. december 2030, ophør af servicesupport til EZD PUW den 31. marts 2031. Det er en tidsplan fra en præsentation, ikke fra en retsakt, og den kan derfor ændre sig.
Konklusionen for en myndighed, der allerede arbejder i EZD PUW: presset udspringer ikke af selve datoen 2028, men af at det nuværende system holder op med at blive videreudviklet og senere serviceret. Der er tid til at forberede sig grundigt, men ikke så meget, at man kan udskyde kortlægningen.
Hvilke beslutninger ligger hos myndigheden
- Valg af system. EZD RP stilles gratis til rådighed af NASK, enten i skyen eller på myndighedens egen infrastruktur. Den planlagte pligt gælder dog systemklassen, så myndigheden kan også vælge en anden løsning, der opfylder kravene. Det er værdifuldt at sammenligne mindst to varianter og beregne den samlede omkostning (TCO), ikke blot licensprisen.
- Migreringens omfang. Om man overfører alle sager, kun verserende sager, eller starter det nye år med et rent system, mens det gamle forbliver til opslag.
- Integrationer med fagsystemer. Økonomi og bogholderi, skatter, registre, e-Doręczenia (polsk e-Delivery), KSeF (det polske nationale e-fakturasystem), BIP. Enhver forbindelse, der i dag fungerer med EZD PUW, skal enten genskabes, erstattes eller bevidst opgives.
- Arkivdata. Hvad der sker med afsluttede sager, hvordan de stilles til rådighed, samt hvornår og i hvilken form de overføres til virksomhedsarkivet og det statslige arkiv. Det er en beslutning, hvor arkivaren skal have en stemme.
- Driftsmodel. NASK's sky, en anden skyudbyder eller eget serverrum. Det afgør, hvem der har ansvaret for backup, opdateringer og driftskontinuitet.
Et "gratis system" betyder ikke en gratis migrering. Budgettet skal tage højde for integrationer med fagsystemer, overførsel af data, uddannelse, medarbejdertid samt en periode, hvor to systemer kører parallelt. Disse poster bør fremlægges for byrådet hver for sig, med en beskrivelse af, hvad der sker, hvis myndigheden ikke finansierer dem.
Hvad der bør kortlægges, før beslutningen træffes
Denne kortlægning kan myndigheden lave selv. Den kræver tid og adgang til de rette medarbejdere, ikke programmeringsviden.
- Version og driftsmåde for EZD PUW: hvor det er installeret, hvem der administrerer det, og hvilke tilføjelser og tilpasninger det har.
- Omfang: antal brugere, verserende og afsluttede sager, mængden af gemte filer.
- Integrationer: hvad EZD PUW udveksler data med, hvem der har etableret forbindelsen, og om der findes dokumentation og en kontrakt for den.
- Den faktiske sagsgang: hvordan breve og fakturaer reelt bevæger sig gennem afdelingerne, herunder steder hvor papir stadig cirkulerer sideløbende med systemet.
- Kancellidokumenter: kancelliinstruksen, den ensartede sagsfortegnelse og undtagelser fra den elektroniske sagsbehandling.
- Kontrakter og licenser: frister, opsigelsesvarsler, rettigheder til data og muligheden for at eksportere dem.
- Mennesker: hvem der bliver koordinator, hvem der kender det nuværende system, og hvor meget tid afdelingerne reelt kan afsætte til uddannelse.
Hvordan en sådan kortlægning adskiller sig fra en almindelig liste over applikationer, har jeg beskrevet i indlægget Kortlægning kontra en liste over applikationer.
Typiske fejl
Dette er situationer, der går igen i lignende projekter, og ikke en beskrivelse af en konkret myndighed.
- At overføre den gamle sagsgang én til én. Migreringen er en anledning til at forenkle godkendelsesforløbene. Hvis man genskaber dem uændret, overfører man blot de gamle problemer til det nye system.
- Integrationer, der ikke er med i kontrakten. Forbindelser til fagsystemer dukker op efter kontraktens underskrift og kommer tilbage som tillægsaftaler.
- Manglende beslutning om arkivdata. Uden den skal det gamle system vedligeholdes på ubestemt tid, fordi ingen ved, om det kan lukkes ned.
- Et rent it-projekt. Arbejdsgangen ændrer sig i hver eneste afdeling, og de får først kendskab til tidsfristerne på et kursus.
- En beslutning truffet under tidspres. En myndighed, der går i gang få måneder før supportens ophør, sammenligner ikke varianter, men tager det, der er tilgængeligt.
At migrere et dokumenthåndteringssystem ligner, at en myndighed flytter til en anden bygning. Man kan flytte alt med, inklusive skabe, som ingen har åbnet i årevis. Man kan også først lave en fortegnelse, beslutte hvad der skal med, og hvad der skal på arkiv, og først derefter bestille flyttevognen.
Om forberedelse af organisationen til implementeringen skriver jeg mere udførligt i indlægget Forberedelse til implementering af et system.
Spørgsmål til leverandørerne
Det er værd at stille dem til enhver, der tilbyder et system, en migrering eller implementeringsstøtte – også ved EZD RP.
- Hvilke data fra EZD PUW bliver overført, i hvilken form, og hvad bliver udeladt?
- Hvordan kontrollerer vi, at der ikke mangler noget efter migreringen? Hvem underskriver protokollen for denne kontrol?
- Hvilke integrationer med vores fagsystemer er inkluderet i prisen, og hvilke kræver et separat tilbud?
- Hvor længe skal vi arbejde i to systemer samtidig, og hvem har ansvaret for hvilket i den periode?
- I hvilket format og på hvilke vilkår får vi vores data udleveret, hvis samarbejdet ophører?
- Hvem har ansvaret for backup, opdateringer og tilpasning til lovændringer?
- Hvor mange arbejdstimer fra vores medarbejdere forudsætter tidsplanen, fordelt på afdelinger?
- Hvor kan vi se en implementering i en enhed af tilsvarende størrelse?
Kilder
Retsstilling pr. 4. oktober 2026.
- Digitaliseringsministeriet: EZD RP – den papirløse æra i den offentlige forvaltning nærmer sig (14.07.2025)
- NASK: Politik for indførelse af EZD i Polen. Strategi og udvikling af EZD RP, præsentation fra 18.03.2026
- NASK: Udkast til "Politik for indførelse af EZD i Polen" – fremtiden for EZD PUW og EZD RP, tidligere præsentation
- Ministeriet for Kultur og National Arv: Ministerrådet vedtog lovforslaget om ændring af loven om den nationale arkivbeholdning og arkiver (28.07.2026)
- Ministerrådets liste over lovgivningsarbejde: lovforslag UD113
- Sejmen: forløbet af arbejdet med tryksag nr. 3000
- EZD RP: implementeringsstøtte (gov.pl)
- EZD RP: SaaS-tjenesten EZD RP (gov.pl)
- EZD RP: Forudsætninger og udfordringer ved arkivering i systemer af EZD-klassen (28.07.2026)