Australian planning guide
NAV to Business Central Migration Cost and Timeline in Australia
Plan a Dynamics NAV to Business Central migration budget and timeline in Australia, including licences, data, AL extensions, testing, GST, and cutover.
What to take from this guide
- Separate recurring licences and apps from one-off implementation and internal effort.
- Do not accept a fixed cost or go-live promise before version, code, data, and integration discovery.
- Build the schedule around evidence-based gates, migration rehearsals, UAT, and operational constraints.
- Make Australian GST, banking, reporting, business-calendar, and support requirements explicit.
Cost model
What a credible migration budget includes
A useful budget separates recurring Microsoft or app subscriptions from one-off delivery work and the customer effort needed to make decisions. Treating those as one headline price makes comparisons difficult and leaves important exclusions hidden.
| Budget layer | What to count | Evidence needed |
|---|---|---|
| Business Central licences | The correct mix of Essentials, Premium, Team Members, device, or other applicable licence types, plus the agreed billing term. | Named user roles, required capabilities, environments, and Microsoft's current Australian pricing and licensing terms. |
| Discovery and solution design | Process workshops, fit-to-standard decisions, architecture, scope boundaries, estimates, and the delivery plan. | Process owners, current pain points, statutory needs, integrations, reports, and agreed acceptance criteria. |
| Technical upgrade path | Any supported intermediate NAV or Business Central versions, database work, infrastructure, and specialist upgrade steps. | Exact NAV release and cumulative update, SQL details, localisation, object inventory, database size, and target release. |
| Customisations and apps | Retaining, replacing, redesigning, converting, testing, or retiring C/AL modifications and third-party products. | Object deltas, source access, licences, vendor support status, usage evidence, and a decision for every custom feature. |
| Data migration | Extraction, cleansing, mapping, transformation, trial loads, reconciliation, attachments, history, and final cutover load. | Companies, record counts, history depth, data quality, retention obligations, opening-balance rules, and reconciliation owners. |
| Integrations and reporting | Interfaces, APIs, files, EDI, bank or payment processes, warehouse devices, ecommerce, analytics, and document outputs. | An owner, specification, credential plan, test endpoint, volume profile, failure handling, and support model for each interface. |
| Adoption and cutover | Training, user acceptance testing, rehearsals, change communications, go-live support, and an agreed hypercare window. | Available subject-matter experts, test scripts, sign-off authority, blackout dates, roster coverage, and rollback criteria. |
| Ongoing operation | Support, app subscriptions, storage or capacity, monitoring, release management, and future enhancement capacity. | A post-go-live ownership model, service levels, update policy, vendor responsibilities, and approved operating budget. |
Estimate quality
Why there is no honest universal migration price
Two businesses with the same NAV version and user count can have very different delivery scope. The estimate changes when evidence changes, so the assumptions and exclusions matter as much as the number.
Starting version and build
Older NAV releases can require supported intermediate upgrade steps before a full migration to Business Central online. The exact cumulative update and database state can also constrain the route.
- Record the full product version and cumulative update.
- Confirm database and operating-system prerequisites.
- Validate the path against Microsoft's current compatibility guidance.
Customisation footprint
Object count alone is not a reliable effort measure. A small modification in posting, pricing, costing, or warehousing can carry more risk than many unused reports.
- Compare modified objects with the relevant standard application.
- Trace each modification to a current business requirement.
- Decide retain, replace, redesign, or retire before estimating build.
Data and company scope
More companies, poor master data, bespoke fields, attachments, or a requirement for deep transactional history add mapping, load, reconciliation, and rehearsal effort.
- Measure records and database size rather than guessing.
- Separate operational history from data kept only for reference.
- Assign business owners to reconciliation and sign-off.
Operational dependencies
Interfaces, labels, scanners, ecommerce, EDI, bank files, external payroll, reporting, and peak trading periods can drive both build effort and the safe cutover window.
- Inventory every inbound and outbound dependency.
- Include third-party vendor lead times and test access.
- Define failure recovery and support ownership before go-live.
Schedule model
Build the timeline from evidence and exit gates
A migration plan is more reliable when each phase produces evidence that permits the next one to start. Calendar dates should follow the scope, resource plan, rehearsals, and business constraints—not replace them.
| Phase | Primary output | Exit evidence |
|---|---|---|
| 1. Readiness baseline | Confirmed version, companies, users, data volumes, customisations, integrations, constraints, and decision-makers. | The inventory is complete enough to select and estimate a migration approach. |
| 2. Discovery and fit-to-standard | Documented future processes, gaps, controls, app decisions, data scope, and non-functional needs. | Business owners approve requirements, exclusions, priorities, and acceptance criteria. |
| 3. Solution and cutover design | Architecture, extension boundaries, integration contracts, environments, security roles, migration plan, and cutover runbook outline. | Technical owners confirm feasibility and the delivery backlog is estimable. |
| 4. Configure, build, and convert | Configured Business Central environment, AL extensions or selected apps, reports, integrations, permissions, and automated checks. | The agreed scope builds cleanly and is ready for integrated testing with known defects recorded. |
| 5. Migration rehearsals | Repeatable extraction, transformation, load, reconciliation, timings, and issue remediation. | A rehearsal meets the agreed accuracy and cutover-duration criteria. |
| 6. UAT, training, and readiness | Executed end-to-end business scenarios, trained users, support preparation, go-live decision pack, and rollback plan. | Authorised business and technical owners sign off against agreed criteria. |
| 7. Cutover and hypercare | Final migration, reconciled opening position, enabled users and interfaces, controlled issue triage, and transition to support. | Priority issues are resolved or accepted, operations are stable, and ownership has transferred. |
Australian context
Planning factors Australian organisations should surface early
The technical migration path is global, but commercial, tax, payment, operating-calendar, and support decisions must reflect the Australian business that will use the system.
Currency, GST, and commercial terms
Use Microsoft's live Australian pricing page for current licence information and obtain a dated quote. State currency, GST treatment, billing frequency, renewal assumptions, app fees, and professional-services exclusions explicitly.
GST and finance validation
Include GST posting setup, tax-sensitive transactions, reconciliation, reporting, and the organisation's control requirements in design and UAT. Product configuration should be reviewed by the customer's qualified finance and tax advisers.
Banking, payments, and external services
Identify bank formats, payment approvals, remittance outputs, feeds, payroll boundaries, ecommerce, EDI, freight, and industry apps. Availability and responsibility can differ by bank, provider, and solution.
Business calendar and support coverage
Plan around month-end, financial year-end, stocktakes, seasonal peaks, public holidays, warehouse shifts, and supplier availability. Define time zones, escalation routes, and after-hours cutover coverage in advance.
Migration strategy
Three scope patterns that change cost and timing
These are planning patterns, not fixed packages or duration bands. Discovery should establish which pattern—or combination—fits the data, process, audit, and continuity requirements.
Reimplementation with selected data
Configure a standard-led target and bring forward an agreed subset such as setup, master data, opening positions, and selected transactions. Historical access and statutory retention still need an explicit design.
- Can reduce the legacy code and data carried forward.
- Requires strong process decisions and reconciliation rules.
- Must not be described as automatically faster before scope is tested.
Full upgrade and cloud migration
Follow Microsoft's supported intermediate versions, convert required customisations to extensions, upgrade the data, and use the supported cloud migration process for the online target.
- May preserve more data and continuity.
- Intermediate upgrades and extension work can be substantial.
- Exact version compatibility must be checked for the target release.
Business transformation
Use the move to redesign processes, integrations, reporting, controls, or operating models rather than reproducing NAV. This is broader than a technical migration and should be governed accordingly.
- Creates additional design and change decisions.
- Needs clear benefits, owners, and scope control.
- May be staged to protect critical operations.
Hybrid or staged transition
Sequence companies, integrations, or capabilities when a single cutover is not appropriate. Staging can manage operational risk but adds temporary interfaces, reconciliation, and dual-running considerations.
- Define the system of record at every stage.
- Price temporary integration and support effort.
- Set clear conditions for retiring the legacy environment.
Before requesting a quote
Prepare an estimate pack that suppliers can price consistently
A common evidence pack makes proposals easier to compare and reduces contingency caused by unknowns. Sensitive system information should be shared through an approved secure channel, not a public enquiry form.
- Exact NAV version, cumulative update, localisation, database topology, and SQL version
- Companies and sites, active and historical, with legal or reporting relationships
- Named user roles and capability needs—not only concurrent or current licence counts
- Modified-object inventory, deltas, source availability, and third-party app list
- Inbound and outbound integrations with owners, volumes, schedules, and test access
- Data volumes by key table plus proposed history, attachment, and archive scope
- Critical finance, sales, purchasing, inventory, warehouse, manufacturing, and service scenarios
- Reports, documents, labels, statutory outputs, and analytics that must remain available
- Security roles, approval controls, segregation needs, and audit evidence
- UAT participants, decision-makers, training audiences, and realistic availability
- Blackout dates, peak periods, cutover window, rollback criteria, and support coverage
- Assumptions, exclusions, customer tasks, third-party tasks, and acceptance criteria
Practical answers
Frequently asked questions
How much does a NAV to Business Central migration cost in Australia?
There is no responsible fixed figure without discovery. Cost depends on the supported upgrade route, licence mix, companies, data scope, customisations, integrations, reports, apps, testing, training, cutover, and internal customer effort. Ask for a cost breakdown with assumptions and exclusions rather than only a headline total.
How long does a NAV to Business Central migration take?
The timeline should be estimated after the current version, customisations, integrations, data volume, customer availability, and cutover constraints are known. A credible plan identifies phases, dependencies, exit criteria, a forecast range, and the conditions that would change it.
Are Business Central licences included in migration services?
Do not assume so. Microsoft licences, third-party apps, implementation services, support, storage or capacity, and out-of-scope work should each be identified in the proposal. Check Microsoft's current Australian pricing and the signed commercial terms.
Does moving less history always make the project cheaper?
Not automatically. A smaller data set can reduce extraction, load, and reconciliation effort, but selecting, transforming, archiving, and providing compliant access to excluded history also requires design and testing. Compare the complete approaches using evidence from the database.
Should an Australian business go live at financial year-end?
A period boundary can simplify some opening-position decisions, but it can also coincide with reporting workload and limited staff availability. Choose the cutover date from reconciliation design, rehearsal evidence, operational risk, and finance-team capacity—not from the calendar alone.
Primary references
Official Microsoft guidance
Microsoft changes product pricing, licensing, tooling, and supported upgrade routes over time. Use these source pages to validate the current position for your target release.
Plan from evidence
Turn the budget discussion into a readiness baseline
Share the non-sensitive facts about your NAV environment, user count, migration status, and priorities. LeXurey can use them to prepare a complimentary, no-obligation migration-readiness discussion; exact scope and commercials require discovery and an agreed Statement of Work.