Every contract lifecycle management program has a moment where the schedule quietly moves. Configuration is done, workflows are tested, the pilot group is trained, and then someone asks what happens to the twenty-three years of executed agreements sitting in a shared drive, three email archives and a decommissioned repository that only one person still has credentials for.
Legacy contract migration is the part of the program with the least glamour and the most schedule risk. It is also the part most often handed to a partner with a scope line that reads extract key metadata, which is not a specification. The result is a re-extraction cycle, an argument about accuracy, and a repository the business does not trust enough to use for reporting.
The failure is almost never the extraction technology. Modern document AI handles the mechanical work well. The failure is that nobody decided, in advance, which agreements matter, which fields matter for each of them, and what accuracy means in a way that can be tested. This checklist covers those decisions.
Four decisions to make before extraction starts
Each of these is cheap to settle in a workshop and expensive to settle after 40,000 documents have been processed. Treat them as gate criteria for starting the migration work stream.
- Scope tiers, the rule that separates agreements needing full clause-level extraction from those needing header metadata only, and those that should be archived without extraction at all.
- Minimum field set per tier, the specific fields each tier must carry, derived from the reports and alerts you have committed to producing rather than from the extraction tool default.
- Accuracy threshold and sampling method, the acceptance rate required per field, the sample size, and who adjudicates a disputed value, agreed before the first batch is delivered.
- Source of truth rule, which system holds the authoritative value when the executed PDF, the old repository and the finance system disagree, because they will disagree.
- Migration evidence, the record retained showing what was migrated, when, from which source, and what was deliberately excluded, which is what an auditor will ask for.
A useful discipline is to write the three reports the business most wants from the new repository, then work backwards to the fields required to produce them. Most teams discover their real minimum field set is between twelve and twenty attributes, well below what a full extraction schema offers and far above what a filename convention can carry.
Full clause-level extraction across an entire archive is rarely justified. Active agreements with live obligations, renewals or regulatory exposure warrant depth. Expired agreements retained only for record-keeping usually warrant header metadata and a searchable file, nothing more.
Where migrations go wrong
The patterns repeat across implementations, and each one is visible early if somebody is looking for it.
- Extracting everything at one depth. Applying clause-level extraction uniformly inflates cost and timeline while producing detail on expired paper that nobody will read. Tiering is the single largest lever on migration effort.
- No accuracy definition. Without a stated threshold and a sampling method, accuracy becomes an argument between the business and the partner at exactly the point where there is no schedule left to fix it.
- Ignoring amendments and order forms. The operative terms often live in an amendment, an order form or a statement of work rather than the master agreement. A migration that captures only the master will misstate value, term and renewal dates.
- Deferring the duplicate question. Archives contain drafts, scans of the same executed document and near-identical copies across systems. Decide the deduplication rule up front or the repository inherits the mess it was meant to fix.
- Migrating dead paper first. Chronological migration processes the oldest and least useful agreements first. Sequence by business value instead, starting with agreements carrying live obligations and near-term renewal dates.
A five-step readiness sequence
Step 1, Inventory sources, not documents
Count the repositories, drives, mailboxes and third-party systems that hold executed paper, and name an owner for each. Volume estimates made without this step are consistently low, and the sources discovered late are the ones that push a cutover date.
Step 2, Tier the portfolio against business value
Classify agreements into full extraction, header extraction and archive-only using objective rules such as active status, contract type, annual value and regulatory category. Publish the rules so the tiering can be audited later.
Step 3, Fix the minimum field set
Derive fields from committed reports and alerts. If a field does not appear in a report, an obligation trigger or a search filter that someone has asked for, it does not belong in the mandatory set.
Step 4, Run a calibration batch and set acceptance
Process a representative sample of several hundred agreements across tiers, measure per-field accuracy, and use the result to set the acceptance threshold and the human review rate for the full run.
Step 5, Migrate by business priority and keep evidence
Sequence active and obligation-bearing agreements first, then the rest. Retain a migration log showing source, date, tier and exclusions. Post-signature commitments should be validated on arrival, which is where obligation management picks up the record.
Plan a migration against a working repository
Aavenir Contractflow combines AI extraction with tiering rules and human review queues, so accuracy is measured per field rather than asserted at the end.
How much human review is realistic
Extraction models handle structured header data well and handle clause interpretation less well, so the review rate should differ by field rather than being set once for the whole run. Effective dates, parties and contract values in clean digital PDFs are usually accepted with light sampling. Renewal mechanics, liability caps, assignment restrictions and anything expressed as a cross-reference to another document need higher review because an error there propagates into an obligation or an alert that someone will act on. Scanned paper from before the mid-2000s deserves its own accuracy assumption entirely. The economically sensible position is a variable review rate driven by field risk and source quality, with the rate recalibrated after the first full batch rather than fixed in the statement of work. For how the extracted output should behave once loaded, see contract repository versus CLM.
Scope tiers and what each one carries
The table below is a starting template. Adjust the thresholds to your portfolio, but keep the principle that extraction depth follows business consequence rather than document age.
| Tier | Typical population | Extraction depth | Review rate |
|---|---|---|---|
| Tier 1, active and material | Live agreements above a value or risk threshold | Full clause and obligation extraction | High, with adjudication on disputed fields |
| Tier 2, active and routine | Live low-value or standard-form agreements | Header metadata plus renewal and term fields | Sampled against a stated threshold |
| Tier 3, expired but retained | Closed agreements inside the retention window | Header metadata and full-text search | Spot check only |
| Tier 4, archive | Superseded drafts and duplicates | File and index, no field extraction | None |
| Exception queue | Illegible scans and missing amendments | Manual handling with a named owner | Full manual |
Legacy migration is a data governance exercise wearing an implementation costume. The organizations that finish on schedule are the ones that decided scope, fields, accuracy and evidence before the first batch ran, and that sequenced the work so the agreements carrying live commitments landed first. Everything else is throughput, and throughput is the one part of the problem that vendors and partners are genuinely good at solving. Decisions are yours; volume is theirs. If the migration is part of a broader platform selection, the questions worth asking a vendor are in the CLM software evaluation checklist.
For related guidance, see The legal ops guide to contract data migration, Validating AI contract data extraction accuracy and ASC 842 and IFRS 16, the lease data auditors test.
