Dynamics NAV end of support: Business Central or Odoo

Dynamics NAV end of support: what the January 2028 date means for your move

If you run Dynamics NAV and must choose your next platform, the deadline is now the main planning constraint. Microsoft's lifecycle page for Dynamics NAV 2018 lists mainstream support ending January 10, 2023 and extended support ending January 11, 2028 (Microsoft Lifecycle, Dynamics NAV 2018). NAV 2018 is the last NAV release, so the question is no longer whether to move but where. The two paths are the vendor path, Dynamics 365 Business Central online or on premises, and the open-source path, self-hosted Odoo or ERPNext, which means re-implementing your processes on a different product.

Business Central is the path with the smallest change in data model and terminology, and it is the one Microsoft designs its migration tooling around. The open-source path means new data structures, new configuration and new custom code. Neither path is cheap or fast by default, so the decision should rest on three factors: how deeply your NAV system is customized, how much data you must carry across, and how much in-house skill you have to run and extend a new platform. A heavily customized NAV estate with years of history usually weighs differently from a lightly extended one with a small chart of accounts.

Before you compare platforms, inventory your NAV customizations, reports, integrations and data volumes, and confirm which of them each candidate platform must reproduce. Ask Microsoft partners and open-source implementation firms to price the work from that same written inventory, and confirm current Business Central deployment options and licensing with Microsoft, since these change over time. For the open-source route, confirm the version and support window you will adopt, because Odoo and ERPNext each publish their own support schedules. Treat the January 2028 date as the hard stop for planning, and schedule the decision early enough to leave time for a parallel run and cutover.

What the NAV end-of-support deadline requires from your plan

Dynamics NAV 2018 leaves extended support on January 11, 2028, so the deadline sets the end date for every decision below. Each card is a planning requirement you set for your own organization, not a regulatory rule, and the cards depend on one another, so decide the target platform first.

Decide the target platform

Choose between Business Central online, Business Central on premises and a self-hosted open-source ERP before anything else is scheduled. Each option changes the data path, the customization model and the team you need. Write the decision down with the reasons, the owners and the approval date, so the migration plan has a fixed starting point. Confirm the Business Central deployment options with Microsoft's current documentation rather than relying on older internal notes.

Build a dated migration plan

Work backward from the extended support end date to set milestones for design, data extraction, test loads, parallel running and cutover. Include a freeze period for NAV changes and a fallback plan if testing slips. Ask every candidate partner for a written scope and timeline before work starts, and make the plan show who approves each gate.

Inventory NAV customizations and reports

List every table extension, page extension, codeunit, report, XMLport and integration that your business depends on, and mark each as keep, rebuild or retire. Rebuilding AL extensions as Odoo Python modules or ERPNext Frappe apps and server scripts is different work from a standard upgrade, so estimate it separately. Identify the reports users run monthly, because those are the first tests of any replacement.

Choose a data extraction method

Decide how ledgers, items, customers, vendors and open documents leave NAV or Business Central. For Business Central online, the BACPAC export has a monthly limit and requires a paid subscription, and Microsoft does not support restoring that file to a working on-premises environment. For NAV or on-premises SQL Server, query the database directly. Test the extraction on a copy and reconcile totals against the source before any load.

Plan the support model after go-live

Decide who fixes defects, applies upgrades and handles security patches once the new system is live. Odoo standard support covers the first three years after a major release, and ERPNext versions have their own end-of-life dates, so tie your upgrade cadence to those dates. Ask any implementation partner whether ongoing support is a retainer, what response times they commit to in writing, and who holds the admin credentials.

Decide licensing and hosting

Set the cost model for licenses, hosting, backup and staff before selecting a platform. Odoo Enterprise and its features such as Odoo Studio are paid, while ERPNext is free to self-host, and both vendors offer managed hosting at a fee. Confirm which Odoo edition includes the features your customizations need, and confirm with the vendor whether your hosting location meets your data residency requirements.

How each path meets the deadline in practice

Business Central online stores your data in the Microsoft cloud, and Microsoft runs the platform and applies updates on its release schedule. You do not schedule the upgrade itself, but you do own the extension rework that comes with each release. Your data leaves the NAV server you operate today, so the residency and access terms of the Microsoft cloud become part of your compliance file. Your exit path also depends on export. Online databases can be exported as BACPAC files to an Azure standard storage account, but only with a paid subscription and up to 10 times per month per environment, according to Microsoft Learn.

