Data Migration Silent Killers: FndMig & DMM Notes

FndMig and DMM validate what they can define a rule for: mandatory fields populated, foreign keys resolving to a record that exists at the moment the load runs, values within a domain the target field accepts. Mandatory-field and foreign-key checks catch errors that are structurally invalid outright, at load time, with a log line pointing at the offending row. What it structurally cannot catch is anything that is syntactically and referentially valid but semantically wrong: a quantity that is a legal number, just computed from the wrong conversion factor; a foreign key that resolves correctly today because the parent happened to load in an earlier batch, even though the two were never meant to be linked; a value hand-patched into a staging spreadsheet under time pressure and never checked against the rule it was meant to satisfy.

None of that trips a validation rule, because none of it is invalid data. It is valid data that means the wrong thing, and the tooling has no way to know what the right thing was supposed to be without someone writing and maintaining that rule deliberately, on top of the standard load, not instead of it.

Unit-of-measure conversion mismatches are the failure I see most often and trust least in any migration I inherit rather than build myself. The legacy system holds a quantity in one unit, the legacy source data was extracted with an assumed conversion factor to the target stocking unit, and that factor was either wrong, out of date, or applied inconsistently across the extract. The load itself is completely happy: it sees a numeric quantity, it sees a valid unit of measure on the part record, it writes the value. Nothing about the transaction is invalid.

What actually happens is that the on-hand balance loaded into IFS is now arithmetically consistent and physically false. It will not surface at go-live, because nobody is comparing the freshly loaded balance against a physical count on day one. It surfaces at the first cycle count, or worse, the first time someone tries to ship an order against that balance and the pick fails or, more dangerously, succeeds against stock that is not really there in that quantity. By the time it surfaces, the legacy system is usually decommissioned, the original extract is gone, and reconstructing the correct conversion factor means going back to the part’s technical specification or, in the worst case, physically recounting everything affected.

The check that catches this before go-live is uncomfortably simple and rarely done under deadline pressure: for a sample of parts across every unit-of-measure pairing in the extract, not just the high-value ones, physically verify the conversion factor against the part specification, independently of whatever factor the extract used. If the legacy system and the target system disagree on the factor for even one pairing, assume every part using that pairing is suspect until proven otherwise, not just the one you happened to sample.

A migration runs in a sequence, dependent objects loading after the parents they reference. The failure mode here is subtler than a broken foreign key rejected at load time. It is a foreign key that resolves successfully, at the moment its record loads, to a parent record that exists in the target system for reasons entirely unrelated to being the correct parent: a batch that loaded slightly out of the intended order, or a mid-project dedup pass that consolidated two legacy IDs into one target record without updating every child reference to match.

The record is not invalid, it just does not point at the thing it was supposed to point at, and load validation, which only checks that a referenced key exists at the moment of the load, has no way to know that. It tends to surface in one of two ways: a report that silently pulls the wrong parent’s attributes for months before anyone notices, or a downstream process that fails in a way that looks unrelated to migration at all, which is what makes it expensive to trace back to its actual cause.

The mitigation I now insist on is a post-load reconciliation pass that is separate from load-time validation: after the full sequence completes, re-walk every parent-child relationship that matters for the modules in scope and confirm each child’s parent is the one the source system actually recorded, by comparing legacy identifiers carried through as cross-reference fields, not by trusting that the target key resolving at all means it resolved correctly. This has to run after the whole sequence, not batch by batch, because the specific failure pattern is a batch ordering issue that a single batch’s own validation cannot see.

Every migration I have worked on has had at least one point where the automated extract could not resolve something cleanly under the schedule available, and someone hand-corrected a batch of rows in a spreadsheet before feeding them into the load. This is not a criticism; it is sometimes the only realistic way to hit a cutover date. The failure is that the patch is applied once, works, and then nobody schedules the work to fold the correction back into the repeatable extract logic, because the project has already moved on to the next milestone.

The specific way this bites later is not usually the patched data itself going wrong; a careful hand-correction is often more accurate than the automated logic it replaced, at the moment it was made. It is that the underlying source data changes after go-live, a new batch of the same record type arrives through the same integration or a delta load, and the extract logic that was never fixed reproduces the original error on the new records, because nobody remembers, months later, that this particular field needed a hand adjustment and why. The knowledge lived in a spreadsheet on someone’s laptop, not in the transform logic, and the spreadsheet is gone or forgotten well before the problem resurfaces.

What I do differently now: every hand-patch gets a one-line entry in a migration decisions log, at the moment it is applied, stating which field, which record population, what the automated logic got wrong, and what the correct rule actually is. That log is the input to a follow-up task, tracked separately from go-live, to either fix the transform logic properly or, at minimum, confirm in writing that the condition causing the original error cannot recur post-cutover. A patch without that entry is indistinguishable, eighteen months later, from a deliberate design decision, and someone will eventually build on top of it assuming it was one.

Four checks catch this class of error after any load I am responsible for: conversion-factor consistency, parent-child cross-reference matching, patch-window edits and an independent-source quantity comparison. They are shown here as generic, PL/SQL-flavoured pseudocode using aliases rather than an assertion about a specific release’s exact schema, because the exact objects involved differ by module and by release:

None of these queries are complicated. What matters is that they run as a separate step after the load, not folded into load-time validation, because the point is to catch things that were valid at load time and wrong in a way that only shows up when compared against something outside the load itself.

1. Sample and independently verify conversion factors before the first mock load. Do this against the part specification, not against the extract's own assumptions, and treat any disagreement as a signal to check the whole unit-of-measure pairing, not just the sampled parts.
2. Run the post-load parent-child reconciliation after every mock load, not just the final one. Catching an orphan pattern in mock load two, while the extract logic is still being actively worked, is far cheaper than catching it after go-live.
3. Keep a live migration decisions log from day one. Every hand-patch gets an entry the day it is applied, not retroactively at project close-out when nobody remembers the details.
4. Assign an owner and a deadline to each logged patch. A decision log nobody is accountable for closing out is just documentation of a problem that still exists.
5. Run the independent-source quantity check at every mock load and at go-live. Comparing against the legacy system's own totals, not just internal consistency within the new load, is what catches a systematic conversion error rather than a one-off.
6. Freeze the decisions log and confirm every open item before cutover. An unresolved “temporary” patch at cutover needs an explicit, written decision to accept the risk, made by someone who can actually own that decision, not a default of silence.
7. Wire the same reconciliation queries as a recurring Custom Event check for the first few months post-go-live. New data flowing through the same integration paths can reproduce a migration-era error long after the migration project itself has closed, and a standing check inside the Extensibility Framework catches that far earlier than the next audit would.

Dariusz Myśliwiec: 25+ years in ERP and supply chain, 17+ on IFS (Apps 7.5–10 and IFS Cloud), with hands-on Data Migration Manager, FndMig and Oracle PL/SQL work across those projects. IFS Certified Associate Consultant. PRINCE2® 7. Based in Kraków, delivering remotely across Europe and globally through an independent practice.

Selected clients: Fugro · LGC · BVI Medical · Betafence (PRÆSIDIAD) · Barlinek · NGK Ceramics · Newag · Oleofarm.

IFS is a registered trademark of IFS AB; this practice is not affiliated with IFS AB.