Every legacy contract migration starts with the same promise, that the new system will finally hold every agreement the company has signed. Six months later the program is stalled on a shared drive of unknown depth, an unknown number of duplicates, and a field list that grew every time another stakeholder was asked what they wanted.
The instinct is to blame document capture. Scanned paper, poor image quality, signature pages photographed on a phone. Capture matters, but it is rarely the thing that kills the program. Migrations fail on the metadata model, the decisions about which fields exist, what they mean, how they are validated, and how records relate to one another.
That is also why a migration is not a storage project. A repository holds files. A CLM system answers questions, and it can only answer the questions its data model supports. Design the model first, then decide what is worth moving into it.
Scope is the first data decision
Not every executed agreement needs to move. The useful test is whether a record will drive a decision in the new system. An agreement that is active, renewable, revenue bearing or subject to audit belongs in the structured repository. A terminated purchase order from nine years ago belongs in a searchable archive, not the model. Scoping down is the cheapest way to improve migration quality.
- Parties and entity, the contracting legal entity on both sides, normalized to a single identifier rather than to whatever string happened to appear on the signature block of that document.
- Dates that trigger work, effective date, expiration date, renewal notice date and auto renewal terms, because these fields generate alerts and are therefore the fields users notice when they are wrong.
- Agreement type and status, a controlled list, not free text, so reporting can separate master agreements from statements of work, amendments, order forms and terminated records without a human reading each title.
- Commercial terms in scope, contract value, currency, payment terms and any committed volume, captured only where the business will use them, since unused numeric fields decay fastest.
- Risk and compliance flags, governing law, assignment on change of control, data processing terms and audit rights, extracted as flags first and full clause text second, so reporting works before every clause is perfect.
The wish list will be longer. Someone will want negotiating history, the original sales owner and the discount rationale. Each extra field is a permanent maintenance obligation and a permanent source of blank cells. A field earns its place only when a named person can say which report or alert it feeds. If nobody can, it belongs in the document, not in the model.
AI extraction should return a confidence score per field, not just a value. Set a threshold per field, high for dates and contract value, lower for descriptive fields, and route anything below it to a reviewer. The point is not to eliminate human review, but to spend it where it changes the answer.
Relationships are harder than fields
A flat list of agreements is close to useless in an enterprise. The questions people ask involve relationships. What is the effective liability cap for this supplier across the master agreement and every amendment. Which statements of work are still running under an agreement expiring in March. None of that is answerable unless migration builds the family structure explicitly.
- Link amendments to the parent agreement. Every amendment, order form and statement of work should point to the master it operates under. Where the parent is missing, flag the orphan rather than loading the child as a standalone agreement.
- Detect superseded documents before load. Restated agreements, second executed copies and drafts saved beside the signed version look alike to a crawler. Fingerprinting on parties, dates and value catches most of them ahead of human review.
- Normalize counterparty names once. Acme Corp, Acme Corporation and ACME Corp. are one supplier. Resolve names to a master vendor identifier during migration, ideally the one procurement or finance already uses, or spend reporting stays wrong.
- Carry a pointer to the source file. Each migrated record should store where the source came from and when it was captured. Auditors ask, and so does the analyst working out why two records disagree on one expiration date.
- Model your own entity hierarchy too. Large enterprises sign through many legal entities. If migration collapses them into one company name, obligations and spend cannot be reported by entity, which is what finance and compliance ask for first.
A five step migration sequence that holds up
Step 1, Inventory And Scope
Crawl the sources, deduplicate at the file level, and classify what you find before committing to a target count. Publish the scope decision, including what is deliberately going to archive rather than into the structured repository. Programs that skip this step negotiate scope for the rest of the project.
Step 2, Freeze The Field Set
Agree the minimum viable field set with the people who will run reports on it, then freeze it for the duration. New fields can be added after cutover through a defined process. A field list that changes mid extraction invalidates records already processed and sampling already done.
Step 3, Extract With Review Thresholds
Run extraction in batches, with per field confidence thresholds and a review queue for everything below them. Track reviewer correction rate by field. If one field is corrected constantly, the problem is the model or the field definition, and both are cheaper to fix in batch two than batch twenty.
Step 4, Link, Deduplicate And Normalize
Build the agreement families, resolve superseded copies, and normalize counterparties and internal entities. This is the step most often deferred and the most expensive to retrofit, because every downstream report and obligation depends on the relationships being right. Treat linking as migration work, not cleanup.
Step 5, Validate, Then Cut Over On A Date
Pull a stratified sample across agreement types and check every field against the source document. Set the accuracy target before you sample, not after. Then name a cutover date, declare the new platform the system of record, and make old drives read only. Migrations without a cutover date never end.
Plan a migration around the data model
Review scope, field sets, confidence thresholds and family linking with a team that has run enterprise contract migrations, using a sample of your own agreements.
Human in the loop is a design choice, not a fallback
Extraction accuracy varies by field and by document quality. The design question is what happens to a low confidence value, and there are three honest answers. It loads and is wrong. It loads flagged and someone corrects it later. Or it never loads without review. Choose per field. Dates and renewal terms usually justify the review cost because they drive alerts, while a descriptive field can load flagged. Publish the rule, and store the review state on the record. A repository where nobody knows which values were verified undermines the reporting that justifies contract lifecycle management, and makes the return on the program hard to demonstrate.
What to check before you call the migration done
Validation is a sampling exercise with a stated target, not a feeling that the data looks fine. Stratify the sample by agreement type, by source system and by extraction confidence band, then check each sampled record field by field against the source. Record the error rate per field. The table below sets out what to test and what passing looks like.
| Check | Method | Passing signal | If it fails |
|---|---|---|---|
| Scope completeness | Reconcile counts against the source inventory | No unexplained gaps by type or year | Recrawl and log exclusions |
| Field accuracy | Stratified sample against source documents | Error rate within the preset target | Retune extraction or the field definition |
| Family linking | Trace amendments and statements of work to a parent | No orphan children in scope | Rerun linking, resolve missing parents |
| Duplicates | Fingerprint on parties, dates and value | One active record per agreement | Merge and mark superseded copies |
| Counterparty normalization | Compare against the vendor master | Names resolve to one identifier | Rerun normalization before reporting |
A migration is a data modeling project that happens to involve documents. Decide what moves and what is archived, freeze a field set the business will maintain, set confidence thresholds per field, and build the family structure while the records are open. Then sample, publish the error rate, and cut over on a named date to one system of record. Programs that do this finish. Programs that treat capture accuracy as the whole problem keep migrating for years.
For related guidance, see The legal ops guide to contract data migration, How to build a contract metadata model for AI search and Validating AI contract data extraction accuracy.