Data location: Records sit in the Microsoft cloud. Confirm the data region and who can administer the tenant with your cloud team.
Upgrades: Microsoft applies platform updates, so your NAV customizations must be reworked for the online model before cutover.
Exit export: Plan BACPAC exports within the monthly limit, and confirm the storage account setup before you need it.
On-premises restore: Microsoft does not support creating a working on-premises Business Central environment from an online BACPAC, so this tab is not a fallback for on-premises operation.
Before January 11, 2028: Complete data migration testing and user acceptance on the online tenant, and keep NAV running until cutover is signed off.

Confirm with Microsoft and your partner which features your NAV customizations need, and what the online tenant includes for your scope.

Which successor platform fits your NAV estate

This table compares the four realistic successors to Dynamics NAV 2018 after extended support ends on January 11, 2028. Read each row for how the option meets that date, then check the trade-offs against your customizations, hosting rules and upgrade capacity.

Option	How it meets the deadline	Trade-offs
Business Central online	Microsoft hosts and maintains the service, so the platform stays on a supported path.	Data is stored in the Microsoft cloud. Database exports need a paid subscription and are limited to 10 per month per environment.
Business Central on premises	Runs on your own servers, but must stay on a supported release wave to remain supported.	Microsoft does not support building an on-premises environment from an online BACPAC. Confirm wave end dates and your upgrade capacity.
Self-hosted Odoo (Community or Enterprise)	Community is LGPL-3.0 and free to self-host. Requires re-implementation, with NAV customizations rebuilt as Python modules.	Upgrade service and Odoo Studio need Enterprise. Each major version has three years of standard support, so plan upgrades regularly.
Self-hosted ERPNext	GPL-3.0 licensed and self-hosted with Docker or bench. Requires re-implementation, with customizations rebuilt as Frappe apps.	Version 15 is supported until the end of 2027 and version 16 until the end of 2029. Warranty needs a matching Frappe Cloud support plan. Server scripts are disabled by default from version 15.

How Dynamics NAV customizations carry over to each path

Before any path is priced, inventory every NAV customization and classify it as standard functionality, an extension to rebuild, or obsolete. Work from the object list in the NAV development environment: modified standard objects (tables, pages, reports, codeunits, XMLports), custom objects, event subscribers, integrations, and scheduled jobs. Standard functionality that Business Central already ships can usually be dropped. Obsolete items are usually reports nobody runs or fields nobody reads. Only the remainder carries cost to the next platform, and that remainder is the number that should drive the quote.

On Business Central, most customizations are rebuilt as AL extensions rather than edits to the base application, so the classification also tells you how much of the rework depends on Microsoft's release cadence. Online tenants receive the two yearly waves automatically, and on-premises deployments must stay current to remain supported, so each extension needs a compatibility check at every wave. On Odoo, customizations become Python modules that add models, views and business logic, and they are upgraded with the database through the upgrade service, which has to be tested on the upgraded test database before production. On ERPNext, customizations become Frappe apps or document-level customizations, and simple logic can sit in server scripts.

Server scripts need a specific check. From version 15, server scripts are disabled by default and must be enabled with the server_script_enabled setting, and Frappe Cloud public shared benches do not allow them at all. Any NAV logic you plan to recreate as a server script therefore needs a hosting decision first: a self-managed bench or Docker deployment where you control the setting, or a dedicated Frappe Cloud plan. Confirm each NAV customization against the target platform's own documentation, for example the Frappe server script documentation, before committing to a rebuild estimate.

Data migration risks that delay a NAV exit

Most NAV exits stall on data, not on features. The cards below cover the points where export limits, restore constraints and import volumes can push a cutover date, whichever target you choose. Confirm each one against your own NAV version and environment before you fix a timeline.

BACPAC export limits on Business Central online

If your data already sits in Business Central online, the BACPAC route is the most direct extract. Export requires a paid subscription, and each environment can export only 10 times per month. A failed or repeated extract can consume part of that allowance during a cutover rehearsal, so plan the number of test extracts before you start. Confirm which environments you control and who holds the administrator rights to run exports.

No on-premises restore from BACPAC

Microsoft does not support creating a working on-premises Business Central environment from a BACPAC exported from Business Central online. A BACPAC is therefore a data extract for migration tooling, not a fallback copy you can stand up on your own servers. Treat it as a one-way source file and confirm with your partner or Microsoft how the file will be read into your target.

