Inventory the eleven customisation surfaces an Acumatica estate can hide behaviour in, recover the business capability behind each one, and assign every artefact a single disposition — because none of it ports to X++.
The gap register states this module's premise in one sentence: there is no direct runtime parity for Acumatica customisations in D365 F&SCM. Nothing converts. The customisation-surfaces source says the same thing from the other direction — no direct portability to X++, so requirement recovery and explicit disposition are mandatory.
The customisation-surfaces inventory for this path lists eleven, and it is worth walking through all of them, because the recognisable ones are not the risky ones.
The inventory record that supports a disposition decision has a specific shape, and none of the fields are technical.
The source names five patterns explicitly, and each has a characteristic failure.
Custom fields and custom entities are the most numerous items in most inventories and the easiest to mishandle, because "add the field to the target" looks like an obvious answer.
The source prescribes exactly seven, and the discipline is that every surface gets one — not a category, not a phase, one disposition with an owner.
The eleventh surface deserves separate handling because the questions are commercial rather than technical: treat them as product dependencies with licensing, roadmap and data-ownership analysis.
The estimate follows from the dispositions, and it is worth being explicit about what does and does not drive it.
Nothing in the Acumatica customisation estate converts to X++, and the estate is larger than its tidiness suggests. Eleven surfaces can hold behaviour, and the ones that cause trouble — generic inquiries, import scenarios, push notifications, screen-based automation — were often configured by business users and never classified as…