Migrating from Dynamics NAV to Business Central: A Malaysian Business's Timeline

How-to guide

Why the migration conversation is happening now

Many Malaysian businesses running Dynamics NAV have treated the system as a fixture — stable, familiar, and "not broken." That calculus is changing. According to Microsoft's official Product Lifecycle documentation, Dynamics NAV 2018, the final release of Dynamics NAV before the product line was renamed and rearchitected as Dynamics 365 Business Central, has an Extended Support end date of 11 January 2028. Earlier NAV releases reach the end of their support windows sooner: Dynamics NAV 2017 support ends in January 2027, and versions before that have already passed end of support entirely.

Once Extended Support ends, Microsoft stops issuing security updates, non-security updates, and technical support for the product, regardless of the underlying database or operating system it runs on. For a finance system that touches banking, payroll, tax reporting, and customer records, running an unsupported platform is a business risk that compounds quietly — it does not usually cause an immediate failure, but it removes the safety net for the day something does go wrong.

For Malaysian organisations specifically, there is a second, more immediate driver alongside the support deadline: Malaysia's MyInvois e-invoicing mandate under the Inland Revenue Board (LHDN) is being phased in by annual turnover threshold, with the lower-threshold bands (businesses with turnover between RM1 million and RM5 million) brought into scope from 1 January 2026. Sales and Service Tax (SST) reporting obligations continue alongside this. Dynamics NAV was never built with Malaysia's e-invoicing model in mind, and older NAV environments generally rely on manual workarounds, spreadsheet bridges, or bolt-on tools to approximate compliance. Migrating to Business Central does not automatically solve this — Malaysia is a partner-led localisation market for Business Central, meaning MyInvois and SST functionality is delivered through local partner extensions rather than a Microsoft-built module — but it does give a business a modern extension framework capable of supporting that localisation properly, rather than layering more workarounds onto an ageing C/AL codebase.

Understanding the migration path

Moving from Dynamics NAV to Dynamics 365 Business Central is not a simple version upgrade. Microsoft's migration documentation sets out a structured path with several distinct workstreams that a Malaysian business should understand before committing to a timeline.

1. Assessment

The first step is a proper assessment of the current NAV environment: which version is in use, how much custom C/AL code exists, which third-party add-ons (ISV solutions) are installed, how large the database is, and which integrations depend on the current system. This assessment determines almost everything about the shape of the project that follows — a lightly customised NAV environment migrates very differently to one with years of accumulated bespoke code.

2. Customisation and extension conversion

This is typically the most substantial phase of a NAV-to-Business-Central migration. Business Central online runs on an extension model only — all custom C/AL code must be converted into AL extensions before the business can move to the cloud, and data held in tables with code customisations cannot be carried forward unless those customisations are handled by extensions installed on both the on-premises and online environments. Microsoft's customisation migration guidance recommends a structured workstream: inventory and classify every modified object and ISV add-on, separate data-carrying customisations from behaviour-only changes, build an extension roadmap, pilot the conversion on a representative subset of objects, and run regression testing with business users before freezing further C/AL development ahead of cutover.

For businesses where full extension conversion is not practical in the short term, Microsoft also offers a Business Central 14 reimplementation path, which migrates essential master data, opening balances, and setup without requiring extension conversion — though it does not carry forward historical transactions or legacy customisations. This is a meaningful trade-off worth discussing early, not something to default into under time pressure.

3. Data migration and cloud versus on-premises decision

Once customisations are handled, the business chooses its target: Business Central online (Microsoft-hosted, cloud-based) or Business Central on-premises (self-hosted, similar deployment model to NAV). For most Malaysian small and mid-sized businesses, Business Central online is the more common target, as it removes the burden of server maintenance and keeps the environment on Microsoft's regular update cadence. Migrating to Business Central online follows a six-phase roadmap: preparation and prerequisite validation, upgrade to a supported Business Central on-premises version as an intermediate step, cloud migration setup (configuring the connection and Integration Runtime between the on-premises database and the online tenant), data replication through Azure Data Factory, a final data upgrade and cutover, and post-migration follow-up to reconnect integrations and monitor the new environment.

Businesses that need to remain on-premises for regulatory, data-residency, or integration reasons can still upgrade from NAV to a supported Business Central on-premises version and gain access to current security updates, without moving to the cloud immediately.

A realistic timeline for a Malaysian business

Every migration timeline depends on database size, the volume of custom code, and how many companies or entities are involved, but a Malaysian small to mid-sized business with a moderately customised NAV environment can generally expect a project shaped roughly like this:

