Triaging the extension estate when the public object model is incomplete

How to classify a QAD customisation estate — QXtend interfaces, platform flows, EDI maps, EQMS workflows, planning scenarios and undocumented local reports — into extensions, Power Platform, ISV or retirement.

What you will be able to do

Introduction

Every migration has a customisation estate, and the honest question is always the same: what is it, what does it do, and where does each piece go?

The eight surfaces and their classifications

The customisation surfaces file gives eight entries with a triage decision and a rationale for each.

Building the inventory the estate actually has

The eighth surface is where the discovery work sits, and the method matters because the artefacts are not catalogued anywhere.

The triage rule

With an inventory, each item needs a destination. Four questions in order settle almost every case.

The quality-platform decision

EQMS is the surface where the technical decision most obviously follows a process decision, and getting the order right saves a great deal of rework.

Designing the extension model

For whatever does become extension code, the design principles are the ones that keep service updates uneventful.

Retirement as a first-class outcome

A meaningful proportion of any long-lived customisation estate exists to compensate for something the source could not do. Where the target does it natively, migrating the customisation reproduces the workaround and its maintenance obligation without the original reason.

Knowledge check

Summary

The extension estate on this path is dominated by integration, partner content and quality workflow rather than by ERP code, which is a healthier starting position than most. Seven of the eight documented surfaces come with a triage classification and a rationale;