Why an M3 migration is a conceptual re-projection — from a program-code-driven system where behaviour hides behind numeric CO/CR codes to D365's posting-profile world — and why understanding the FAM function is the prerequisite for everything else.
What you will be able to do
Explain M3's readability problem and why decoding numeric control codes is the first migration task
Name M3's primary operational modules by three-letter code and their D365 analogs
Describe the CONO/DIVI identity model and its relationship to the D365 legal entity
Trace the path from an operational event through the FAM function to an FGLEDG voucher
Explain why CO/CR-code-to-posting-profile translation is the programme's defining workstream
Introduction
Infor M3 — descended from MOVEX, the Lawson Software product that ran on IBM AS/400 for two decades before being re-platformed as a Java application — is one of the most operationally capable mid-market ERPs in the world. It is also one of the least readable to anyone who did not grow up inside it.
The M3 Business Engine and module codes
The M3 Business Engine (BE) is a monolithic Java application server that hosts every M3 functional module in a single process tree. The H5 client — and before it, Smart Office — is a thin renderer. The database is a largely passive store. All business logic lives in the BE, and it is addressed by program codes, not services.
CONO, DIVI, and the M3 accounting identity
M3 represents an enterprise through four nested codes. Two of them define the accounting identity:
The readability problem — numeric codes that hide behaviour
CO codes (Control Object codes) and CR codes (Control Reference codes) are M3's mechanism for encoding accounting behaviour in master data and transactions without describing it. A customer with CO code 12 will post to different GL accounts than a customer with CO code 14.
The accounting pipeline in M3
Both M3 and D365 F&O run every transaction through the same four-step pipeline. Naming it explicitly gives the team a shared frame.
Programme codes and surface vocabulary to recognise
M3 practitioners often identify a process by programme code rather than by the table it touches. A D365 team does not need to memorise every programme, but it must recognise the codes that appear in migration artefacts and know when to verify release-specific details against the customer's catalogue.
Knowledge check
Summary
M3 is a program-code-driven business engine where operational behaviour is encoded in numeric CO/CR codes and FAM functions that most people in the organisation have never inspected.