Programme shape, waves and sequencing for a reimplementation migration
The structural choices that define a Business Central to D365 F&SCM programme — why this is a reimplementation and not an upgrade, the eight canonical waves with dependency ordering, go/no-go gates per wave, disposition codes for every discovered object, and the false-parity risks that arise specifically from shared Microsoft vocabulary and branding.
What you will be able to do
Explain why Business Central to D365 F&SCM is a reimplementation, not an upgrade, despite shared Microsoft branding
State the eight canonical waves and the dependency logic that orders them
Describe the go/no-go gate that closes each wave before the next can begin
Apply the disposition codes to every discovered source object
Identify the false-parity risks that arise from shared terminology between BC and D365 F&SCM
Introduction
A Business Central or Dynamics NAV migration to D365 Finance and Supply Chain Management is a reimplementation — not an upgrade, not a lift-and-shift, and not a platform version change.
Why this is a reimplementation
Code does not convert. C/AL and AL do not compile to X++. There is no tool that reads an AL app and produces an X++ extension. Data does not schema-migrate. BC tables (Customer, Item, G/L Entry, Dimension Set Entry) are not the same as D365 tables (CustTable, InventTable, GeneralJournalAccountEntry, DimensionAttributeValueCombination).
The eight canonical waves
The site fixes an eight-wave dependency model. Each wave represents a load-and-validation group, not a calendar sprint. Waves are dependency-ordered: Wave N cannot begin until Wave N-1 passes its reconciliation gate.
Per-wave go/no-go gates
Each wave closes with a reconciliation gate. The gate is binary — PASS or FAIL. A failed gate blocks progression to the next wave until the root cause is resolved.
Re-mapping the playbook wave numbering
The BC playbook numbers its own waves differently from the site's canonical eight. The re-mapping is:
Disposition codes for discovered objects
Every discovered source artefact — extension, integration, report, workflow, job, security configuration — receives a disposition code:
The source fingerprint
Before wave planning begins, the programme must freeze an immutable source fingerprint. For Business Central and NAV estates, this fingerprint captures:
False-parity risks
False parity is the most dangerous risk category in a BC-to-D365 programme because it hides behind familiarity. Both products are Microsoft Dynamics. Both use Azure AD. Both connect to Dataverse. Both expose OData. Both use "dimensions". This shared vocabulary creates an illusion of compatibility that collapses during execution.
The seven programme stages
The site defines seven stages that structure delivery:
Knowledge check
Summary
A Business Central to D365 F&SCM migration is a reimplementation governed by eight dependency-ordered waves, each closed by a binary reconciliation gate. Every discovered artefact receives a disposition code. The programme's largest risk is false parity — the illusion of compatibility created by shared Microsoft branding and vocabulary.