Inventory and dispose of the twelve EBS customisation surfaces — from Descriptive Flexfields and CUSTOM.pll to concurrent programs and XML Publisher — using business purpose rather than technology as the sorting key.
EBS gives customers an unusually wide extensibility surface, and mature estates use most of it. The source package identifies twelve distinct surfaces, spanning flexfields, two separate user-interface customisation technologies, workflow, batch, reporting and integration.
The last three rows belong operationally to the Integration module, which takes them further. They appear here because they are part of the same inventory and the same triage, and separating the inventory by owning module is how artefacts fall between two workstreams.
A register that lists artefacts and their technology supports counting. A register that supports decisions needs six columns beyond the artefact's name.
Keep as standard D365 configuration. The behaviour exists in the target as configuration. This is the best outcome and it is more common than teams expect, because many EBS customisations were built to fill gaps that the target closes natively. Rewrite in X++.
This is the one to plan first, because it is the one most likely to be missing from the estimate entirely.
The gap register carries a separate entry for Account Generator and workflow-embedded derivation, and it belongs in this module even though its consequences land in the Posting Engine module.
Once an artefact is disposed to a rebuild, three homes are available and the choice is usually clearer than it first appears.
The EBS customisation estate spans twelve surfaces, none of which converts. This module produces dispositions, and the quality of those dispositions depends on an inventory built around business purpose, owner, trigger, consumer, last execution and criticality.