Data audit: the phase everyone overlooks

Everyone wants to start building. The audit, by contrast, is anything but spectacular: no demo, no visible deliverable, just the patient inventory of what actually exists. Yet it is the phase that determines everything else.

What an audit should really produce

A good audit does more than list tables. It answers one simple question: what is genuinely migratable, and at what risk?

In practice, that means:

1. extracting and analyzing the real data, not a convenient sample;
2. measuring actual volumes, not the figures that were announced;
3. identifying inconsistencies, duplicates and edge cases;
4. understanding the functional dependencies between objects.

The deliverable is not a compliance report. It is a quantified map of the risk: what goes through as-is, what needs a transformation rule, what requires a business decision, and in what proportions.

What the audit almost always reveals

From one project to the next, the systems change; the findings look strikingly alike:

• structural duplicates: the same part created three times under three codifications, each with its own history;
• orphaned objects: bills of materials pointing to deleted parts, documents attached to nothing;
• diverging reference data: the unit of measure missing here, coded differently there, and a spreadsheet somewhere acting as the real source of truth;
• dead data inflating the scope: intermediate revisions, drafts never promoted, test objects created in production;
• historical exceptions: records from before 2015 that follow none of the current rules, because the rules have changed three times since.

None of these anomalies is visible in the documentation. All of them are critical at load time. This is exactly what makes migrations fail in production.

Volume estimates almost always lie

A volume estimate provided at the start of a project is, in the vast majority of cases, underestimated. History, intermediate revisions, orphaned objects and accumulated exceptions inflate the real scope far beyond what was anticipated.

And the scope almost never fits inside a single system: multiple instances, side databases, exports that quietly became the real reference. A real PLM migration reconciles several sources; it doesn’t copy just one.

Measuring early means avoiding a nasty surprise at the worst possible moment.

Why does this phase get sacrificed so often?

Three reasons come up every time. The audit has no demonstrable deliverable: weeks of work to produce numbers, when a screen prototype makes a better impression at the steering committee. The schedule is already under pressure: the audit looks compressible because its consequences are invisible at the moment you cut it. And above all, everyone assumes the data is fine: the source system works, so its data must be healthy. It isn’t: a system in production tolerates years of inconsistencies perfectly well; the target model will refuse them.

Saving on the audit doesn’t remove the work. It moves it to the end of the project, when every correction costs the most.

How a MigQuest audit runs

The audit is the first phase of our methodology, and it always follows the same discipline:

1. complete extraction of the source data: not a sample, all of it;
2. systematic profiling: fill rates, formats, out-of-reference values, distributions;
3. volume measurement per object type, history and revisions included;
4. dependency mapping: which objects must migrate together, and in what order;
5. quantified restitution: real scope, anomalies by family, prioritized risks.

The audit doesn’t say whether the migration will be easy. It says exactly where it will be hard.

A few weeks are usually enough. A fraction of the project, for visibility that conditions everything else: the schedule estimate, the sizing of the chain, and the business decisions to prepare.

Auditing already reduces risk

Every anomaly spotted during the audit is an anomaly that will not derail production. The audit doesn’t solve the problems, but it makes them visible early enough to be dealt with, and quantified. That is the difference between budgeting a correction and paying the bill for a fiasco.

That is exactly the spirit of the approach: work from real data, not assumptions. The rest of the migration depends on it.