A build-to-order migration engine that moves Dynamics NAV or GP chart of accounts, master data, open transactions and balances into Dynamics 365 F&O, with reconciliation reports that prove the numbers. Built to order by ECOSIRE for Dynamics 365 F&O (build-to-order) — indicative price from $1499.00 USD; request a quote for a scoped proposal.
A build-to-order migration engine that moves Dynamics NAV or GP chart of accounts, master data, open transactions and balances into Dynamics 365 F&O, with reconciliation reports that prove the numbers.
Built to order
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.
### 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.
A short call to confirm the workflow, your platform version and where the integration boundaries sit.
You receive a written scope and a fixed price. Nothing is built until you approve it.
We develop against a copy of your configuration and test it there. Typically two to four weeks.
We install on your instance, hand over the source, and support it for twelve months.
Owns the closing balance in the legacy system and the opening balance in F&O, and will personally sign off that they match. The reconciliation reports and preserved invoice ageing give them evidence rather than assurances, and the mapping forms let their own team own the account translation instead of relaying it through developers.
Is running a re-implementation where the data workstream is the single largest schedule risk and the hardest to estimate. A fixed-scope migration engine with repeatable rehearsal runs turns an open-ended unknown into a dated task with a runbook and a rollback position.
Is configuring F&O processes and does not want the team pulled into writing extraction and load code against a legacy schema. Handing the migration engine to a dedicated build keeps their consultants on process design while the data path is developed and tested in parallel.
| Criterion | ECOSIRE | Custom Build | Competitor |
|---|---|---|---|
| Mapping maintained as data by finance, not hardcoded in scripts | Included | Partial support | Partial support |
| Consolidates multiple legacy companies into multiple legal entities | Included |
From $1499.00
Starting point — quoted to your scope
| Partial support |
| Open AR and AP loaded with original document number, date and ageing | Included | Partial support | Included |
|---|
| Automated legacy-versus-F&O reconciliation reporting | Included | Not included | Partial support |
|---|
| Repeatable rehearsal runs promoted as DMF packages between environments | Included | Partial support | Partial support |
|---|
| Batch framework execution with bundling and resume-from-failure | Included | Partial support | Partial support |
|---|
| Extension only, no overlayering, update-safe under One Version | Included | Partial support | Included |
|---|
| Fixed-scope price with cutover runbook and post-go-live support window | Included | Not included | Partial support |
|---|
An X++ extension that imports bank statements into Dynamics 365 F&O and fuzzy-matches lines against payments, deposits and fees. Built to order for your legal entities after a scoping call and fixed quote.
A behaviour-aware treasury forecasting app for Dynamics 365 Finance & Operations. Built to order as an X++ extension after a scoping call and a fixed quote — nothing is pre-built or downloadable today.
A built-to-order forecasting and planning layer for Dynamics 365 Finance & Operations, with external demand signals, explainable forecasts and scenario comparison. Scoped and built by ECOSIRE after a fixed quote.
A build-to-order X++ extension that captures vendor invoices, extracts line data, matches them against purchase orders with tolerance rules and routes exceptions through F&O workflow. ECOSIRE builds it for your entity structure after a fixed quote.