Dynamics NAV to Business Central migration: which specialists do you need?

Inventory the starting point before requesting estimates

Record the exact NAV version, cumulative update, country localization, database size and company structure. Include source availability, modified objects, installed add-ons, scheduled jobs, document outputs and external interfaces. These facts determine whether a proposal is based on your actual estate or a generic migration story.

Microsoft’s NAV migration documentation describes supported routes and intermediate upgrade requirements. Those routes can change with platform support, so require the proposed specialist to validate the path for your source and target versions before committing to a schedule. Avoid relying on an old diagram saved from a previous project.

A Business Central migration specialist should produce an assessment with assumptions, dependencies and options. Ask which parts can be verified immediately and which need a trial conversion or data exercise. A credible assessment narrows uncertainty rather than disguising unknowns as a precise estimate.

Choose what is worth carrying forward

The migration is an opportunity to review legacy behavior, but it should not become an uncontrolled redesign. Classify customizations by current use, business value, replacement options and data consequences. Some remain essential; others duplicate features now available in the target application or support a process the business no longer uses.

In a hypothetical company, a custom purchase approval routine may still be used daily while an old sales export has not run for years. Treating both as mandatory conversions wastes effort and enlarges the test surface. Ask users to demonstrate current usage and identify the owner of each decision.

Create a disposition register: retain and redesign, replace with a standard process, replace with an approved app, archive or retire. Record the effect on historic data and reporting. The business should approve this register before substantial development begins. Technical feasibility alone does not determine what deserves a place in the new system.

Separate the technical path from business transformation

A technical migration focuses on moving a supported estate and preserving agreed behavior. A reimplementation places greater emphasis on redesigned processes, new configuration and selected data. Real projects may contain elements of both, but the distinction affects team composition, testing and user involvement.

Microsoft documents different migration options and the consequences for customizations and historical data. Rather than choosing on a slogan such as “clean start,” compare the options against reporting needs, audit access, operational continuity and the cost of maintaining old behavior. Ask how historic records will be available to authorized users after transition.

Bring Business Central functional consultants into this decision. A technically successful migration can preserve a process that the organization already considers broken. Conversely, unnecessary redesign can increase risk when the immediate business need is a controlled platform transition. Agree the boundary and put later improvements into a separate roadmap.

Allocate specialists to migration risks

One migration lead can coordinate the plan, but the work contains distinct responsibilities. Legacy code analysis requires NAV knowledge; extension work requires AL experience; financial reconciliation requires business finance ownership. Interfaces often need someone who understands both the old integration and the target contract.

The table identifies typical responsibilities, not a mandatory full-time headcount. Several roles can be combined if the person has evidence of both capabilities and enough capacity. Preserve independent acceptance for critical financial and operational results. The person running a conversion should not be the only person deciding that the resulting balances are correct.

Treat data rehearsal as a business exercise

A migration rehearsal should answer more than whether a tool finished without errors. Compare source and target results for the agreed data categories. Use record counts where meaningful, but also reconcile financial balances, open transactions and operational quantities. Document exclusions so missing data is distinguishable from deliberately omitted data.

Microsoft’s preparation guidance highlights source versions, companies, database size and extension data as important planning inputs. Your rehearsal should turn those inputs into observable results and expose bottlenecks while there is time to correct them. A large volume of history may affect both processing and validation effort.

Assign named business reviewers to difficult exceptions. If an open purchase line has inconsistent information, the migration team needs a decision about the correct outcome. Maintain a repeatable correction process rather than making undocumented one-off fixes in each trial. The final run should follow an understood method, with differences explained rather than accepted on trust.

Rebuild interface assumptions before cutover

Legacy NAV integrations may depend on old authentication methods, direct database access, file locations or scheduled components. Inventory how each connection actually works, including any manual steps known only to one employee. A simple “CRM integration” label conceals the direction, frequency, transaction ownership and error recovery rules.

For the target design, Microsoft identifies the Business Central API stack as the preferred integration approach and offers built-in and custom APIs. The specific design still needs to match the business transaction. Confirm identifiers, mapping, authentication, retry behavior and reconciliation with the external system owner.

Use Business Central integration developers where these connections require redesign. Test duplicate messages, failed requests and cutover timing, not just a successful sample. Decide whether old integrations must be paused during the final migration and how queued transactions will be handled. An interface overlooked in planning can continue writing to the wrong system after users have moved.

Choose the engagement model by migration phase

Hourly Model suits an initial estate review, specialist opinion or focused investigation of a blocking issue. Ask for a written finding with evidence and next steps. It can also supplement an established partner team that needs temporary expertise in a specific NAV version or extension challenge.

Project Based suits a defined migration work package after discovery: an approved extension conversion, a rehearsal cycle or an interface transition. State the source and target assumptions, required client inputs and acceptance measures. A migration package should distinguish unexpected legacy defects from agreed conversion work.

Dedicated Resource is useful when a large customization inventory or repeated migration cycles create sustained demand. Plan continuity through the relevant validation period so knowledge does not disappear immediately before cutover. For North American and European customers working with India-based resources, agree the exact rehearsal and cutover overlap; ordinary meeting availability may not cover a weekend transition.

Make cutover and early-life support explicit

Document the final data freeze, extraction or replication activities, verification sequence and go/no-go authority. Assign a person and expected duration to each step. Include communications to users and external system owners, and define what evidence must be available before operational work begins in the target environment.

A fallback decision needs practical criteria and timing. Ask the migration lead to explain what can be reversed, what cannot be safely replayed and when new transactions make a return more complicated. Have the customer’s responsible technical and business owners approve the plan based on the actual architecture.

After launch, track issues separately from improvement requests. Keep migration specialists available for reconciliation questions and ensure the support team understands the new extensions and interfaces. Close the migration only after agreed acceptance checks and handover are complete. A successful login on Monday morning is useful evidence, but it is not the whole definition of a successful transition.

• Verified source version, localization and accessible customization inventory.
• Approved data scope and named reconciliation owners.
• Rehearsed interfaces, cutover steps and support responsibilities.