// Source System
IFS to Dynamics 365 Data Migration
We've moved customer, supplier and general ledger data out of IFS Applications into D365 F&O — cleanly, completely, on time.
IFS — Entity Mapping
// The Challenge
Why IFS migrations are hard.
IFS Applications covers finance, supply chain and asset management in one suite, which means data that would sit in separate systems elsewhere — maintenance history against fixed assets, for example — often needs to be disentangled before it maps onto D365's more modular structure.
Older IFS versions have more limited API access than the current cloud-based releases, so discovery has to confirm which version and deployment model you're on before we can commit to an extraction approach — direct database access, IFS's own integration layer, or flat-file exports.
IFS's accounting rules engine, which derives GL postings from underlying transactions, means the general ledger data itself is often a downstream result of business rules rather than a direct entry — understanding those rules is necessary to migrate historical balances accurately rather than just the summarised output.
// Mapping
IFS entities, mapped to D365.
| Source entity | D365 entity |
|---|---|
| Customer Info | CustTable |
| Supplier Info | VendTable |
| General ledger (via Accounting Rules) | MainAccount / GeneralJournalAccountEntry |
| Inventory Part | InventTable |
// Pitfalls
Where IFS migrations go wrong.
- IFS's accounting rules engine derives GL postings from transactions — understand the rules before assuming the ledger data is a direct entry.
- Version and deployment model (on-prem vs cloud) materially affects extraction method — confirm this before committing to an approach.
- Asset maintenance history bundled with finance and supply chain data needs disentangling before it fits D365's modular structure.
- API access varies significantly by version — older on-prem instances often need flat-file or direct database extraction.
// Domains
Domains we most commonly migrate from IFS.
// Methodology
The same six phases, every time.
01
DISCOVER
Profiling, volumes, quality scoring across every source system in scope.
02
DESIGN
Source-to-target mapping and the cleansing plan, agreed before build starts.
03
BUILD
DMF templates, KingswaySoft packages, SQL staging tables.
04
TEST
Two mock migrations, full reconciliation, and UAT sign-off.
05
CUTOVER
Final load, balance reconciliation, go-live clearance.
06
STABILISE
Corrections, closure report, retainer option for what follows.
// FAQ
Questions about migrating from IFS.
Yes, materially. Cloud-based IFS releases have a modern API surface; older on-prem versions typically need direct database or flat-file extraction.
Planning a IFS to D365 migration?
Start with a Health Check to see exactly what needs cleansing before it moves.