News & Insights / Dynamics NAV 2016 migration options

Dynamics NAV 2016 Support Has Ended: Migration Options for Australian Organisations

Microsoft Dynamics NAV 2016 reached the end of extended support on 14 April 2026. Mainstream support had already ended on 13 April 2021. An existing NAV system may continue to run, but Microsoft no longer provides the normal security updates, non-security updates or assisted support that were available during the product lifecycle.

For an Australian organisation still using NAV 2016, the immediate task is not to rush into a technical conversion. It is to understand the current risk, stabilise critical operations and choose between an upgrade-led migration and a process-led reimplementation.

What does the end of NAV 2016 support mean?

End of support does not mean NAV 2016 stops opening on the lifecycle date. It means the safety net around the product has changed.

After extended support ends, an organisation should expect:

This is a lifecycle risk, not proof that every NAV 2016 environment is already unsafe or unusable. The actual exposure depends on architecture, network access, custom code, authentication, integrations, infrastructure, backup quality and operational controls.

The first actions to take now

Before deciding on a future platform, document what must be protected today.

Confirm the exact application and platform versions

Record the NAV build, cumulative update, SQL Server version, Windows Server version, authentication method and important third-party components. One unsupported dependency can affect the plan even if another component remains supported.

Verify backups and recovery

Confirm that database and application backups complete successfully and can be restored. 

Map external access and integrations

Identify web services, remote access, ecommerce, banking, payroll, warehouse, EDI, reporting and customer or supplier portals connected to NAV. Include integrations that depend on exported files or scheduled jobs, not only APIs.

Freeze unnecessary customisation

Avoid adding more legacy code unless it addresses an urgent operational or security need. Every new modification can increase discovery, conversion and testing effort later.

Assign an accountable owner and target date

Treat the replacement decision as a business programme with an executive owner, not an open-ended IT maintenance issue.

Three realistic migration paths

Option 1: Stabilise NAV 2016 while preparing the transition

A short stabilisation period can be appropriate when the organisation cannot move immediately. Work may include reducing exposure, confirming recovery, documenting integrations, resolving critical data issues and defining a funded roadmap.

This is a bridge, not a long-term product strategy. Its value is measured by how safely and quickly it enables the next step.

Option 2: Upgrade and migrate with greater functional continuity

An upgrade-led route aims to retain more historical data, established processes and proven functionality. Microsoft's migration guidance explains that older Dynamics NAV environments first need to be upgraded to a supported Business Central on-premises path before data is moved to Business Central online. For NAV customisations written in C/AL, conversion to the Business Central extension model also needs to be assessed.

This route may suit an organisation when:

Continuity is not the same as simplicity. A technically complex legacy estate can make a full upgrade more expensive and harder to test than a selective reimplementation.

Option 3: Reimplement Business Central around current requirements

A reimplementation starts with present-day processes and moves selected master data, opening balances and required history rather than reproducing every legacy object. Historical NAV data can be retained in a read-only archive or reporting store where appropriate.

This route may suit an organisation when:

A reimplementation should not be confused with simply starting from an empty database. Data retention, audit access, reconciliation and cutover still require a governed plan.

Upgrade or reimplementation: a decision matrix

The final choice can also be hybrid. For example, an organisation may preserve selected financial history while redesigning inventory, warehousing or approval workflows.

What should a NAV 2016 assessment include?

A useful assessment produces evidence for a decision rather than a generic recommendation. It should cover:

  1. Business scope: legal entities, locations, currencies, tax, reporting and critical periods.
  2. Process map: order-to-cash, procure-to-pay, inventory, projects, manufacturing or service workflows in use.
  3. Object inventory: standard, modified and bespoke NAV objects, reports and job queue tasks.
  4. Extension inventory: add-ons, vertical solutions and dependencies with their current support status.
  5. Integration map: system owners, data direction, frequency, failure handling and replacement plans.
  6. Data profile: record volumes, duplicates, inactive records, dimensions, open transactions and retention needs.
  7. Security review: users, permissions, service accounts, remote access and segregation of duties.
  8. Infrastructure review: servers, SQL, identity, backup, monitoring and disaster recovery.
  9. Future requirements: capabilities the organisation needs over the next three to five years.
  10. Options and estimate: assumptions, exclusions, risks, timeline and a recommended proof-of-concept or migration rehearsal.

A practical migration sequence

Phase 1: Discovery and option selection

Confirm the current estate, business priorities and non-negotiable controls. Compare the upgrade, reimplementation and hybrid paths using the same criteria.

Phase 2: Solution and data design

Define the target companies, dimensions, posting setup, permissions, extensions, integrations, reporting and data-retention approach. Decide what will be migrated, transformed, archived or retired.

Phase 3: Build and migration rehearsal

Configure the target environment, develop only the required extensions and run a representative data migration. Reconcile balances and transaction counts before user acceptance testing begins.

Phase 4: End-to-end testing

Test complete business scenarios with migrated data, integrations, permissions and reports. Include month-end or year-end activities where they are in scope, plus failure and recovery scenarios.

Phase 5: Cutover and go-live

Set a data freeze, migration runbook, reconciliation owners, go/no-go criteria and rollback or contingency plan. Make support contacts and escalation paths clear to every affected team.

Phase 6: Stabilisation and optimisation

Monitor errors, adoption, processing time and outstanding workarounds. Decommission the old environment only after data access, audit retention and recovery responsibilities are formally accepted.

Risks that are easy to underestimate

Rebuilding every customisation

A legacy modification should earn its place in the target system. Ask which regulatory, customer or operational requirement it satisfies and whether standard capability or a supported extension now covers the need.

Moving data without ownership

Technical teams can extract records, but business owners need to decide which records are correct, active and legally required. Data cleansing cannot be delegated entirely to the migration script.

Testing only individual functions

A posted sales invoice may work while the complete order, warehouse, shipment, invoice, payment and reporting process fails. Test end-to-end scenarios across teams and systems.

Ignoring the old-system archive

Define who can access historical NAV information, how it is protected, how long it is retained and how an audit request will be answered after go-live.

Treating training as a final-week activity

Role-based training should use realistic data and processes. Super users need time to practise exceptions and support colleagues before the cutover.

Frequently asked questions

When did Dynamics NAV 2016 support end?

Microsoft lists the end of mainstream support as 13 April 2021 and the end of extended support as 14 April 2026.

Will NAV 2016 stop working after the support date?

Not automatically. An installed system may continue to operate, but Microsoft no longer provides the normal security and non-security updates or assisted support for that product version. Compatibility and operational risk can increase over time.

Can NAV 2016 move directly to Business Central online?

Microsoft's documented route requires older NAV data to be upgraded through a supported Business Central on-premises path before cloud migration. The exact route depends on the source version, customisations, extensions and the chosen data strategy.

Do we have to migrate all historical data?

No. Depending on legal, audit and operational needs, an organisation may migrate full history, selected history or essential master data and balances while retaining older information in a controlled archive.

Is an upgrade always cheaper than reimplementation?

No. The cost depends on custom code, data quality, integrations, process change, history requirements and testing. A discovery assessment is needed before either path can be compared fairly.

How long can we safely stay on NAV 2016?

There is no universal safe period. Risk depends on the environment and controls. The organisation should document the exposure, apply compensating measures where possible and approve a time-bound transition plan.

Next step

Create an evidence-based inventory of the NAV environment before requesting a fixed migration proposal. Dynamic Aspect can help assess the current estate and map it to Dynamics 365 Business Central. Contact the team to discuss the next step.

Official Microsoft resources