Validate every hop in the upgrade route

An ERP destination does not define an upgrade route.

The mechanism

The source build, target build and supported intermediate steps matter. A supported major-release path does not make every minor-build combination compatible.

Why this changes the decision

A supported target is not proof that the direct jump from the current source is valid. The route needs evidence for each major release and compatible build pair, followed by a rehearsal with explicit recovery decisions. Current matrices must be rechecked when execution begins.

A destination is not an itinerary

Imagine a project slide with a familiar NAV source on the left and an attractive Business Central target on the right. The arrow between them is the work that needs explanation. A target being supported does not establish that the source can reach it in one step. Ask the team to replace that single arrow with the assessed route for the actual estate. Each proposed stage should identify its input, prerequisites, expected output and source of support evidence. This is a planning example, not a published route for an unspecified NAV installation.

Use the exact component and build information, not a major-version label alone. Keep localisation, custom application behaviour, extension dependencies and retained data attached to the route. Where a prerequisite is unknown, record the missing evidence and its owner. Where an intermediate stage is necessary, explain why it exists rather than hiding it in the delivery estimate. The commercial value of the map is clarity about scope and uncertainty. It is not an automatic estimate of duration, cost or downtime, and it does not promise that every legacy customisation can be carried forward unchanged.

Rehearse the transitions, not only the final login

A useful rehearsal plan asks what must be true before each transition and what evidence will show that the transition worked. Record the expected application and data state, the relevant business validation and any external dependency that must be coordinated. If the team reaches a later stage but cannot validate a required operation, preserve that outcome as incomplete acceptance. Do not collapse it into a successful migration simply because the target starts. The example is an assessment framework; no version hop, conversion, restore or production change is executed here.

Separate the route decision from the cutover decision. A documented route can still need changes after a representative rehearsal exposes estate-specific work. Recovery choices may also become narrower after data or application state changes, so ask the delivery owner to explain those constraints before proceeding. Recheck the current Microsoft matrices at execution rather than treating an article or an old project diagram as permanent compatibility evidence. The decision a CTO should receive is a supported, qualified route with unresolved items and acceptance gates clearly stated, not an unsupported promise that the newest destination makes the path straightforward.

Three checks before a change

• Record exact source and target builds.
• Verify supported hops and compatibility.
• Rehearse prerequisites and recovery decisions.

Keep the scope clear

Matrices change. Do not turn a current bridge release into a permanent universal rule.