Microsoft NAV to Business Central Migration: The Complete Step-by-Step Guide (2025)
Microsoft Dynamics NAV has been a workhorse ERP for thousands of businesses across the GCC for over two decades. But Microsoft has officially shifted its investment to Business Central — and mainstream support for older NAV versions has ended or is ending. The question is no longer whether to migrate, but how to do it without disrupting the business operations that depend on NAV every day. This guide walks you through the real process: what changed, how to prepare, and how to navigate the migration without the costly mistakes most companies make.
NAV vs Business Central — What Actually Changed
Business Central is not simply a rebranded NAV. Microsoft rebuilt significant parts of the platform. If you're expecting a simple database upgrade, you'll be surprised. Here's what's genuinely different:
The shift to AL extensions is the most operationally significant change. In NAV, developers modified base application objects directly — which meant every upgrade required a merge of customisations with Microsoft's new code, a laborious and expensive process. In BC, customisations are extensions that don't touch the base application. This changes the economics of upgrades permanently.
Before You Start — Pre-Migration Assessment Checklist
The businesses that run into trouble during NAV-to-BC migration are almost always the ones that skipped proper assessment. Before any migration work begins, complete this checklist:
Customisation Audit
Document every C/AL modification made to your NAV installation. Which are business-critical? Which were workarounds that BC now handles natively? Which can be retired? This audit determines how much AL extension development your migration requires.
Data Quality Assessment
Review the state of your master data: customers, vendors, items, chart of accounts, open transactions. Old NAV installations often have years of duplicates, inactive records, and inconsistent coding. Migration is the best opportunity to clean this — but only if you plan for it.
Integrations Map
List every system that connects to NAV: banking portals, e-commerce, CRM, payroll, WMS, third-party logistics. Each integration needs to be re-evaluated — some will be replaced by native BC capabilities, others will need new API connectors.
User Count & License Planning
Map your current NAV users to BC license tiers (Essentials, Premium, Team Members). This is often an opportunity to reduce license cost — some NAV full users only need Team Member access in BC.
Go-Live Timeline Planning
Identify blackout periods: fiscal year ends, peak trading seasons (e.g. Ramadan, Q4), regulatory filing deadlines. Plan your go-live for a low-activity window with at least two weeks of buffer either side.
Training Plan
BC's UI is meaningfully different from NAV's. Plan role-based training for all user groups — not just a generic system demo. Power users and administrators need additional sessions on the new tools and workflows.
Step-by-Step Migration Process
Every migration is different in its specifics, but the structure of a well-run NAV-to-BC migration follows five phases. Here's what each entails:
-
Discovery & Scoping
The partner works with your team to produce a Business Requirements Document (BRD) mapping your current NAV workflows to BC equivalents. Gaps are identified where custom AL development is needed. Integrations are catalogued. A fixed-price or time-and-materials project plan is produced with milestones, deliverables, and sign-off criteria.
-
Data Migration & Cleansing
Microsoft's Data Migration Cloud Extension (or RapidStart) is used to extract data from NAV. Before import, data is validated and cleansed — duplicates removed, mandatory fields populated, coding standardised. A test migration is run to surface issues before they become live problems. Expect this phase to surface data issues that no one knew existed.
-
Customisation Rebuild as AL Extensions
C/AL customisations from NAV cannot be imported directly into BC. They must be re-built in AL — the modern Business Central development language. This is not a translation; it's often a rebuild with improved architecture. BC's base application covers many things NAV needed custom code for, which means some customisations can be retired entirely.
-
User Acceptance Testing (UAT)
Key users from each department test the migrated BC environment against defined test scripts. This is not an IT task — it requires the finance team testing financial workflows, the warehouse team testing inventory flows, and so on. Issues found in UAT are fixed before go-live. A parallel run (running NAV and BC simultaneously for a defined period) may be planned for critical processes.
-
Go-Live & Hypercare
On go-live day, NAV is decommissioned (or set to read-only) and BC becomes the system of record. The hypercare period — typically 2–4 weeks — means your implementation partner has dedicated support resources available to resolve issues immediately. This is not standard post-project support; it's intensive availability during the highest-risk period.
Common Migration Mistakes to Avoid
Moving old customisations as-is
The temptation is to rebuild every NAV customisation in BC exactly as it was. Resist it. Many NAV customisations exist because the platform didn't support certain things natively — BC often does. Migrating outdated workarounds creates technical debt from day one.
Skipping data cleansing
Migrating 10 years of accumulated NAV data without cleansing is one of the most common and costly mistakes. Bad data in NAV becomes bad data in BC — and it degrades reporting, complicates reconciliation, and frustrates users from day one.
Underestimating the training requirement
"Users who know NAV will need genuine training on BC — the navigation model, the role centre concept, the Power BI integration, and the mobile experience are all different. "They'll figure it out" is a phrase we hear before every troubled go-live.
No rollback plan
What happens if a critical issue appears on go-live day? A rollback plan — a defined process to revert to NAV for a short period while issues are resolved — should be agreed and documented before go-live. It is rarely needed, but its absence turns a minor crisis into a major one.
Treating migration as a purely technical project
Migration touches every team in the business. Finance workflows change. Approval processes change. Reports look different. Users who feel excluded from the project become resistant to the new system. Involving department heads in UAT and change management is not optional.
How Long Does a NAV to BC Migration Take?
| Migration Profile | Estimated Timeline | Key Factors |
|---|---|---|
| Simple NAV (few customisations, clean data, 5–15 users) | 6–10 weeks | Mostly configuration, minimal AL development, light data migration |
| Mid-complexity (moderate customisations, some integrations, 15–40 users) | 3–5 months | AL extension rebuild, integration re-work, full UAT cycle |
| Complex NAV (heavy C/AL modifications, multiple integrations, 40+ users, manufacturing or WMS) | 6–12 months | Significant AL development, multi-phase data migration, parallel run period |
How Much Does NAV to BC Migration Cost?
Migration cost is driven by two primary factors: the volume of AL extension development required (i.e., how many NAV customisations need to be rebuilt), and the complexity of your data migration. Partner day rates in the UAE typically range from AED 1,200 to AED 2,500 per consultant day depending on experience level and specialisation.
| Migration Complexity | Estimated Cost Range (AED) |
|---|---|
| Simple (minimal customisations) | AED 30,000 – 70,000 |
| Mid-complexity | AED 80,000 – 200,000 |
| Complex (heavy customisations + integrations) | AED 250,000 – 500,000+ |
Note that these ranges exclude your new BC license costs, which begin from the date your subscription starts. Work with your partner to time your license activation relative to your go-live date.
Start Your Migration the Right Way
A successful NAV-to-BC migration is achievable — we've delivered them for businesses across UAE, KSA, and Qatar of every size and complexity level. The common thread in every successful project is early investment in assessment and planning. The pre-migration assessment phase costs a fraction of the total project, but it determines whether the rest of the project succeeds or spirals.
If you're still on NAV and thinking about when and how to move to Business Central, the best first step is a structured assessment of your current NAV environment. It takes a few days, produces a clear scope and cost estimate, and gives you everything you need to make an informed decision.