There's no migration wizard between NAV and IFS. Every migration is a custom ETL project — extract from NAV's SQL Server, transform against IFS's entity model, and load through its business-logic-enforced API layer.
Migrating from Microsoft Dynamics NAV to IFS Cloud is a custom architectural translation project with no vendor-provided migration wizard or automated path between the two systems. NAV is built on SQL Server with a C/AL customization model that permits direct table modifications, while IFS Cloud runs on Oracle and enforces all business logic through an API-first import layer — meaning data cannot be inserted via direct SQL and must pass through IFS's state machine validators before being accepted. The fundamental data model differences extend to multi-company structure, asset management capabilities, and lifecycle state enforcement, where IFS will reject records that attempt to bypass correct state transitions. Every NAV-to-IFS migration requires a custom ETL project involving deliberate extraction strategy selection, offline data transformation, and entity-level mapping to reconcile NAV's open table architecture against IFS's logic-enforced projection model.
Read this first
Pair-specific gotchas that catch teams out. Each one has cost somebody a weekend.
Add a persistent legacy key (e.g., LegacyNavNo) as a custom attribute to every target
Add a persistent legacy key (e.g., LegacyNavNo) as a custom attribute to every target entity you care about. In IFS, persistent custom attributes are stored in the database, making them useful as idempotency keys, deduplication anchors, and rollback lookups.
Do not attempt direct SQL inserts into IFS's Oracle database
IFS's business logic layer enforces referential integrity, state machine transitions, and audit logging that direct inserts bypass. Records inserted via SQL will cause downstream failures in posting, reporting, and workflow execution.
The runbook
Work top to bottom. Tick steps as you go — your progress is saved in this browser.
01 Discovery Scope the ledger, the subledgers and the audit obligations.
Objective Agreed scope across master data, open transactions and historical balances, with finance and audit signed up.
Keep these open
-
Inventory master data and transaction volumes in Dynamics NAV
Count GL accounts, customers, vendors, items, fixed assets, open AR and AP, and transaction lines by year. Transaction line volume, not header count, is what determines your load time.
Data Profiler Get real record counts instead of estimating from memory -
Decide the history strategy with finance and audit
Choose between opening balances only, open items plus balances, or full transactional history. This is the single biggest scope decision in an ERP migration: full history multiplies effort many times over, and most organisations land on balances plus open items plus a read-only archive.
Full transactional history is rarely worth the cost. Confirm what your auditor actually requires before assuming you need it.
Vendor Evaluator Score IFS against alternatives on weighted criteria -
Consult the external auditor early
The auditor has views on cut-over timing, audit-trail retention and how you evidence that balances carried across correctly. Finding this out after go-live can mean a qualified opinion, so get it in writing now.
-
Review the chart of accounts and decide whether to redesign
A migration is the natural moment to restructure the COA, and also the riskiest one. If you redesign, you need a mapping from old to new for every historical balance, plus a plan to restate comparatives.
Redesigning the chart of accounts mid-migration doubles the reconciliation burden. Treat it as a separate, sequenced project if you can.
-
Catalogue integrations and statutory reporting
List banking feeds, payment gateways, tax filing, payroll, CRM, e-commerce, warehouse and BI. Then list every statutory and tax filing obligation with its deadline — those deadlines constrain your window absolutely.
-
Pick a period-aligned go-live date
ERP cutovers align to a period boundary — ideally the start of a fiscal year, otherwise the start of a clean month. Mid-period cutover means split-period reporting for the rest of the year.
Dynamics NAV → IFS specifics
- Small business, one-time move
- CSV/FNDMIG for master data. Manually recreate open transactions if volume is low.
- Enterprise migration
- Custom ETL (SQL extraction) combined with IFS API or FNDMIG loading.
- Ongoing NAV + IFS coexistence
- API-based sync or custom integration. Not CSV.
- Low engineering bandwidth
- Managed service. DIY heroics on a one-time ERP migration rarely pay off.
Don't move on until
- Chart of accounts and master-data counts confirmed
- History strategy agreed: balances, open items, or full transactional detail
- External auditor consulted on the migration approach
02 Data Audit Reconcile the source before you migrate it — you cannot fix a ledger later.
Objective A source ledger that balances, with master data cleansed and every open item agreed.
Keep these open
-
Produce and sign off a source trial balance
Run the trial balance in Dynamics NAV and have the controller sign it. This is your migration baseline: without a signed pre-migration position you have nothing to reconcile the target against, and any later discrepancy is unarguable.
Without a signed, dated source trial balance you cannot prove the migration preserved the ledger. Do this before anything else.
-
Reconcile subledgers to the general ledger
Confirm AR, AP, inventory and fixed-asset subledgers tie to their GL control accounts. Pre-existing breaks must be resolved in Dynamics NAV: migrating an out-of-balance ledger makes the break permanently unattributable.
Data Profiler Profile the Dynamics NAV export for nulls, outliers and type drift -
Clean and deduplicate master data
Deduplicate customers, vendors and items, and identify records that should not carry forward. Duplicate vendors are also a fraud-control weakness, so this has value beyond the migration.
Data Cleaner Strip empty rows, stray whitespace and dead columns -
Agree open AR and AP item by item
Every open invoice, credit note and payment on account needs an owner and an agreed amount, including partially-paid items and foreign-currency balances. Open items are what customers and vendors will dispute in week one.
-
Validate export structure, encoding and precision
Check numeric precision and rounding on the export, and confirm dates and currency codes are unambiguous. Precision loss on amounts is silent, cumulative and produces penny differences that take days to trace.
Amounts exported at reduced precision will not re-total. Verify decimal places before you accept the export.
CSV Validator Catch broken headers and ragged rows in the raw export -
Scan for regulated data and produce masked test data
ERP data holds bank details, tax IDs and payroll information. Scan it, restrict who can see it, and generate a masked copy for the sandbox and for any implementation partner.
PII & Compliance Scanner Find regulated fields before they land in a new system
Dynamics NAV → IFS specifics
- Customers & Vendors (Tables 18, 23)
- Active vs. blocked records. NAV's Blocked field has multiple states (empty, Ship, Invoice, All) — decide which to migrate.
- Chart of Accounts (Table 15)
- Map NAV's G/L Account table to IFS's accounting code structure. Watch for account types that don't translate directly.
- Items / Inventory (Table 27)
- NAV's item table carries costing method (FIFO, LIFO, Average, Standard, Specific) — IFS uses different costing terminology.
- Open Transactions
- Sales orders (Table 36), purchase orders (Table 38), production orders in progress at cutover.
- Posted Transactions
- G/L entries (Table 17), customer/vendor ledger entries. Decide how much history to migrate vs. archive.
Don't move on until
- Trial balance in Dynamics NAV balances and is signed by the controller
- AR and AP subledgers reconcile to the GL control accounts
- Master data deduplicated and inactive records identified
03 Field Mapping Map the COA, the dimensions and the subledger structures.
Objective A signed mapping covering the chart of accounts, dimensions, tax codes and currency handling.
Keep these open
-
Map the chart of accounts account by account
Every source account maps to exactly one target account, or to a documented split with agreed proportions. The controller reviews and signs this line by line — an unreviewed COA map is how a balance sheet stops balancing.
Schema Mapper Opens pre-loaded with the Dynamics NAV → IFS field pair -
Map dimensions, cost centres and analysis codes
ERPs differ structurally here: segments, dimensions, tracking categories and classes are not interchangeable. Confirm how IFS models analysis and whether your existing reporting hierarchy survives the translation.
-
Map tax codes, rates and jurisdictions
Map every tax code with its rate, jurisdiction and reporting treatment, then verify the mapping reproduces your last filed return. Tax errors are statutory exposure, not reporting inconvenience.
A tax-code mapping that has not been tested against a previously filed return is untested. Reproduce a real filing before sign-off.
-
Decide multi-currency and exchange-rate handling
Confirm functional and reporting currencies, and how historical rates are stored. Revaluing historical transactions at current rates rewrites reported results and will not tie to filed accounts.
Historical transactions must retain their original transaction-date rates, or your comparatives will not match filed statements.
-
Map master data and subledger structures
Map customer and vendor records with their payment terms, credit limits and tax registrations, and item records with units of measure and costing method. Costing-method differences change inventory valuation, which changes the balance sheet.
-
Set load order and freeze the spec
COA, then dimensions, then master data, then opening balances, then open items, then any historical detail. Version and sign off the spec with the controller before the pilot.
Don't move on until
- Account-by-account COA mapping reviewed by the controller
- Tax codes and jurisdictions mapped and verified against filings
- Multi-currency and rate handling agreed with finance
04 Test Migration Prove the ledger balances in the target before you trust it.
Objective A sandbox load whose trial balance matches the signed source position to the penny.
Keep these open
-
Configure the IFS sandbox with the agreed structures
Build the COA, dimensions, tax codes, currencies, fiscal calendar and posting rules before loading anything. Every one of these affects how a posted transaction lands, so an unconfigured sandbox produces meaningless results.
-
Load master data and validate it
Load customers, vendors and items first and verify counts, payment terms, tax registrations and costing methods. Transactions cannot post correctly against wrong master data, so this gate comes before any balance work.
Migration Validation Tool Diff the pilot batch against source before scaling up -
Load opening balances and prove the trial balance ties
Load opening balances and run a trial balance in IFS, comparing to the signed source position. It must match exactly — a rounding difference here is a mapping defect, not a rounding difference.
Any variance at all between source and target trial balance must be explained line by line. "Close enough" is never acceptable in a ledger.
-
Load open items and reconcile the subledgers
Load open AR and AP with their ageing intact, then confirm subledger totals tie to GL control accounts and that ageing buckets match. Ageing that shifts means transaction dates mapped wrongly.
-
Run a full period-end close in the sandbox
Execute the whole close: revaluation, accruals, depreciation, tax calculation, and financial statement generation. Compare every statement to Dynamics NAV for the same period. The close is where structural mapping errors finally become visible.
-
Test transactions end to end and reproduce a tax filing
Post a sales order to cash and a purchase order to payment, then generate the tax return for a previously filed period and compare it to what you filed. If both reconcile, the configuration is sound.
Don't move on until
- Target trial balance matches the signed source trial balance exactly
- Subledgers reconcile to control accounts in the target
- A full period-end close has been run in the sandbox
05 Cutover Switch the ledger on a period boundary, with balances proven.
Objective Balances and open items live in IFS, transacting resumed, and a signed post-load trial balance.
Keep these open
-
Close the final period in Dynamics NAV and freeze posting
Complete the period-end close, then lock posting entirely. An ERP freeze is absolute: a single journal posted to the old system after the final export leaves the two ledgers permanently divergent.
One journal posted in the old ERP after the final export breaks the reconciliation permanently. Lock posting at the system level, not by asking people nicely.
-
Publish the cutover runbook with the abort point
A timed, owner-named sequence for load, balance verification, integration switch and go/no-go, with an explicit abort criterion. The trial-balance check is the gate — nothing proceeds until it ties.
-
Load balances and open items into production
Load the final opening balances and open AR/AP into IFS production, following the pilot-proven sequence. Do not improvise the order under time pressure.
-
Reconcile and sign the post-load trial balance
Run the trial balance in IFS and reconcile it to the signed source position, then have the controller sign the result. This signature is your evidence for the auditor and your go/no-go gate.
Migration Validation Tool Confirm the final delta landed before you reopen -
Repoint banking, payment and tax integrations
Switch bank feeds, payment gateways, tax filing connections, payroll and BI, then process one real low-value payment and one bank reconciliation end to end. Banking errors move real money, so verify with live traffic.
Payment integrations left connected to the old ERP can duplicate real payments. Disable them before switching, not after.
-
Go/no-go, then open for transacting with daily reconciliation
Call the decision on the signed trial balance, open IFS for posting, and reconcile daily for the first two weeks with finance support on hand. Keep Dynamics NAV read-only for statutory retention — this is an audit requirement, not a preference.
Don't move on until
- Post-load trial balance signed by the controller
- Banking, tax and payment integrations verified live
- Users transacting and the first daily reconciliation clean
06 Validation Prove the statements, the tax position and the audit trail.
Objective Financial statements reproducing the source position, a clean tax filing, and auditor acceptance.
Keep these open
-
Reconcile the full ledger and all subledgers
Reconcile trial balance, AR, AP, inventory, fixed assets and bank against the signed source position. Produce a single reconciliation pack that goes to the auditor.
Migration Validation Tool Reconcile Dynamics NAV and IFS record-for-record -
Reproduce the financial statements
Generate balance sheet, P&L and cash flow in IFS and compare to the pre-migration statements. Every variance needs a documented explanation traced to a specific mapping decision.
-
Complete and review the first period-end close
Run the first real close in IFS with extra review at every step. Compare its duration and outcome to your historical close, and treat anything unexpected as a live finding.
Data Profiler Prove field completeness held up through the load -
Verify the tax position and file
Generate and review the first tax filing from IFS, reconciling it to the underlying transactions before submission. Have the tax lead review it independently.
The first statutory filing out of a new ERP should be reconciled manually to source transactions before submission.
-
Confirm controls, segregation of duties and audit trail
Verify user permissions, approval limits, segregation of duties and audit logging in IFS. Controls do not migrate, and a control gap found by an auditor is far more expensive than one you find yourself.
PII & Compliance Scanner Produce the compliance evidence your auditor will ask for -
Obtain auditor acceptance and retain the archive
Walk the auditor through the reconciliation pack, get written acceptance, and retain Dynamics NAV read-only for the full statutory retention period. Diarise the retention expiry rather than the contract renewal.
Don't move on until
- Financial statements match the pre-migration position
- First period-end close completed and reviewed in IFS
- Auditor satisfied and archive retained for the statutory period
Field mapping reference
The field-by-field mapping for each object. Use this as the starting point for your mapping spec.
NAV Entity (Table) NAV Table ID
| Dynamics NAV field | IFS field | Notes |
|---|---|---|
| Customer | 18 | Map No. to customer_id. IFS separates customer identity from addresses (CustomerInfoAddress). |
| Vendor | 23 | NAV vendor terms → IFS payment terms mapping required. |
| Contact | 5050 | Create as Person in IFS, then link to Customer via CustomerInfoContact. |
| Item | 27 | IFS distinguishes general part definition from site-specific inventory parameters. |
| G/L Account | 15 | Restructure chart of accounts to fit IFS code part structure. |
| Sales Header | 36 | Map document types. IFS state machine applies. |
| Sales Line | 37 | Line-level item references and pricing. |
| Purchase Header | 38 | Includes approval workflow state mapping. |
| Purchase Line | 39 | Unit of measure conversions critical here. |
| G/L Entry | 17 | Posted entries — decide on history depth. |
| Item Ledger Entry | 32 | Costing and quantity tracking. |
| Fixed Asset | 5600 | Depreciation method translation required. |
| Production BOM | 99000771 | Bill of materials mapping. |
| Routing | 99000764 | Operation-level mapping. |
| Dimension Value | 349 | NAV dimensions → IFS accounting code parts. |
(Table 18 - Customer) (CustomerInfo)
| Dynamics NAV field | IFS field | Notes |
|---|---|---|
| No_ | CustomerId | String (Max 20). Preserve as-is or remap. |
| Name | Name | String. IFS limit may be shorter — truncate if needed. |
| Address | Address1 (CustomerInfoAddress) | String (Max 35). |
| City | City (CustomerInfoAddress) | String (Max 35). |
| Country_Region Code | Country | 2-char ISO → may require full country database ID in IFS. |
| Currency Code | CurrencyCode | String (ISO 3). |
| Payment Terms Code | PayTermId | String mapping required — NAV and IFS payment term IDs won't match. |
Risk matrix
Per-object risk for this pair. Plan extra validation around anything marked high.
| Object | Risk | Notes |
|---|---|---|
| Customers | medium | NAV Table 18 contains active and blocked customer records where the multi-value 'Blocked' field requires interpretation and mapping before IFS import to avoid creating invalid customer master records. |
| Vendors | medium | NAV Table 23 carries similar blocked-status complexity as customers, and vendor payment terms and banking data must be remapped to IFS's supplier model with care to preserve payment run integrity. |
| Open Sales Orders | high | Partially fulfilled or partially invoiced sales orders exist in intermediate NAV states that have no direct IFS equivalent, and IFS's state machine will reject imports that attempt to load these records without traversing the correct lifecycle transitions. |
| Purchase Orders | high | Open purchase orders with partial receipts or pending approvals carry multi-line state complexity that must be resolved before import, as IFS enforces header-to-line state consistency and will reject mismatched records. |
| General Ledger Transactions | high | Historical G/L entries are typically archived rather than migrated into IFS transactional tables because importing closed accounting periods through IFS's business logic layer requires special archive table access and period unlock procedures. |
| Chart of Accounts | medium | NAV account structures must be restructured to fit IFS's multi-company shared data model, and any dimensional or analytical account segments used in NAV require explicit mapping to IFS's code string structure before master data load. |
| Inventory and Item Master | medium | Item master records require unit-of-measure, costing method, and product classification remapping into IFS's part catalog structure, and on-hand quantity balances must be loaded as opening inventory transactions rather than direct record inserts. |
| Fixed Assets | medium | NAV fixed asset records including depreciation books and accumulated depreciation values must be translated into IFS's native EAM object structure, which carries significantly richer lifecycle and maintenance data requirements than NAV's asset model. |
| Custom Table Data (50000+ Range) | high | Data stored in NAV's custom table range has no predefined IFS target, requiring per-table scoping decisions on whether to migrate into IFS custom logical units, export to an archive, or discard — with no automated mapping possible. |
| ISV Add-on Data | high | Data managed by ISV add-ons installed in NAV may exist in proprietary table structures with undocumented schemas, making extraction dependent on ISV cooperation or reverse engineering of the add-on's data model before transformation can begin. |
The hard parts
What makes this specific migration difficult, beyond the mechanics.
IFS State Machine Enforcement
IFS Cloud enforces strict lifecycle state transitions via its API layer, meaning historical NAV records with terminal statuses like 'Closed' or 'Invoiced' cannot be directly imported and must either pass through all intermediate states or be loaded into dedicated historical archive tables.
No Native Migration Path
There is no vendor-provided migration wizard or direct connector between Dynamics NAV and IFS Cloud, requiring every migration to be built as a custom ETL pipeline with purpose-built extraction, transformation, and loading logic.
NAV Custom Table Extraction
Long-running NAV instances accumulate C/AL modifications and custom tables in the 50000–99999 range that have no direct IFS equivalent, requiring per-table analysis to determine whether records should be migrated, transformed, or archived.
NAV OData Performance Constraints
NAV's OData layer has no bulk endpoint and enforces a default page size limit of 20,000 records, making API-based extraction of large datasets slow and requiring pagination logic that significantly extends migration runtime.
Authentication and Protocol Differences
NAV uses NTLM/Negotiate authentication while IFS Cloud requires OAuth 2.0 client credentials, and OData services in NAV must be explicitly published per entity before extraction can begin, adding configuration overhead to API-based migration approaches.
Chart of Accounts Restructuring
NAV's generalist SMB account structure must be remapped to IFS Cloud's multi-site, multi-company shared data model, often requiring dimensional restructuring and consolidation logic that cannot be automated without deep knowledge of both financial models.
Tools used in this playbook
All free, all run entirely in your browser — nothing is uploaded.
FAQ
Can you migrate directly from Dynamics NAV to IFS Cloud?
No. There is no vendor-provided migration wizard or tool between NAV and IFS. Every migration requires a custom ETL pipeline — extracting data from NAV's SQL Server database, transforming it to match IFS's entity model and validation rules, and loading it through IFS's REST API or Data Migration (FNDMIG) framework.
What is the best way to extract data from Dynamics NAV for migration?
Direct SQL queries against NAV's SQL Server database are the fastest and most complete extraction method. NAV also supports OData v4 web services, but these must be published per entity and have a default page size limit of 20,000 records. For large datasets like G/L entries or item ledger entries, SQL extraction is significantly faster than OData.
What is the biggest risk when migrating to IFS?
Ignoring the IFS state machine. You cannot simply insert historical records in a 'Closed' or 'Invoiced' state. They must pass through specific API state transitions or be mapped to dedicated historical archive tables. This is the most common failure point in NAV-to-IFS migrations.
What happens to NAV custom tables during IFS migration?
NAV custom tables (ID 50000+) have no automatic equivalent in IFS. Each must be individually assessed: map to an existing IFS entity if a functional equivalent exists, create a custom logical unit in IFS (requires development work), or archive the data externally for historical reference.
Can middleware like Zapier handle a NAV to IFS migration?
Not as the primary migration engine. Middleware is designed for event-driven, low-volume syncing. Zapier's documented support is centered on Business Central, not Dynamics NAV on-prem. Use middleware for light post-migration sync at most — not for bulk historical data loads.