Migrating a paper-based process without breaking it

Most e-signature rollouts that fail do not fail on technology. They fail because a team switched everything at once, hit one edge case nobody had considered, and reverted to paper with the conclusion that "it did not work for us".

A staged migration takes longer on paper and finishes sooner in practice.

Stage one: inventory

List every document your team currently gets signed. For each one, record volume, the parties, whether notarisation or witnessing is involved, retention requirements, and where the signed copy currently ends up.

This is dull and it is the step that determines whether the rest goes well. Teams that skip it discover halfway through that one document requires a wet signature under a regulation nobody had read.

Stage two: sort by risk

• Green — routine internal documents, low value, no special requirements. Start here.
• Amber — customer-facing agreements with ordinary commercial risk.
• Red — anything regulated, notarised, witnessed, or above a material value threshold.
• Excluded — documents where law requires wet ink. Confirm rather than assume.

Migrate green first. It builds familiarity where mistakes are cheap, and it gives you internal advocates before you touch anything customer-facing.

Stage three: confirm the legal position

For each amber and red document, confirm three things: that electronic signature is permitted for this document type in the relevant jurisdictions, what level of signature is required, and what your retention obligation is.

Stage four: rebuild rather than replicate

The temptation is to reproduce the paper process exactly. Resist it. Paper processes contain steps that exist purely because of paper — printing, scanning, physical routing, a filing cabinet, someone walking a folder between desks.

The approval chain in particular is worth revisiting. Chains often grew because a physical folder passed a desk and it seemed sensible to have that person initial it. That reasoning does not survive the transition.

Stage five: run parallel briefly

For two to four weeks, run both. Not for every document — pick a representative sample. The purpose is to catch process gaps, not to validate the technology.

Keep parallel running short and time-boxed. Indefinite parallel running is how organisations end up with two half-maintained processes forever.

Stage six: train for the exceptions

Sending a document is self-explanatory. What people need training on is the unusual cases:

1. 1A signer says they cannot open it — what do you actually do?
2. 2A signer wants a change — void and resend, or return for changes?
3. 3The wrong person was sent it — how do you correct without voiding?
4. 4A counterparty insists on wet ink — what is the approved fallback?
5. 5Someone needs a copy three years later — where does it live?

Write those down as a one-page reference. Every one of them will happen in the first month.

Handling the counterparty who refuses

Some counterparties will insist on wet ink. Occasionally there is a genuine legal basis; more often it is policy or unfamiliarity. Either way, you need an approved fallback that does not involve the person in front of the customer improvising.

Decide in advance who can authorise a paper exception, how the resulting document gets back into the electronic record, and who scans it. Without that, exceptions accumulate in individual inboxes and your archive silently becomes incomplete.

Deal with signature authority while you are here

Migration is the ideal moment to review who is actually authorised to bind the organisation, because you are about to encode it. Most organisations discover the practical answer has drifted from the documented one.

Map authority levels to document types and values, then reflect that in template permissions. It is considerably easier to enforce a signing authority matrix in software than it ever was on paper, and this is the only point in the project where doing so is nearly free.

Stage seven: decommission properly

Once a document type is fully migrated, remove the paper path. Take the blank forms out of the cupboard. A team with an easy paper option will use it under time pressure, and you will end up with records split across two systems — the worst outcome of all.

Deal with the existing paper archive as a separate project. Scanning historical records is worth doing, but conflating it with process migration is how migrations stall for eighteen months.

A realistic timeline

For a mid-sized team with a dozen document types, a comfortable pace looks roughly like this.

1. 1Weeks 1–2: inventory and risk sorting
2. 2Weeks 3–4: legal confirmation on amber and red documents
3. 3Weeks 5–6: build and test green templates, train the team
4. 4Weeks 7–10: parallel running on a sample, fix what surfaces
5. 5Weeks 11–14: migrate amber documents in batches
6. 6Week 15 onward: red documents individually, each with sign-off

Roughly four months. Teams that try to compress this to three weeks usually spend the saved time later, dealing with an exception nobody planned for while the process is already live.