NAV & GP to F&O Migration Toolkit

Companies still running Microsoft Dynamics NAV or Microsoft Dynamics GP tend to hit the same wall at the same time. The finance model has outgrown a single company database, the customisations are welded into the schema, and there is no supported in-place upgrade that lands you in Dynamics 365 Finance and Supply Chain Management. Moving to F&O is a re-implementation, and what stalls re-implementations is almost never process design — it is the data. Somebody has to decide what a segmented GP account string becomes in a main account plus financial dimension model, what happens to years of posted history, and how you close the final period in the legacy system and open the first period in F&O without dropping a single open invoice.

This is a build-to-order toolkit. There is nothing to download and nothing pre-packaged sitting on a shelf. ECOSIRE builds the migration engine against your actual legacy schema, your actual chart of accounts and your actual legal entity design, then installs it into your sandbox first and your production environment second.

What ECOSIRE builds

### A mapping layer, not a one-off script The core of the toolkit is a set of X++ extension tables and forms inside F&O holding the mapping between the legacy world and the target world: legacy company to legal entity, legacy account segment to main account and financial dimension, legacy customer, vendor and item numbers to F&O number sequence output, legacy posting group to posting profile. Mappings are data — edited by your finance team in an F&O form with validation, versioned, and re-runnable. That matters because you will run the migration more than once: a trial load, at least one dress rehearsal, then the real cutover. A hardcoded script gives you none of that.

### Extraction and staging We build extraction packages that read the legacy source directly — GP company databases and their GL00100 / GL20000 account and transaction structures plus the receivables and payables tables, or NAV G/L Entry, Cust. Ledger Entry, Vendor Ledger Entry and Item Ledger Entry — and land the result in staging tables inside F&O. From staging everything moves through the Data management framework: custom and standard data entities, composite entities where a header and its lines must arrive together, and data projects that can be exported as packages and promoted between environments so the sandbox run and the production run are demonstrably the same run.

### Chart of accounts and ledger dimensions GP account strings and NAV dimension setups do not map one-to-one onto F&O. We build the translation into MainAccount, into your account structures, and into the DimensionAttributeValueCombination records behind every posting — including default dimension templates on customers, vendors, released products and fixed assets so new transactions inherit dimensions correctly after go-live. Where a legacy segment is really a department, a cost centre or a project, we map it to the right dimension attribute rather than inflating your main account list into something nobody can report on.

### Master data Customers and vendors with their contacts and LogisticsPostalAddress records, released products with product masters, product dimensions and unit conversions, bank accounts, terms of payment, sales tax groups and item sales tax groups, trade agreements, and fixed assets loaded with acquisition value, prior accumulated depreciation and remaining service life on the asset book so the first depreciation proposal in F&O is correct rather than approximately correct.

### Open transactions Open AR and AP arrive as customer and vendor invoice journals with the original document number, invoice date and due date preserved, so ageing is honest on day one and your collections team does not restart the clock on every open item. Bank balances and unreconciled items come across so the first reconciliation actually reconciles. Inventory on hand loads through counting or movement journals at the correct site, warehouse and tracking dimension, with the costing decision — standard, weighted average or FIFO — made deliberately during scoping instead of discovered during cutover. Open purchase and sales orders load with remaining quantities only.

### Historical balances Full transaction-level history rarely belongs in F&O. The default we recommend is trial balance by period and dimension for the number of comparative years you need, loaded through the general journal under a dedicated journal name and a reserved voucher series, so migrated history is instantly separable from live posting in every enquiry and report. If you genuinely need line-level history inside F&O, that is a scoping decision with a cost attached and we quote it as one rather than discovering it halfway through.

### Reconciliation and control Every load writes to a reconciliation table and produces a comparison report: legacy balance versus F&O balance by main account, by dimension, by legal entity and by period; customer and vendor ageing totals; inventory quantity and value by item group. The migration is not finished because a batch job completed. It is finished because the two systems agree and you are holding the report that proves it — the artefact your auditors will ask for.

### Built to run at scale Large loads execute under the F&O batch framework using SysOperation service classes with configurable bundling, resume-from-failure and a per-record error log, rather than a monolithic job that dies on record 40,000 and leaves you guessing. Long-running steps are visible in batch job history and can be scheduled precisely into a cutover window.

## Who it is for Finance and IT teams on NAV or GP who have already chosen F&O and now need the data path built. Implementation partners running the functional workstream who want the migration engine owned by a team whose only job is the migration. Groups consolidating several legacy company databases into one F&O instance across multiple legal entities, where the mapping problem multiplies with every company added.

## How delivery works 1. Scoping call. We review the legacy version and edition, the number of companies, the account string structure, which modules are genuinely in use, how many years of history you need, and your target legal entity design. 2. Fixed quote. You receive a written scope listing the entities to be built, the mapping rules, the reconciliation reports and the number of rehearsal runs included. The price is fixed against that scope. 3. Build. Typical lead time is two to four weeks depending on legal entity count and module coverage, with a mid-build checkpoint where the mapping forms run against a sample extract from your data. 4. Install in test. The deployable package goes into your sandbox through your own LCS pipeline. We run a full trial load with your team and hand over the reconciliation output. 5. Rehearsal, then production. At least one dress rehearsal on a refreshed sandbox, then the production run inside your cutover window, executed against a written runbook with named owners and go/no-go checks. 6. Support window. An agreed post-go-live period for defect fixes and mapping corrections.

## Scope notes Everything is delivered as extensions. There is no overlayering, no modification of standard objects, and nothing that blocks a platform update. Legacy customisations are not migrated as code: where a NAV or GP customisation holds data you need in F&O, it becomes a mapped extension in the target and is quoted separately. Access to your legacy databases and your F&O environments stays under your control throughout.