Most migration plans treat data as a workstream that ends at cutover. Extract, map, transform, load, tick.

What actually happens is that the load succeeds, the project celebrates, and six weeks later someone in finance notices that supplier bank details are missing on 400 records, or that open purchase orders came across with the wrong tax classification. The migration was declared complete before anyone had proven it was correct.

A load reports how many records the system accepted. It says nothing about whether those records mean what they meant in the source. Those are different questions, and only one of them is usually answered.

Mapping is usually documented in a spreadsheet, agreed in a workshop and then diverges from reality over the following six months.

The problem is not the spreadsheet. It is that the mapping is a living artefact treated as a one-time deliverable. Rules change during conversion cycles. Someone adjusts a transformation in the load script to fix a rejection and does not update the document. By the fourth cycle, the map and the code disagree, and nobody knows which one is authoritative.

Mapping has to be executable. If the rules that govern the transformation are the same rules that govern the validation, they cannot drift apart.

Every transformation is a place where data can silently change meaning.

Concatenating segments, defaulting missing values, converting date formats, applying currency rates, splitting a legacy field into two Fusion attributes. Each is individually reasonable. Collectively they are where the discrepancies come from, because a defaulted value looks identical to a real one once it is loaded.

The rule that matters: any transformation that invents data has to be recorded as such. When a validation run later shows a mismatch, the team needs to know immediately whether the target value came from the source or from a default rule applied at 2am during a conversion cycle.

Validation asks whether individual records are correct. Reconciliation asks whether the totals agree, and it is the check the business actually cares about.

Trial balance in EBS against trial balance in Fusion. Open AR by customer, both sides. Open AP by supplier. Inventory quantity and value by organisation. Open purchase order commitment. Fixed asset cost and accumulated depreciation.

When these do not tie, the difference is the finding. A three-record variance in open AR is not a rounding issue to be waved through. It is either a missing transaction, a transformation error or a scoping decision nobody wrote down. Each of those needs a different fix, and the only way to tell them apart is to trace the specific records.

Reconciliation reports should be produced automatically at the end of every conversion cycle, in a format the finance team can read without a technical translator. If the business cannot verify the numbers themselves, they will not sign off with any confidence, and sign-off without confidence is how projects go live with known problems.

Every conversion cycle produces exceptions. The measure of a migration process is not whether they occur but how fast they are understood.

A failure log listing 12,000 rejected rows with a generic error message is not useful. What the team needs is grouping by cause, the specific source record for each failure, the transformation rule that was applied, and an owner. Most large exception sets collapse to a small number of root causes once they are grouped properly. Twelve thousand rejections is often four problems.

Exception counts should also fall across cycles. If mock 1 produced 12,000 and mock 3 produces 11,400, the process is not converging and the go-live date is optimistic. That trend line is one of the more honest indicators of migration readiness available.

Somebody will ask what happened. It might be an internal auditor, an external auditor during the first year-end on Fusion, or a finance director in month three trying to explain a variance.

The answer needs to exist without a two-week reconstruction exercise. That means retaining, per run: what was extracted and when, which rules were applied, how many records were processed and rejected, the validation results, the reconciliation position and who approved it.

Teams that treat this as a compliance chore build it at the end and it is painful. Teams that treat it as a by-product of the process get it for free, because the system that runs the validation is the system that keeps the record.

The last conversion cycle before cutover should be a rehearsal, not a first attempt.

Full volume, production-like data, the complete validation suite, the complete reconciliation pack, and a timed run so the cutover window is based on measurement rather than estimate. Then a documented decision: the data is ready, or these specific items are open and here is who accepted the risk.

That distinction matters more than it sounds. Every migration goes live with some known issues. The difference between a controlled go-live and a bad one is whether those issues were listed and accepted, or discovered afterwards.

The single biggest efficiency gain in a migration programme is making the conversion cycle repeatable. Most projects run four to six cycles. If each one requires manual preparation, the team spends its time rebuilding the process instead of improving the data.

A repeatable framework means the same validation rules execute against every cycle, the reconciliation pack generates automatically, exception reports arrive grouped and owned, and cycle-over-cycle trends are visible. The first cycle costs more to set up. Every subsequent one costs a fraction, and the fourth one takes hours rather than days.

That is also what makes the framework reusable beyond the project. The same validation logic works for the next entity rollout, the next acquisition and the next environment refresh.

Oracle removed the deadline. What is left is the harder standard: proving the migration was worth doing.