Inventorying and triaging the customisation estate

How to catalogue every Maconomy customisation surface — MScript, RGL/MSL, Java extensions, Extender, APUs and TPUs, custom fields, custom tables, Workspace Client layouts, iAccess, Touch, workflows, Business Objects universes, web services, direct SQL and batch jobs — classify each by recovered business intent, and size only what survives into D365 extensions, Power Platform, or integration.

What you will be able to do

• Catalogue the full Maconomy customisation estate across all twenty-four surface types
• Classify every object by recovered business intent into one of nine dispositions
• Contrast the APU/TPU patch-and-upgrade-unit model with D365 deployable packages and four service updates a year
• Size migration effort from recovered intent per object, never from lines of code
• Produce a prioritised build backlog that excludes retired and standardised objects

Introduction

Maconomy's customisation estate is broad, layered and — critically — has no automatic conversion path to any target platform. There is no MScript-to-X++ transpiler, no Extender-to-Power-Platform converter, and no tool that partially converts a Business Objects universe into a Power BI semantic model.

The twenty-four customisation surfaces

The Maconomy customisation estate spans twenty-four distinct surface types. Each has different portability characteristics, different discovery techniques and different target dispositions:

The nine dispositions

Every artefact in the customisation estate must land in exactly one disposition before any build work is scoped:

Triage method: five questions per artefact

For each of the potentially hundreds of artefacts in the estate, the triage pass asks:

APU/TPU model versus D365 deployable packages

Maconomy delivers changes through Application Program Updates (APUs), Technical Program Updates (TPUs), and Correction Units (CUs). These are versioned packages applied at customer discretion through the Deltek Software Manager and MConfig tooling.

Sizing from recovered intent, not lines of code

The single most common estimation failure in Maconomy-to-D365 programmes is sizing build effort from the volume of source code. This fails for three reasons:

Placement rules: where each object type lands

Does D365 Finance or Supply Chain do this natively? If yes, configure — do not build. This is the most common outcome for artefacts that were originally built to fill Maconomy functional gaps that D365 addresses.

The code-bearing estate: MScript, Java, Extender

MScript is Maconomy's proprietary scripting language for validations, calculations, automation and integration hooks. It has no public language specification, no external runtime, and no conversion tool.

Knowledge check

Summary

The Maconomy customisation estate is diverse, entirely non-portable, and must be triaged before any build is scoped. There is no transpiler, no partial-conversion tool, and no shortcut that avoids recovering business intent from every surviving artefact.