Reviews and corrects ledger-to-subledger alignment in D365 by fixing posting configurations, inventory profiles, reconciliation logic, GL mapping, and critical reporting procedures.
Moving from AX to D365? Make Your Customizations Reapply for the Job.
Posted on: November 3, 2026 | By: Heather Zhu | Microsoft Dynamics AX/365|Microsoft Dynamics Manufacturing, Microsoft Dynamics AX/365
Before you pay to rebuild yesterday’s code, prove which business requirements still deserve a place in tomorrow’s system.
By Logan Consulting | November 2, 2026 | 5-minute read
Picture an AX migration workshop. Someone opens the customization spreadsheet. Finance recognizes a critical control. Operations recognizes a useful shortcut. Nobody recognizes three of the reports, but they all receive a development estimate anyway.
This is an illustrative scene, not a client story. The problem is the assumption underneath it: everything that exists must come along.
A migration estimate answers what rebuilding costs. It does not answer whether rebuilding is the right decision.
Logan’s position: preserve the business requirement. Make the old implementation earn its place.
Start with the job, not the code
Ask what each customization protects, enables or simplifies. Who uses it? What breaks without it? Is it meeting a customer commitment, enforcing a control or compensating for an old process?
That distinction matters technically, too. Current D365 Finance and Operations product models support extensions rather than AX-style overlayering. Keeping a requirement does not mean carrying its old implementation forward unchanged. [1]
Microsoft’s documented AX 2012 upgrade route applies to R2 and R3, with the latest available cumulative update required. Older AX versions need a separately assessed path. Its Upgrade analysis report identifies application, database and deprecated-feature issues; it is not a business-value scorecard for every customization. [2][3]
Use the technical assessment alongside a business-owned decision register, not instead of one.
Keep, retire or redesign. Require evidence for all three.
| Decision | What earns it |
|---|---|
| Keep the requirement | It still protects an essential control or meaningful business difference. Demonstrate the outcome and assign an owner. |
| Retire the requirement | The need has ended or is genuinely duplicated. Check reports, integrations and scheduled jobs before removal. |
| Redesign the implementation | The need remains, but configuration, a supported extension or a partner product is a better fit. Prove the replacement. |
“No one remembers why we built it” is an investigation prompt, not permission to delete it.
Likewise, “standard first” should not mean forcing a valuable process into an unsuitable template. Compare support effort, release testing, licensing, integrations and user work across the alternatives. A simpler architecture that creates a harder working day is not automatically an improvement.
A quality hold is a requirement. A custom button is not.
Consider an illustrative manufacturer with a custom AX receiving-hold function. The business requirement is straightforward: all 100 units on a received purchase-order line must remain unavailable for issue while inspection is open.
Before estimating a replacement button, test the native D365 approach. Quality associations can automatically generate quality orders at defined transaction events. For automatically generated quality orders, Full blocking can hold the entire source-line quantity during inspection, rather than just the sample. [4][5]
This is a fit test, not a claim that quality management is new or that every custom hold should disappear. Logan has previously covered native inspection blocking; the migration question is whether it preserves your required behavior. [6]
How to test the replacement in D365
In a sandbox, work with the quality owner and functional lead, using configured tests and appropriate business-role permissions.
Open Inventory management > Setup > Quality control > Item sampling. Create a fixed five-unit sample and set Full blocking to Yes. Then open Quality associations in the same setup area. Configure the relevant purchase-order scenario to create a quality order after product receipt, using the agreed test group and sampling record. [4][7]
Receive a complete 100-unit test line. Inspect the quality order and inventory-blocking records, then attempt the relevant inventory issue while inspection remains open. The acceptance criterion is five units selected for testing, all 100 protected from issue. [5]
Now repeat a separate test with Full blocking disabled. Compare the blocked quantity. A five-unit sample alone is not proof that the remaining 95 units are protected. Also test authorized release after successful inspection and the partial-receipt and warehouse scenarios your business actually uses. [4][5]
These are proposed tests, not executed tenant results. Verify the target build, dimensions, warehouse configuration and other blocking rules. Do not turn off an existing production control to run the comparison.
Replace the implementation without losing the evidence
Keep the original requirement, configuration, transaction references, test results and business-owner acceptance together. Measure manual interventions per completed inspection and control failures, not merely the number of custom objects removed.
There is a practical precedent in Logan’s published telecommunications migration case study. That AX 2012 R3 project reduced the customizations requiring redevelopment by introducing Treasury Automation Suite for banking. It was a partner-solution decision, not a claim that native D365 replaced everything. [8]
That distinction matters: configuration, custom extensions and independent software vendor products have different ownership and support obligations.
Make the migration budget buy a better operating model
Start with a small set of high-impact customizations. For each, document the business outcome, current dependencies, proposed replacement, acceptance test and accountable owner. Keep uncertain items in investigation rather than quietly treating them as approved rebuilds.
Budget for proving replacements, training users, preserving required history and retiring old dependencies. Do not spend the entire allowance translating code and leave the business decision for later.
Logan’s D365 approach puts business-process design and standard functionality ahead of unnecessary rebuilding, while protecting genuine differentiators. Bring one legacy customization and the person whose work depends on it. The useful question is not “Can we recreate this?” It is “What is the best supported way to do this job now?” [9]
Remember one thing: migrate the value, not the workaround.
Sources
- Microsoft Learn: Application extensibility roadmap
- Microsoft Learn: Upgrade from AX 2012 to finance and operations
- Microsoft Learn: Plan by using the Upgrade analysis report
- Microsoft Learn: Quality associations
- Microsoft Learn: Inventory blocking
- Logan Consulting: How Dynamics 365 for SCM Can Help You Manage Turnaround Times (January 25, 2021)
- Microsoft Learn: Quality management item sampling
- Logan Consulting: Southeast telecommunications company migration case study (project completed October 2021)
- Logan Consulting: Dynamics 365 Finance & Supply Chain Management
Scenarios and acceptance tests are illustrative editorial guidance, not performed tenant tests or customer results. Validate the target build, permissions, warehouse design and quality configuration.