Assessment and scoping (2–4 weeks): Cataloguing customisations, ISV add-ons, integrations, and data volume; deciding between full migration and reimplementation; agreeing the cloud or on-premises target.
Customisation and extension conversion (6–16 weeks): The widest range in the whole project, driven almost entirely by how much C/AL code exists. A business with minimal customisation may clear this quickly; one with years of bespoke development, especially around Malaysian tax or reporting workarounds, should expect this to be the longest phase.
Localisation and MyInvois/SST readiness review (2–4 weeks, can run in parallel): Confirming which Malaysia-specific extensions are needed for e-invoicing and SST reporting, and validating that any locally customised tax or regulatory logic has been correctly converted.
Data preparation and dry-run migration (2–4 weeks): Cleaning historical data, archiving what does not need to move, and running at least one full dry run in a sandbox environment, as Microsoft's guidance recommends, before committing to the production cutover.
Cutover and go-live (1–2 weeks): Final data replication, validation against the sandbox results, user access setup, and reconnection of integrations.
Post-migration stabilisation (2–4 weeks): Monitoring, addressing issues that only surface under live use, and user support as the team adjusts to the new interface and workflows.

Taken together, a business with a moderate NAV customisation footprint should plan for a project in the range of three to six months from the start of assessment to a stable go-live. Businesses with heavier customisation, multiple entities, or complex integrations should plan toward the longer end of that range, or beyond it. The point of stating a range rather than a fixed number is that the extension-conversion phase genuinely varies this much in practice — a firm date should only be set once the assessment phase is complete.

Malaysian localisation: MyInvois and SST as migration drivers, not afterthoughts

For Malaysian businesses, the migration business case is strongest when it treats regulatory readiness as a first-class requirement rather than something to bolt on after go-live. Two areas deserve explicit attention in the assessment phase:

MyInvois e-invoicing: LHDN's e-invoicing mandate is being phased in by annual turnover, with lower-threshold businesses brought into scope through 2026. A business assessing its NAV environment should confirm, as part of the same project, how e-invoice generation, transmission, and the required data fields will be handled in the new Business Central environment — typically through a local partner extension built for the Malaysian market, since Business Central's Malaysia coverage is delivered through partner-led localisation rather than a built-in Microsoft module.
SST reporting: Sales and Service Tax obligations continue to require accurate tax coding, registration number management, and reporting output. This should be validated as part of the customisation-conversion workstream, particularly where the NAV environment has custom SST logic that needs to be re-expressed as an AL extension rather than lost in the migration.

Building these requirements into the assessment and extension-conversion phases — rather than treating them as a separate project after go-live — avoids the common pattern of a technically successful migration that still leaves the business patching together compliance workarounds.

Risks, and how to de-risk the migration

A NAV-to-Business-Central migration carries genuine risk if it is rushed or under-scoped. The main risk areas, and the corresponding mitigations drawn from Microsoft's own migration guidance, are:

Data loss from unconverted customisations. Data in tables with code customisations cannot be carried forward unless those customisations are converted to extensions installed on both environments. Mitigation: complete the inventory and classification step properly before estimating a timeline, and treat data-carrying customisations as a priority in the conversion roadmap.
Breaking schema changes. Removing or renaming fields during conversion can prevent extension synchronisation and cause data loss. Mitigation: plan schema changes carefully and test synchronisation in a sandbox before cutover.
Underestimating the customisation-conversion effort. This is the phase most likely to run long, particularly where customisations were built incrementally over many years without documentation. Mitigation: run a pilot conversion on a representative subset of objects early, to get a realistic effort estimate before committing to a full project timeline.
Skipping the dry run. Moving straight to a production cutover without a full sandbox rehearsal increases the risk of surprises during go-live. Mitigation: Microsoft's own guidance recommends at least one full dry run in a sandbox environment before the production migration.
Treating Malaysian localisation as separate from the core project. Leaving MyInvois and SST readiness until after go-live risks a second disruptive project shortly after the first. Mitigation: scope localisation requirements alongside the core assessment, not after it.

How SCSB helps

SCSB provides Dynamics 365 Business Central implementation services for Malaysian organisations, including assessment of existing Dynamics NAV environments, planning the customisation-conversion workstream, and coordinating the cloud or on-premises migration path in line with Microsoft's documented migration process. Our team works with Malaysian businesses to align the migration timeline with practical business constraints, and to scope MyInvois and SST readiness as part of the same project rather than as a follow-on exercise.

If your organisation is running Dynamics NAV and has not yet assessed its migration path to Dynamics 365 Business Central, request a consultation with SCSB to discuss your environment and a realistic project timeline.

Microsoft, Dynamics NAV, Dynamics 365 Business Central, and other Microsoft products referenced are trademarks of the Microsoft group of companies.

Sources: Microsoft Product Lifecycle documentation (Dynamics NAV 2018, Dynamics NAV 2017); Microsoft Learn, "Migrate Dynamics NAV to Business Central online"; Microsoft Learn, "Customization migration guide: Dynamics NAV to Business Central Online"; Lembaga Hasil Dalam Negeri Malaysia (LHDN) MyInvois e-invoicing guidance.

Last updated: July 2026