AI-Assisted Migration of Legacy Project Data, and What It Will Not Do for You

The previous article argued that you can start a PMIS without moving your history. This one deals with the history — because some of it does need to come forward, and the cost of bringing it has changed.

It has changed less than the marketing around AI suggests, and more than most people implementing systems assume. Both halves of that matter.

Most migration projects go wrong because they are scoped as one activity. They are three, with different costs and different failure modes.

Three problems that get called migration

Most migration projects go wrong because they are scoped as one activity. They are three, with different costs and different failure modes.

Moving structured records from one database to another. Mapping one organisation's coding structures onto another's. And extracting governed records from decades of unstructured documents.

Conflating them produces a single estimate that is wrong in both directions — too high for the first, far too low for the third — and a plan in which the hardest work is discovered late.

The first is engineering, and it is not where the cost sits

Moving structured records between relational databases is well-understood work with mature tooling. Staged loading, referential validation, reconciliation against source totals, iterative correction. It is not trivial and it is entirely predictable. same reason that mattered in the earlier article on client-built analysis. You can load in stages, validate relationships before committing, reconcile against control totals, and correct in place. The tooling is standard and the people who know how to use it are not scarce.

Compare that with a target reachable only through an API. The load becomes a sequence of calls, subject to rate limits and to whatever the interface exposes, with error handling and restart logic built around the constraint.

Same data, same destination, materially different exercise. Not impossible — genuinely more expensive, and slower to correct when something is wrong.

The second is where AI helps most, and it is not what people expect

The expensive problem in most migrations is not moving records. It is deciding what the old codes mean in the new structure.

A legacy WBS built for one delivery model has to map onto a new one. A cost code structure with eleven years of accumulated exceptions has to be expressed in the target's coding. A vendor master with duplicates, historic names, merged entities and three spellings of the same company has to be reconciled. This work has traditionally been done by two or three experienced people over months, and it is genuinely difficult because it requires knowing both what the old codes meant in practice and what the new structure is for.

AI is unexpectedly good at proposing these mappings — reading both structures, examining how codes were actually used rather than how they were defined, and proposing correspondences with the reasoning shown so a person can accept or reject each one.

The work does not disappear. It changes from authoring to reviewing, and that is roughly an order of magnitude. Two people producing a mapping over four months becomes two people reviewing a proposed mapping over three weeks, with better coverage because the proposal examined every code rather than the ones anybody remembered.

The mapping work changes from authoring to reviewing. That is the largest single saving available in a migration, and it is the least discussed.

The third is where AI helps most visibly

Extracting governed records from legacy correspondence, contracts and submittals is the capability described earlier in this series, applied backwards in time. The same properties matter: entity matching so the extracted content attaches to the right record, and source traceability so it can be verified by exception rather than in full.

And the same scoping discipline applies. Classify everything, extract from the fraction that warrants it. An archive project scoped as extraction of the whole estate does not finish.

What it will not do

Three things, stated without hedging, because the honest version of this argument is more persuasive than the complete one.

It will not decide what is worth migrating. This is the decision where most migration budgets are actually lost, it requires commercial and legal judgement about which historic positions still carry consequence, and no tool will make it for you. Organisations that skip this decision default to everything, which is how a migration becomes a programme. verification step is real work performed by people who understand the material, and a migration plan without a resourced verification stage has moved the risk rather than removed it.

This is the principle PMWEB's Intelligence Control Framework states for the platform, AI advises and the operator decides, and it applies to migration with particular force, because a mapping accepted in month two governs every record loaded after it. Keep a record of what the AI proposed, who accepted or rejected each proposal, and on what basis. Whoever later has to explain why a historic cost landed in the code it did will read it.

And it will not reconstruct a record that was never properly kept. No extraction recovers an approval given verbally in a site meeting in 2019. No mapping reconstructs the intent behind a cost code that three people used three different ways. If the history is incomplete, migration produces a faithful copy of an incomplete history, and the gaps are the same gaps.

Migrate by exception

The recommendation this all leads to is simple to state and difficult to hold to.

Move the open commitments, the live obligations, the disputed history, and anything that will be needed as evidence in a matter that is still running. That is a small fraction of most archives and it is the fraction that has consequence.

Classify and index the rest in place, so it is findable when somebody needs it, which will be rarely and unpredictably. Findable is a different requirement from migrated, it costs a fraction as much, and for closed projects it is almost always sufficient.

Archive what remains against your retention obligations and stop paying attention to it.

Organisations that migrate by exception finish, usually within a period a sponsor will tolerate. Organisations that attempt completeness produce a very good plan, a series of extensions, and eventually a decision to stop that gets framed as a change of priorities.

Where this series ends

Sixteen articles ago this began with a claim: that the quality of any AI answer in capital delivery is set by the data underneath it, and that a PMIS and a document repository are not the same substrate.

Everything since has been a consequence of that. The capabilities arriving in PMWEB 2026 are aimed at getting more of the record into the system. The analysis worth wanting has to name the data it read. The monitoring worth having connects an event to records that were structured enough to be connected. The client-built layer exists because structured data can be queried by the organisation that owns it. And migration is tractable because the target is a documented relational structure rather than a black box.

And the governance argued for at the start of the series (permissions inherited rather than duplicated, an audit trail that names a person, a gate that does not move) is now something PMWEB has written down as a published framework under a five-word principle: AI advises, the operator decides.

The organisations that will get the most from AI in project delivery are not the ones with the longest vendor roadmap. They are the ones whose project record is complete enough, structured enough and accessible enough to be worth reading.

That was true before any of this and it will be true after. AI has simply raised the return on having done it properly.

The organisations that will get the most from AI in project delivery are the ones whose project record is complete enough, structured enough and accessible enough to be worth reading. AI

has simply raised the return on having done it properly.

Thank you for reading this series. I am glad to discuss any of it — particularly the questions in articles four and twelve, which are the ones worth taking into your next vendor conversation whichever platform you are running.