Data audit: the phase everyone overlooks

Everyone wants to start building. An audit produces deliverables less spectacular than an application demo: a measured inventory, a risk map and a readout of the decisions to make. 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 analysing the real data in the agreed scope, recording any access limitations;
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.

The anomalies to investigate

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;
• data whose use and retention need assessment: intermediate revisions, drafts or test objects. Migration, archiving or exclusion requires a decision based on business needs and applicable obligations;
• historical exceptions: for example, records from before 2015 governed by rules that have since changed. Their date alone does not determine how they should be treated.

Documentation alone does not locate or count these anomalies. Their impact depends on the affected objects and processes: the audit prioritises them before they disrupt the migration in production.

Verify the declared volumes and sources

An initial estimate may omit history, revisions, orphaned objects or exceptions. Compare the declared volumes with extracts by data family, then distinguish what needs to be migrated, archived or excluded.

Look for additional sources: other instances, local databases and exports used as reference data. Where they contribute to the same scope, reconcile their data and agree the authoritative system. Our article on PLM migration pitfalls describes these dependencies.

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

Why does this phase get sacrificed so often?

Three factors can lead to an audit being cut. Its deliverables appear less immediate: a quantified risk map and pending business decisions draw less attention than a screen prototype 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. Finally, a working source system can be mistaken for proof of data quality. Some inconsistencies are tolerated or compensated for by current practices; after transformation, they can cause a rejection or a business error.

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. extraction of the agreed scope at real volume, recording unavailable sources and limits to the analysis;
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 locates observed difficulties, measures their reach and makes the remaining uncertainty explicit.

Scope, access, business contribution and schedule are agreed when scoping the audit. Its findings then support the migration estimate, the design of the chain and the planning of business decisions.

Auditing already reduces risk

An identified anomaly can be assigned to an owner, corrected or arbitrated, then checked before cutover. Finding it does not guarantee its resolution. The audit makes the work visible and estimable; later phases must demonstrate that the treatment is appropriate and remaining discrepancies are acceptable. That is how it helps reduce the operational risks of migration.

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

On an undocumented system, the audit goes beyond counting: value profiles provide clues to investigate alongside source code, reference data and business knowledge. Reading undocumented meaning explains how to confirm those hypotheses before defining migration rules.

What the audit feeds into, phase by phase, is set out in the ERP data migration guide and the PLM data migration guide, each with a checklist you can run against your own scope.