Classify what a source project code actually does before choosing between a financial dimension and the D365 project module, and build the discovery framework the thin evidence base requires.
What you will be able to do
Classify each project code by what it actually does in the business today
Apply the application-boundary test that decides dimension versus project module
Identify project behaviour hidden in user-defined objects and add-ons
Scope a project discovery that produces evidence rather than opinion
Recognise where the evidence base is too thin for a confident mapping
Introduction
This is one of the chapters on this path where honesty about the evidence base matters more than confident prose.
What a project code can actually be
In practice the same construct serves four quite different purposes, often within one estate.
The discovery framework
Because the source package cannot tell you how this client uses projects, the discovery has to. Run it in three passes.
Applying the boundary test
With the evidence gathered, the decision is usually clear. Where it is not, these tests break the tie.
If the module is chosen
The design becomes a substantial workstream in its own right, and this path's evidence base does not extend into it. What the migration must settle:
Where the evidence stops
Supported by the source package: that project codes exist; that they map either to a project module record or to a project financial dimension; that the choice is an application-boundary decision governed by operational ownership, costing, billing and governance; that project usage is a required discovery input;
Knowledge check
Summary
The source package supports project codes existing and rates their mapping at medium confidence. It does not describe client usage. The decision is an application-boundary test: the project module only where operational ownership, costing, billing or governance justify it.