Inventory IDOs, extension class assemblies, application and form event handlers, Mongoose customisations and .NET libraries, then assign each one a target surface chosen by business intent rather than by source artefact type.
The customisation surfaces inventory for CloudSuite Industrial lists nine distinct sources of behaviour, and they differ from each other more than they resemble each other. Their preservation qualities run from high to low. Their triage dispositions include configuration, extension and discard.
Read the preservation column as an estimate of how much of the source artefact's intent survives the move without redesign. High means the same thing can be achieved, usually more cheaply. Low means the artefact is evidence of a requirement and nothing more.
An IDO is a metadata-defined business object that transports data and rules between client and database. That definition contains the whole difficulty in one clause: and rules.
IDO extension class assemblies are .NET assemblies that extend IDO methods and event handlers. They are rated low preservation quality, and the translation strategy is explicit about the sequence: import the source assembly inventory, recover behaviour, and rewrite only approved logic into supported D365 extension points.
This is the surface with the blocker rating, and the reason is in the gap register's description: CSI event handlers can encode automation, validation, approvals and UI-specific behaviour, while D365 spreads the same intent across X++ handlers, business events, workflow and Power Platform.
The one bright spot in the inventory. High preservation quality, and a configuration disposition rather than extension.
Extension assemblies beyond base metadata, rated low preservation quality with medium confidence.
Rated low preservation quality with medium confidence, and the translation strategy is a four-way classification: operational document, statutory output, analytical report, or disposable local workbench.
The gap register is emphatic and the knowledge base repeats it: the main anti-pattern is treating ION as just another ERP customisation.
The ninth surface is the only one with a discard disposition, and it is worth understanding why.
The output of the module is one register with one row per artefact across all nine surfaces, and the columns are what make it a scope estimate rather than a catalogue.
IDOs need classifying as entity-shaped, method-shaped or mixed, with mixed contracts split before design, and the inventory built from consumers rather than from metadata. Extension class assemblies are low preservation and need behaviour recovery followed by selective rewrite.