DMS Implementation Checklist

Most document management implementations do not fail technically. They stall because decisions that should have been made in week two get made in month five, under pressure, by whoever is available.

This checklist is sequenced to front-load those decisions.

Before you start: pick the right first scope#

One department, one or two document types, chosen where a failure is currently visible to someone senior. Policy acknowledgement if an audit is coming. Invoice processing if late payment charges are showing up. Contract management if a renewal was missed.

Starting with the process nobody is complaining about produces a well-configured system nobody uses, and there is no recovering the credibility.

Phase 1 — the four decisions#

The taxonomy#

How documents are grouped: by matter, asset, consignment, counterparty, batch or record class. Mirror how the work is actually organised rather than the org chart, because departments reorganise and the work does not.

For a first phase, bring across the existing structure. Migrating structure and system at once makes it impossible to tell which change caused a problem.

Mandatory metadata#

Three to six fields per document type. Each one needs a justification — a report, a retention rule or a routing decision that depends on it. Write the justification down, because in six months someone will ask why they have to fill in a field.

Approval thresholds#

Who approves what, and at what value or risk level a second approver is added. Encode it in the workflow rather than in a procedure.

Retention triggers#

For each record class, the period and — critically — the event that starts the clock. This is the field most often omitted and the one whose absence causes the largest errors.

Phase 2 — configuration#

With the four decisions made, configuration is straightforward and usually takes days rather than weeks. Build the document types, the metadata schema, the workflow templates and the retention rules. Set up single sign-on early, because it removes the leaver problem structurally and it is easier to do before people have accounts.

Configure the intake route that people will actually use. If documents arrive by email, that means an add-in or a watched mailbox, and it will do more for adoption than training will.

Phase 3 — prove the whole path#

On real documents, with real users, in production. Capture a document, apply metadata, route it through approval, find it again by search, and confirm the retention rule attached with the right trigger date.

The temptation is to test capture and storage, declare success, and discover the retention configuration is wrong a year later. Test the end of the lifecycle as well as the beginning.

Phase 4 — migrate selectively#

Identify what is still referenced. In most repositories that is a minority of the total, and moving only that keeps the project tractable.

Establish what version history actually exists at the source before promising to preserve it — source systems trim versions by policy, and discovering that mid-migration is a credibility problem. Reconcile document counts and sample metadata before decommissioning anything, and retain the reconciliation report as a record.

Audit and revoke sharing links on the original copies. A migrated record whose predecessor is still shared has not been brought under control.

Phase 5 — widen by document type, not by department#

Extend to the next document type in the same area before extending to a new area. The taxonomy and retention decisions transfer; the change management does not, and doing both at once means neither gets the attention it needs.

What to measure#

Not adoption percentages. Measure records with no retention class, policies past their review date, approvals older than their target, and searches that returned nothing. Those numbers tell you whether the system is working; a login count does not.

Who needs to be involved, and when#

Understaffing the decisions is the most common structural mistake. Four roles matter, and three of them are needed earlier than most plans assume.

A business owner for the area in scope, with authority to decide the taxonomy and defend the mandatory metadata when people object. Needed from week one.

Someone who understands the records obligations — a records manager, a compliance lead, or whoever answers audits today. Needed before retention rules are configured, which is earlier than it feels.

IT, for single sign-on, storage configuration and any integration. Needed early for authentication and later for everything else.

The people who will actually file documents, in the pilot. Not represented by their manager. The gap between how a process is described and how it is performed is where adoption fails, and the only way to see it is to watch someone do it.

Risks worth planning for explicitly#

Version history at the source is incomplete. Check the retained-version setting before promising to preserve history. Discovering this mid-migration damages credibility more than the gap itself does.

Metadata that was optional is mostly blank. Backfilling is manual. Scope it before deciding to make a field mandatory, or the pilot stalls on data entry.

Sharing links survive migration. Links created at the source remain live against the original copies until revoked. This is the step most often missed, and it means the record has not actually been brought under control.

Existing workflows do not transfer. Approval flows built in another system have to be rebuilt. Inventory them first — organisations are routinely surprised by how many exist and how many are already broken.

Nobody owns the taxonomy after go-live. The project team disperses and the structure decays. Name the ongoing owner during the project, not at the end of it.

A realistic first-phase timeline#

Six to ten weeks for one department and one or two document types. Roughly: two weeks on the four decisions, one week configuring, two weeks proving the path with real users, two weeks migrating and reconciling, and the remainder absorbing the things that surface once people use it.

Compressing the decision phase is the false economy. It is the only part that cannot be redone cheaply, because the taxonomy and the retention triggers are what everything else attaches to.