The eight canonical migration waves mapped from the Maconomy playbook's own wave model, the scope disposition codes applied to every discovered object, decision gates, RACI for the project-to-cash design, required open decisions, and the roles a Maconomy programme must staff — including the customer's own Maconomy application owner.
A Maconomy-to-D365 migration programme is dominated by the project-to-cash lifecycle: jobs, tasks, time, expense, billing, WIP, revenue recognition, and project accounting.
The Maconomy playbook (§15.5) defines nine dependency groups (W0–W8). The site fixes an eight-wave canonical model. The mapping is not one-to-one because the playbook separates foundation configuration more finely and groups project data differently.
Every discovered Maconomy object — module, process, customisation, report, integration, batch job — receives one primary disposition code. No build work begins on any object whose code is unclassified.
The programme operates through seven gates, each of which locks a defined scope and prevents rework on downstream work that depends on it.
The project-to-cash design is the most cross-functional decision set in a Maconomy migration. It spans finance, project accounting, resource management, billing, and operations.
The playbook (§18.4) identifies fifteen decisions that must close before build. Each is a blocking dependency for downstream work:
A Maconomy migration requires roles that span both the customer organisation and the implementation partner. The following roles are the minimum for a programme of this type.
The seven programme stages map to wave activity as follows:
The programme shape for a Maconomy migration is defined by three characteristics: project-to-cash dominance (projects are the core workload, not products or inventory), decision density (fifteen mandatory decisions that cascade into each other), and people-centricity (workers and resources are the primary master data, and the customer's…