Dynamics GP and AX Third-Party Add-On Dependency Assessment
Core financial data rarely makes a GP or AX migration hard. The add-ons, custom reports and integrations around it do. This assessment scores how deeply your system depends on them so you can size the real work.
1. How many third-party (ISV) add-on products run inside your GP or AX system?
2. Do you have a current vendor and a known successor for each add-on?
3. How many custom reports (SSRS, Crystal, SmartList, Management Reporter) are in regular use?
4. How are custom forms or business logic built (Dexterity, VBA, Modifier, X++ customisations)?
5. How many integrations read or write ERP data (EDI, eCommerce, payroll, banks, CRM)?
6. How are those integrations built?
7. Does anyone on staff or retainer know the customisation source code?
8. Which SQL Server and Windows versions host the system?
9. How much business process depends on add-on or custom features that standard target-ERP functions do not cover?
10. Have you documented the add-on and integration inventory with owners?
How to use the assessment
Answer each question for the system as it runs today, not as documented. Ask the people who actually support it, since add-ons and integrations are often known only to a few staff. Your score maps to a band with recommended next steps. Rerun it after you complete your inventory to see whether the picture changes.
- Include integrations owned by other departments
- Count scheduled scripts and SQL jobs as integrations
- Treat unknown answers as the lowest score
What drives migration effort
In practice, effort splits into data (masters, balances, open items), reports, integrations and extensions. Data is usually the most predictable. Extensions and integrations are the least predictable because they are unique to your business and often undocumented. A lower score here is a warning that the discovery phase should be longer and the estimate wider.
Deciding what to keep
Not every add-on needs a replacement. Many exist because of a limitation in an old version that the target system handles natively. For each one ask who uses it, how often, what the manual fallback is, and whether a standard function covers the need. Retiring unused reports and integrations is the cheapest scope reduction you will find.
Common mistakes
Teams plan the data load and leave integrations until the end. Others assume an ISV will deliver a version for the new platform, then discover the vendor was acquired or has stopped. Confirm vendor support in writing early, and keep copies of customisation source and installers.
Frequently Asked Questions
What counts as an ISV add-on?
Any product from a vendor other than Microsoft that installs into or connects to your GP or AX system: modules, forms, workflow tools, EDI, payroll, reporting extensions and banking connectors. Include those installed as Dexterity chunks or AX models.
Is a low score a reason not to migrate?
No. It is a reason to plan carefully. High dependency usually means more time and cost, not that migration is impossible. Support timelines for your current version may still force the move.
Who should fill this in?
Ideally the ERP administrator, a finance lead and an IT integration owner together, so no hidden dependency is missed. Run it as a short workshop and record the answers.
Does the target system change the score?
The score reflects your current dependency. The target decides how many items need replacement. Business Central has its own extension marketplace, while D365 Finance and Operations has different ISV options. Check each add-on per target.
If your inventory shows heavy custom code or integrations, we can help analyse and document them using on-prem tools that read your code and databases without sending data out.
Related Tools
AX 2012 Table to D365 Data Entity Reference
Look up the D365 F&O data entity and OData collection that corresponds to a Dynamics AX 2012 table when planning data migration.
Microsoft DynamicsD365 Finance and Operations OData URL and Token Request Builder
Generate the OData request and OAuth token call to read data entities from D365 F&O during an AX migration or validation.
Microsoft DynamicsDynamics GP Year-End Close Checklist
A step-by-step checklist for closing a fiscal year in Dynamics GP, from subledger reconciliation to final backup and sign-off.
More Microsoft Dynamics tools
See all- D365 F&O Manufacturing Data Entities Reference
- D365 F&O OData URL Builder
- D365 Production Order Status Reference
- D365 Data Management Import Worksheet Template
- D365 Batch Job Checklist
- D365 Security Role Design Worksheet
- D365 Master Planning Setup Checklist
- D365 One Version Update Test Checklist
- D365 Finance and Supply Chain Functional Design Document Template