Importing with External IDs

Odoo recommends External IDs when importing records from a third-party application. Without them, re-running an import can duplicate customers, vendors or items, and linked records such as invoices may point at the wrong parent. Map each NAV primary key to a stable external identifier before the first load, and keep that mapping as migration evidence for later reconciliation.

Batch size for ERPNext imports

ERPNext's Data Import documentation advises importing only a few thousand records at a time. Long ledgers and item histories therefore need to be split into ordered batches, with parent records such as customers and items loaded before transactions. Confirm the record counts per object in your NAV database early, because batch count drives the rehearsal schedule more than any other single factor.

Confirming how NAV data can be read

The supplied facts cover Business Central export paths but do not describe the export options of your NAV version. Whether your database can be read directly, through SQL Server tooling or through a vendor export, depends on your release and hosting. Ask your NAV partner to document the extraction method for each object, its supported format, and any licensing or access needs before you commit to a target.

Deploying Odoo or ERPNext before the NAV deadline

This sequence takes a NAV customer from choosing a target version to retiring NAV access, with each step producing a checkable result inside the client's own infrastructure.

Confirm target version and support window
Your project lead and the business owner choose the platform and version before any build work starts. For Odoo, compare the standard support window of each major version on the support documentation and note that Odoo SaaS versions are released every two to three months and cannot use extended support. For ERPNext, check the supported versions page and confirm that the chosen major version has a listed end date that falls after your go-live plan. Output: a signed version decision that names the support end date for the platform and version you are deploying. Ask the vendor or partner to confirm the date in writing, since support windows change between releases.
Build the test environment in your infrastructure
The infrastructure team provisions a non-production environment in your own cloud account, data center or air-gapped network. For Odoo, decide between the packaged on-premise installers and a source installation. For ERPNext, choose Docker Compose using the production images in the frappe_docker repository, the bench command line tool, or Frappe Cloud if hosting in your own infrastructure is not a requirement. Output: a running test instance reachable only by the project team, with backups scheduled and a documented host inventory. Keep the demo single-file Compose setup out of this environment, because its documentation marks it for short-lived evaluation only.
Configure database, licensing and authentication
Platform engineers set up PostgreSQL for Odoo or MariaDB or PostgreSQL for ERPNext, along with the mail, background worker and scheduler services. For Odoo on premises, Enterprise databases are activated with your subscription code, and a Community edition has no access to the upgrade service that moves a database to a newer supported version. Confirm this before you commit to Community, because on premises the upgrade path depends on the Enterprise subscription. Connect sign-in to your directory through the Odoo LDAP or ERPNext LDAP integration, or configure social login keys where your identity provider supports them. Output: a test instance where staff sign in with corporate credentials and a written licensing record.
Rebuild customizations and confirm server scripts
The development team maps each NAV customization, such as extensions, reports and posting logic, to an Odoo Python module or an ERPNext Frappe app, or to configuration where the standard application covers the need. For ERPNext, server scripts are disabled by default from version 15 and must be enabled with the server_script_enabled setting, and Frappe Cloud public shared benches do not allow them, so check this before relying on scripts. Output: a custom code register listing each item, its replacement and the owner who signed off, kept in version control.
Run a test migration in batches
The data team extracts NAV data from the on-premises SQL database into staging files, then imports master data such as customers, vendors and items. Odoo can import into any business object from Excel or CSV, and its documentation recommends External IDs when importing from a third-party application, so set those keys first. ERPNext's Data Import tool uses downloadable templates and its documentation advises importing a few thousand records at a time, so load in batches. Output: an import log for each object showing record counts that match the NAV source, with rejected rows documented and corrected.
Validate reconciliations and business processes
Finance staff reconcile balances, open items, inventory valuation and sales and purchase documents in the test environment against NAV reports for the same period. Users run their month-end and order-to-cash routines end to end, and integrations with other systems are tested against the new data model. Output: a signed reconciliation pack with each difference explained or fixed. Repeat the test migration until a full run produces clean reconciliations, and record the run times so cutover planning uses measured figures.
Schedule cutover and plan the upgrade cycle
The project board sets a cutover window, freezes NAV postings, runs the final data load and reconciles again before users go live. Plan the recurring upgrade cycle now: Odoo Online and Odoo.sh require major upgrades every two years, and an on-premise Enterprise subscription supports the upgrade service with an upgraded test database that should be tested before production. Output: a cutover runbook with a rollback point, and a dated upgrade calendar tied to the platform's support windows.
Retire NAV access and archive records
After the cutover is accepted, the infrastructure team removes user accounts and service connections to NAV, moves the NAV database to read-only archive storage, and documents where retained records live. Confirm with your compliance lead which records must remain accessible and for how long, since retention rules come from your own obligations. Output: a decommissioning record showing that NAV no longer accepts logins or integrations, a tested archive restore, and the owner who accepted the retirement.

