Triage Dexterity, Modifier, Report Writer, VBA and .NET add-ins by business behaviour rather than by technology name, and re-home each one deliberately into extensions, configuration, Power Platform or retirement.
The GP extensibility estate is one of the three blockers in this migration. The gap register places re-platforming Dexterity, Modifier, Report Writer and VBA alongside the segmented-account redesign and the posting-setup decomposition: blocker severity, weeks of effort, high confidence.
The source material inventories ten surfaces with an assessed preservation potential and disposition for each.
Four of those five are business facts. Only the trigger is partly technical. That balance is the point: the decision about where a customisation lands in the target is made from business facts, and the technical assessment follows it.
Dexterity. Low preservation, and the assessment is high confidence. Capture the business rule, not the code path. A share of Dexterity logic addresses gaps the target closes natively, which is discoverable only by describing the rule in business terms first.
Business rules found in code go to the functional design. Every rule discovered inside a Dexterity customisation, a Modifier dictionary or a VBA routine is a functional requirement that was not in the functional documentation. Route them there, not into a technical backlog.
Estimate after triage, not before. A pre-triage estimate is a count multiplied by an average, and neither number means anything. Estimate re-expression, not conversion. There is no conversion path. Each item is understood, decided and rebuilt or retired. Include the non-code cost.
The GP extensibility estate has no mechanical conversion path and is one of the three blockers at weeks of effort with high confidence. Ten surfaces, five of them with low preservation potential. Capability survives; artefacts generally do not. The central anti-pattern is inventorying technology names instead of business behaviours.