From EZD PUW to an EZD-class system: what the secretary should establish before the authority chooses its path

This post is for secretaries of authorities working in EZD PUW, as well as for treasurers (skarbnik), district heads (starosta) and heads of municipalities (wójt): migrating a document-management system is an organisational and budgetary decision first, and only then a technical one.

Which deadlines actually apply

Discussions about EZD tend to conflate three matters of very different weight.

The planned obligation from 1 January 2028. The Ministry of Digital Affairs describes it as being introduced "in line with the draft regulations": government and local-government units are to operate on the basis of electronic document-management systems (EZD). NASK's presentation "EZD Implementation Policy in Poland" of 18 March 2026 gives the same date and states explicitly that this concerns the EZD obligation, "not EZD RP". This is an announcement, not an enacted regulation. The date is worth building into planning, while checking that it has not changed.

Amendment to the Archives Act. The Council of Ministers adopted the draft on 28 July 2026, it was submitted to the Sejm on 30 July (parliamentary paper no. 3000), and on 15 September the committees presented their report. The draft gives scans of paper documents the same legal standing as originals, sets requirements for systems, and puts the disposal of records on a clearer footing. It is to enter into force 12 months after publication. It does not contain the 1 January 2028 date and does not itself introduce an obligation to implement a system.

The EZD PUW schedule. According to the same NASK presentation: migration support from EZD PUW to EZD RP from Q1 2028, development of EZD PUW halted in Q2 2029, migration support ending on 31 December 2030, and EZD PUW service support ending on 31 March 2031. This schedule comes from a presentation, not from a legal act, so it may change.

The conclusion for an authority already working in EZD PUW: the pressure does not come from the 2028 date itself, but from the fact that the current system will stop being developed, and later serviced. There is time to prepare properly, but not enough to keep postponing the inventory.

Which decisions belong to the authority

Choice of system. EZD RP is made available by NASK free of charge, either in the cloud or on the authority's own infrastructure. The planned obligation, however, concerns the class of system, so the authority may also choose another solution that meets the requirements. It is worth comparing at least two options, calculating total cost of ownership (TCO) rather than just licence price.
Scope of migration. Whether you transfer all cases, only ongoing ones, or start the new year with a clean system while the old one remains available for reference.
Integrations with domain-specific systems. Finance and accounting, tax, registers, e-Doręczenia (e-Delivery), KSeF (e-invoicing), and BIP (public information bulletin). Every connection that currently works with EZD PUW will need to be rebuilt, replaced, or deliberately abandoned.
Archival data. What happens to closed cases, how they will be made available, and when and in what form they will reach the departmental and state archives. This is a decision in which the archivist must have a say.
Maintenance model. NASK's cloud, another cloud provider, or the authority's own server room. This determines who is responsible for backups, updates, and operational continuity.

For financial oversight

A "free system" does not mean a free migration. The budget needs to provide for integrations with domain-specific systems, data transfer, training, staff time, and the period during which two systems run in parallel. It is worth presenting these items to the council (rada) separately, describing what happens if the authority does not fund them.

What to document before the decision is made

The authority can compile this inventory itself. It requires time and access to people, not programming knowledge.

Version and configuration of EZD PUW: where it is installed, who administers it, what add-ons and customisations it has.
Scale: number of users, ongoing and closed cases, and the volume of stored files.
Integrations: what EZD PUW exchanges data with, who built the connection, and whether documentation and a contract exist for it.
Actual workflow: how correspondence and invoices really move through departments, including places where paper still circulates alongside the system.
Records-management documents: the office instruction (instrukcja kancelaryjna), the uniform subject-based file list (jednolity rzeczowy wykaz akt), and exceptions from conducting cases electronically.
Contracts and licences: deadlines, notice periods, and rights to the data and its export.
People: who will be the coordinator, who knows the current system, and how much time departments can realistically give to training.

I describe how such an inventory differs from a simple list of applications in the post Inventory versus a list of applications.

Common mistakes

These are situations that recur across similar projects, not a description of any specific authority.

Replicating the old workflow one-to-one. Migration is an opportunity to simplify approval paths. Recreating them unchanged simply carries old problems into the new system.
Integrations left out of the contract. Connections with domain-specific systems come to light after the contract is signed and return as annexes.
No decision on archival data. Without one, the old system must be kept running indefinitely, because nobody knows whether it can be switched off.
Treating it as a purely IT project. The way every department works changes, yet departments only learn the deadlines at the training session.
Deciding under deadline pressure. An authority that starts a few months before support ends does not compare options; it simply takes whatever is available.

Analogy for the board

Migrating a document-management system is like moving an authority's offices to a different building. You can transport everything, including cabinets nobody has opened in years. Or you can first draw up an inventory, decide what goes, what goes to the archive, and only then book the removal.

I write more about preparing an organisation for implementation in the post Preparing for a system implementation.

Questions for vendors

It is worth asking these of anyone offering a system, migration, or implementation support, including for EZD RP.

Which data from EZD PUW will be transferred, in what form, and what will be left out?
How will we verify that nothing is missing after migration? Who signs off on that verification report?
Which integrations with our domain-specific systems are included in the price, and which require a separate quote?
How long will the parallel-running period last, and who is responsible for which system during that time?
In what format, and on what terms, will we recover our data if we end the cooperation?
Who is responsible for backups, updates, and adapting the system to regulatory changes?
How many hours of our staff's time does the schedule assume, broken down by department?
Where can we see an implementation at a unit of similar size?

Sources

Legal status as at 4 October 2026.