Evidence auditors and finance reviewers ask for during a NAV exit

A NAV exit changes how the ledger is built, tested and controlled, so auditors will want records that show each step. The cards below cover the artifacts finance and audit teams typically request, who should hold each one, and what it proves.

Signed-off customization inventory

This is the list of every NAV object, report, codeunit, page and extension that the business relies on, with a decision for each: rebuild, replace with a standard feature, or retire. Finance and the process owners should sign it, and IT should keep the version under change control. Auditors use it to confirm that no posting logic moved to the new system without review. Check that the inventory covers reports used for statutory or tax output, not only screens.

Data reconciliation between NAV and target

Reconciliation shows that opening balances, open items, item quantities and master records in the new system match NAV at a stated cut-off. Finance should hold the signed trial balance comparison, subledger tie-outs and exception logs with a reason for each difference. Load in batches and keep the import files, since the Data Import tools in ERPNext and Odoo accept CSV or Excel and are typically used in controlled batches. Record who approved each difference.

Test database and neutralization record

Any test copy of production data must be documented with its creation date, source backup, who accessed it and when it was neutralized. Neutralization removes outbound email, payment connectors and live integrations so a test copy cannot send money or messages. Odoo documents database duplication with neutralization for test copies. Keep the log with IT security, and confirm the target platform's neutralization steps in its own documentation before the first test load.

Access and role configuration

Auditors will ask who can post, approve, change master data and administer the system, and whether segregation of duties holds in the new roles. Export role and permission definitions from both NAV and the target, map each NAV permission set to a target role, and keep the mapping signed by the controller. If you connect the target to a directory, record the LDAP or social login configuration, since sign-in controls then depend on it. Review access before cutover and again after the first close.

Version and support status record

Keep a dated record of the platform version in use, its support end date, and the upgrade path. Odoo publishes standard support windows per major version, and ERPNext and Frappe publish supported versions with end-of-life dates. Frappe warranty coverage depends on running a listed version with a matching support plan. IT should own this record and review it at each release, so the organization is never running an unsupported ledger without a documented decision.

Cutover and NAV archive plan

The cutover plan records the freeze time, the final NAV backup, the last posting date, and who signs off go-live. The archive plan states where the final NAV database and reports are kept, for how long, who may access them, and how they can be restored for an audit request after NAV is switched off. Confirm the retention period with your auditors and legal team before decommissioning. Test that archived data can still be read.

Questions NAV customers ask before choosing a successor

How much time is left before Dynamics NAV 2018 support ends?

Extended support for Dynamics NAV 2018 ends on January 11, 2028, and mainstream support ended on January 10, 2023, so the remaining window is shorter than it looks. Work backward from that date. A migration needs a written scope, an inventory of customizations, reports and integrations, a data extraction plan, a mapping of the chart of accounts and dimensions, at least one full test migration, a parallel run period and a cutover date agreed with finance. Each step depends on the one before it, so the start date matters more than the end date. Confirm the support terms in your own agreement with Microsoft or your partner, because obligations can differ by contract.

What drives the cost of moving to Business Central versus Odoo or ERPNext?

The total depends on five components, and each is paid to a different party:

Licenses: Business Central is a per-user subscription sold through Microsoft partners. ERPNext is GPL-3.0 licensed, and self-hosting it is free according to its pricing page. Confirm current Odoo Enterprise terms on the Odoo pricing page.
Hosting: Business Central online runs in Microsoft's cloud. Self-hosting Odoo or ERPNext means your cloud or data center charges plus the staff who operate it.
Customization rebuild: AL extensions, Odoo Python modules or Frappe apps must be written again.
Data work and testing: extraction, mapping, cleansing and repeated test loads.
Support: partner services and internal operations.

Licenses and hosting recur. Rebuild, migration and testing are mostly one-time. Ask every bidder for these five lines in writing.

Can our in-house team move NAV to an open-source ERP alone?

