MB-500, a 90-day plan and the honest assessment of what transfers
What MB-500 measures and what an AX 2012 developer already knows of it, an honest accounting of which skills transfer and which habits are now liabilities, a six-fortnight learning plan with verifiable artefacts, an eighteen-artefact capstone project, market positioning, and a closing register of things that are genuinely harder in D365.
What you will be able to do
Explain what MB-500 measures and identify which of its skill areas an AX 2012 background already supports
Distinguish clearly between skills that transfer directly, skills that transfer conceptually, and habits that are now liabilities
Follow a six-fortnight plan from a standing start to a working capstone
Assemble a capstone project of around eighteen artefacts that demonstrates practical fluency
Position an AX 2012 developer background honestly in the D365 hiring market
Name at least eight things that are genuinely harder in D365 and describe the coping strategy for each
Introduction
This chapter is written for a named person: an AX 2012 developer who has worked with X++, the AOT and MorphX for years, whose codebase is being upgraded or replaced, and who is deciding what to do next.
MB-500: what it measures and what you already know
MB-500 (Microsoft Dynamics 365: Finance and Operations Apps Developer) is the single industry-recognised credential for D365 F&O developers. Its skill areas, and the transfer picture for an AX 2012 developer:
What transfers and what does not
X++ syntax and data-access patterns — select, while select, update_recordset, delete_from, insert_recordset, ttsbegin/ttscommit, RecId, DataAreaId, crossCompany The D365 data model — standard tables (CustTable, VendTable, SalesTable, InventTable, LedgerJournalTable and hundreds more), their relations, and their posting behaviour Posting…
The first 90 days: a six-fortnight plan
Each fortnight produces something checkable. The plan is designed so that "I studied the documentation" is never the only evidence of progress.
The capstone: eighteen artefacts, one deployable package
[!TIP] Item 18 matters more than it looks. A one-page note that says "in AX 2012, this was a CUS-layer over-lay of SalesLineType.validateWrite; in D365 it is a CoC extension, for these reasons, with these trade-offs" demonstrates genuine understanding of both systems. That is what a hiring manager is looking for from an AX 2012 candidate.
Market positioning
An AX 2012 developer has something no other candidate has: direct, first-hand knowledge of the D365 data model, posting architecture and business-process flow. The tables are the same tables. The posting profiles are the same posting profiles. The dimensions are the same dimensions.
Honest friction: things that are genuinely harder in D365
None of these is a reason to expect the transition to fail. Each has a named coping strategy. The honest acknowledgement that they exist — rather than marketing them away — is what lets you plan around them rather than being surprised by them.
Knowledge check
Summary
An AX 2012 developer starts this transition with more of the hard part already done than any other source-system developer on this site. The data model, the posting architecture, the dimension framework, the security hierarchy and the transaction semantics are all known territory.