NAV 2015 – 2018
Your current environment, with its database, C/AL base-code modifications, add-ons, and integrations.
Every remaining Dynamics NAV version now has a published end-of-support date, and the migration is not a database copy. Your C/AL customizations, ISV add-ons, integrations, and history each need a decision before anything moves.
We assess what you're running, establish the supported upgrade path for your specific version, and give you a defined scope and realistic timeline before you commit to a project.
Every Dynamics NAV release follows Microsoft's fixed lifecycle: five years of mainstream support, then five years of extended support covering security updates only. Once the extended date passes, no further updates are issued for that version.
The dates below come straight from Microsoft's lifecycle record. Find your version, then work backwards from the date to decide when planning needs to start.
Source: Microsoft product lifecycle documentation. Dates are shown in Pacific Time. Running a version whose window has closed doesn't stop the system working — it means Microsoft issues no further security updates for it, and migration planning becomes the priority rather than the option.
Most migration pages compress this into "NAV to Business Central." Microsoft's supported path for NAV 2015 through 2018 involves intermediate steps — and the C/AL to AL conversion that happens along the way is where most of the project effort actually sits.
Knowing this upfront changes how you budget and schedule the work.
Your current environment, with its database, C/AL base-code modifications, add-ons, and integrations.
The mandatory stepping stone. This is where the application is converted from C/AL to AL and the extension model takes over.
C/AL → ALA second on-premises hop that brings the application and data onto a current release before any cloud move.
Continuous updates, Microsoft-managed infrastructure, and access to Power Platform, Power BI, and Copilot.
Why the intermediate steps matter to you: data held in tables that carry code customizations can't simply be carried forward — those customizations have to be handled as extensions first. That conversion work is the part a "we'll just move your database" quote leaves out, and it's the main reason two NAV migrations of similar size can differ by months.
Two companies on the same NAV version can have completely different projects. The variables below are what separate a four-month migration from a twelve-month one — so we inventory every one of them before quoting anything.
Every base-code modification is reviewed and given a decision: convert to an extension, replace with standard functionality, or retire. Business Central online runs on the extension model, so nothing carries over untouched.
Each third-party add-on gets checked for a Business Central equivalent, a vendor upgrade path, a replacement, or retirement. A single unsupported add-on can reshape the whole plan.
EDI, shipping, payroll, CRM, banking, warehouse systems, and custom APIs are inventoried and tested. These are usually the connections nobody documented.
Years of added tables and fields need explicit mapping and a destination in the new data model. Unmapped fields are how history quietly goes missing.
You decide what moves, what gets transformed, and what gets archived. Carrying a decade of transactions across costs real time — sometimes it's worth it, often it isn't.
Business Central online authenticates through Microsoft Entra ID, so legacy NAV logins and permission sets need to be re-established rather than transferred.
Custom report layouts, invoice and statement formats, and regulatory outputs are catalogued and rebuilt where the new platform handles them differently.
Approval chains, posting routines, and the workarounds your team built over the years get mapped — so the new system fits how the business actually runs today.
Anyone quoting a NAV migration before seeing your environment is guessing. What we can give you upfront are honest planning bands, based on how complex the environment turns out to be — then a defined scope once we've looked.
Limited base-code modification, few or no ISV add-ons, straightforward integrations, and a clear decision to leave most history behind.
Meaningful C/AL modifications, several add-ons needing assessment, multiple live integrations, and history that partly needs to come across.
Extensive base-code change, industry add-ons, EDI and warehouse connections, and a data estate that needs careful transformation rather than a lift.
We assess your NAV version, customizations, C/AL code, ISV add-ons, data, and integrations, then hand you a defined scope, a realistic timeline, and an implementation plan. You own the output whether or not we run the migration.
Tell us which NAV version you're running and roughly how customized it is. We'll walk through what your migration path looks like, what needs a decision, and how long a project like yours typically takes.
Everything you need to know about BrowseWise and AI-powered website assistance.
Not usually. For NAV 2015 through NAV 2018, Microsoft’s current supported upgrade path goes through Business Central 14 on-premises, then Business Central 25 or later on-premises, before moving to Business Central Online. The exact route depends on your NAV version and current environment.
Your existing C/AL customizations need to be reviewed and converted to the AL extension model used by modern Business Central. Some customizations may be rebuilt as extensions, some may be replaced by standard Business Central functionality, and others may no longer be necessary. Microsoft states that data from tables containing code customizations cannot simply be carried forward without addressing those customizations.
Not automatically. We assess every ISV add-on, integration, API, EDI connection, banking interface, warehouse connection, and other external dependency as part of the migration. Each one needs a decision based on its Business Central availability, upgrade path, replacement options, or retirement. This assessment helps identify compatibility issues before they affect your timeline or budget.
The answer depends on your migration strategy and the condition of your data. We review your master data, transactions, custom tables and fields, historical records, and reporting requirements, then determine what should be migrated, transformed, or archived. Microsoft also provides a Business Central 14 reimplementation path for scenarios where only essential data, such as master data, opening balances, setup, and selected historical information, needs to move forward.
There is no reliable single timeline for every NAV environment. A lightly customized system may take around 3–5 months, a moderately customized environment around 5–8 months, and a heavily customized or integration-intensive environment can take 8–12+ months. The biggest factors are C/AL customizations, ISV add-ons, integrations, data volume, historical data requirements, reports, workflows, and the number of companies involved.
Our fixed-scope NAV migration assessment reviews your NAV version, database and customizations, C/AL code, ISV add-ons, integrations, data, reports, workflows, security, and migration requirements. We then define the recommended upgrade path, key risks and dependencies, estimated timeline, scope, and planning considerations so you know what the migration involves before committing to the full project. Microsoft’s migration guidance similarly starts with assessing the current state, planning scope, validating prerequisites, and preparing the environment before the upgrade and cloud migration stages.
Still have questions? Our experts are here to help.
Talk to an Expert