Some teams can carry part of the work internally, but a full NAV exit usually needs skills in the target platform, data migration, integration and testing at the same time. Assess your team against those areas before deciding. Your NAV developers know the business logic, which is valuable for the functional design, while the target platform may need Python, Frappe or Odoo module skills and database work. Plan for a period of parallel running, and make sure someone owns backups, upgrades and security patches after go-live. DeployOpen plans, implements, customizes, integrates, backs up, upgrades and supports self-hosted open-source platforms inside your own infrastructure. It can deliver the whole migration under a fixed scope or support specific parts alongside your team.

What should we ask a partner for in a fixed-scope ERP migration quote?

Ask for a quote that lists deliverables, exclusions and assumptions in writing before work starts. Useful items to request include:

An inventory of NAV objects, reports, interfaces and customizations, with a classification of which ones are retired, rebuilt or replaced by standard features.
Data entities in scope, expected record volumes and the source of the extraction.
The number of test migrations, the user acceptance process and the cutover plan.
Hardening, backup and restore testing for the self-hosted environment.
Documentation, training and handover of code and configuration.
Post-go-live support terms, including upgrade planning for the target version.

DeployOpen engagements are typically fixed-scope, with scope and timelines agreed in writing. It does not publish a price list, so a quote follows from the written scope.

Can NAV customizations be carried over to the new platform unchanged?

No customization moves across unchanged. Each platform has its own extension model, so every custom object, report and integration must be redesigned, rebuilt or dropped. Business Central uses AL extensions, Odoo uses Python modules, and ERPNext uses Frappe apps or server scripts. In ERPNext, server scripts are disabled by default from version 15 and must be enabled with the server_script_enabled setting, and Frappe Cloud public shared benches do not allow them. Odoo Studio appears only in the Custom plan on the pricing page, so check that feature list before relying on it. Business Central BACPAC exports cannot create a working on-premises environment, so they serve as a data source, not as a way to keep the custom code.

How long does Odoo and ERPNext support last after a version ships?

Odoo provides three years of standard support for each major version, followed by two more years to complete the upgrade, according to Odoo's documentation. Standard support includes security updates and bug fixes, and paid extended support is limited to Odoo.sh for select versions and on-premise. Security patches come only during standard support. On Odoo Online and Odoo.sh, major upgrades are mandatory every two years. For ERPNext, version 15 is supported until the end of 2027 and version 16 until the end of 2029, and version 14 reached end of life on January 31, 2026. Frappe warranty coverage requires running a listed version and a matching Frappe Cloud support plan. Self-hosted operators still need to plan their own patching and upgrades.

What data can we extract from NAV for an Odoo or ERPNext import?

Start by confirming your NAV database platform and the export method your team can run, then decide which entities to move. Odoo can import data into any business object from Excel (.xlsx) or CSV files, and its documentation recommends External IDs when importing from a third-party application, so keep the NAV keys as External IDs to support later reconciliation. ERPNext's Data Import tool loads records from CSV or Excel using downloadable templates, supports child table rows, and its documentation advises importing a few thousand records at a time, so plan batches for large ledgers. Business Central online databases can be exported as BACPAC files only with a paid subscription and up to 10 times per month per environment, which is relevant if you pass through Business Central first.

How DeployOpen plans and deploys a NAV exit

DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For Dynamics NAV end of support, that means starting from an inventory of the NAV customizations and data that must survive the move, then agreeing in writing where the work lands on Odoo or ERPNext.

How we scope

Inventory NAV customizations, reports, integrations and data sets that the new platform must carry over.
Confirm the target path in writing, whether that is Odoo, ERPNext or an upgrade decision for Business Central.
Engagements are fixed-scope, with deliverables and timelines agreed before any work starts.

How we build

Map NAV customizations to Odoo Python modules or Frappe apps and server scripts, with tests for each rebuilt item.
Load master data and balances through staged test imports, reconciling totals against the NAV source at each run.
Configure authentication, backups and hardening in your own cloud, data center or air-gapped network.

How we hand over

Deliver architecture, configuration and runbook documentation covering installation, upgrades and backups.
Run user acceptance and cutover rehearsals, with reconciliation evidence kept for your finance and audit teams.
Confirm with your auditors which control evidence they expect, since DeployOpen prepares evidence but does not issue audit reports.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Plan version upgrades against the vendor's published support windows, testing each upgraded copy before production.
Ask any quote to name who maintains the platform after cutover and how security patches reach your environment.