Moving off email and Word: which step comes first

Historical contracts earn their keep in a small number of situations: renewal reminders, retrieval during a dispute, and audit sampling. None of those demands much data depth. Knowing that the contract exists, who the counterparty is, when it expires and where the original sits is usually sufficient. Full-text capture and clause structuring, the expensive part, will never be used for the great majority of them.

More to the point, migrating history changes nobody's working day. Tomorrow morning the business and legal are still editing Word files in a mailbox, with exactly as much friction as before. Two months of project effort with zero perceptible improvement is fatal to whatever comes next.

Connecting one live loop instead produces visible change in the first week: an inbound draft comes back with a risk list anchored to the text, versions stop being distinguished by filename, and legal's comments sit in the same place as the business's sign-off. That visible improvement is the fuel for everything after it.

A loop means a stretch of process with a defined start and end that produces something deliverable, rather than half a workflow. Three criteria: it happens often, it hurts most today, and it involves as few parties as possible.

Once chosen, write down what it excludes. Anything the first loop will not handle should be listed explicitly and communicated, or the pilot accumulates additions until it quietly becomes a full rollout.

Start migration once the live process is running steadily, typically in the second or third month. Sort documents into three tiers by how they will be used rather than processing everything identically.

The three tiers normally form a pyramid, with index at the base and structured as a small minority. Where scanned images are involved, OCR is billed per page as a value-added service, so tiering before scanning keeps budget away from paper nobody will ever retrieve.

During the pilot, two ways of working necessarily run in parallel: some contracts in the system, some still in the mailbox. The main risk in that period is not efficiency but version confusion, because the same contract can exist on both sides.

Two controls handle it. The first is to cut by scope rather than by person: one category of contract moves wholly into the system while everything else stays wholly on the old path, with no category allowed to run both ways. Cutting by person sends the same contract down different routes depending on who is handling it, which is version confusion by construction.

The second is a firm cut-off date after which that category no longer travels by email. Dual-track without a deadline extends indefinitely, because the old way is always more familiar. The date does not have to be soon, but it has to be set at kickoff and communicated to everyone involved.

Push reminders back to where people already look

When the system gets bypassed during dual-track, it is usually because nobody sees its notifications. Approval tasks, signing prompts and expiry reminders belong in the collaboration platform's message and task centre rather than only in the contract system's own inbox. This detail decides migrations more often than any feature does.

Do not judge by record counts or coverage percentages, both of which can be inflated by back-filling. Use behavioural measures instead: what share of contracts in that category were raised inside the system rather than entered after the fact, and how many places legal has to open to handle one inbound draft.

Read those alongside process outcomes: time from receipt to a decision-ready result, revision rounds, fields still re-keyed by hand, and wrong-version incidents. Baseline all of them before the project starts, measure again a month after the first loop is stable, and treat the difference as the verdict. Without a baseline, none of the later numbers has anything to be compared against.