Blog

Key takeaways

• Migration is the riskiest, least-documented phase of any IFS Cloud project — budget for it like an implementation, not a data dump.
• FndMig is the low-level foundation loader; DMM is the governed, mapped, auditable layer on top — use them for different jobs.
• Load order follows referential dependencies: suppliers and customers before parts, parts before part–supplier, masters before open transactions.
• Validate before and after every load — referential integrity, duplicates, completeness — and reconcile counts and balances back to the source.
• Rehearse the full cutover at least twice, with a tested rollback, before the real one.

Configuration is visible. Reports are visible. Migration is not — until the day a buyer opens a purchase order that points at a supplier who does not exist, or finance runs a trial balance that is off by the value of every open invoice you failed to load. By then the project is in production and the fix is a firefight.

Three things make migration uniquely dangerous. First, it is poorly documented: IFS ships the tooling, but the mapping from your legacy model to the IFS data model is yours to work out, object by object. Second, it is deeply interdependent: an IFS Cloud part cannot stand alone — it needs inventory part data, part–supplier links, units of measure and cost sets, all in the right order. Third, it is tested last, when there is least time to react.

Treat migration as its own workstream with its own plan, not an afterthought bolted to the end of the build. If you are still scoping the wider project, read the IFS Cloud upgrade readiness checklist first — migration readiness is a large part of overall readiness.

IFS gives you two mechanisms, and the mistake is treating them as rivals. They sit at different levels.

Rule of thumb: because both routes write through standard IFS APIs, your data is validated by the same business logic that guards manual entry. That is the point — you are not bypassing IFS, you are feeding it at scale. Nothing here touches core, which keeps the whole project inside Clean Core discipline.

Order is not a preference — it is dictated by referential integrity. Every object below depends on the ones above it. Load out of order and the API will reject the row, or worse, accept an orphan.

1. Suppliers — the supply-chain anchor. Address, payment and tax data must be complete before anything references them.
2. Customers — loaded alongside suppliers; both are masters that open transactions will point at.
3. Parts — part master, then inventory part per site. Units of measure and part types must already exist.
4. Part–supplier — the link that makes a part purchasable. Needs both the part and the supplier already loaded.
5. Price lists — supplier price data and sales price lists, so transactions price correctly.
6. Open purchase orders — only genuinely open lines. Confirm quantities and expected receipts against the source.
7. Open sales orders — same discipline; do not migrate fully-delivered or cancelled lines.
8. Inventory balances — on-hand quantities by location, lot and serial, valued against the cost set.
9. Open invoices — supplier and customer open items, reconciled to the ledger control totals.

Freeze each layer before starting the next. Loading open POs before the part–supplier link exists is the single most common cause of a stalled cutover.

Validation is not one gate at the end. It is a gate before every load and a gate after it. Three questions run through all of them.

• Referential integrity — does every foreign key resolve? No PO line without a part, no part–supplier without a supplier, no invoice without a customer.
• Duplicates — are supplier, customer and part identifiers unique after de-duplication? Merge in the source, not in IFS.
• Completeness — do row counts and control totals reconcile back to the legacy extract? Inventory value and open-invoice balances must match the ledger.

Pre-load validation runs against the staging data and stops bad rows before they hit the API. Post-load validation proves what actually landed: count-in versus count-out, sampled record inspection, and a business sign-off from the data owner — the buyer confirms the POs, finance confirms the balances. Automate the reconciliation queries once and re-run them on every rehearsal.

A migration that reconciles on the first go-live is worth more than any amount of clever configuration. I plan the object model, build the FndMig and DMM loads, write the reconciliation, and rehearse the cutover with your team until it is boring — which is exactly how it should feel on the day.

Book a 30-minute migration call See the data migration service

Rehearse the full cutover end to end at least twice against a production-like copy. Time every load, record the total window, and confirm the sequence and the reconciliation on real volumes — not a sample. The rehearsal is where you discover that inventory takes four hours, not forty minutes.

Have a tested rollback. That normally means a restore point or snapshot taken immediately before the load window, plus a documented decision rule: what has to reconcile by when, or you restore and try again at the next window. A rollback you have never tested is a hope, not a plan.

The failure modes repeat across projects:

• Loading transactions before masters — orphaned rows.
• Migrating closed or cancelled orders as if open.
• Duplicate suppliers or parts merged too late.
• Inventory value that will not tie to the ledger.
• No reconciliation, so nobody can prove completeness.
• A cutover window guessed, never rehearsed.

Dariusz Myśliwiec — 25+ years in ERP and supply chain, 17+ on IFS (Apps 7.5–10 and IFS Cloud). IFS Certified Associate Consultant. PRINCE2® 7. Based in Kraków, delivering remotely across Europe and globally. Independent practice — you talk to the consultant who runs the migration, not a sales layer.

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.