# Dynamics GP and AX Third-Party Add-On Dependency Assessment > Source: https://netray.co/tools/gp-third-party-addon-dependency-assessment > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: Free Tools ## Short answer Answer ten questions to score how much ISV add-ons, custom code and integrations will complicate a move off GP or AX. ## Category microsoft-dynamics ## Erp Microsoft Dynamics GP / AX ## Audience - ERP manager - CIO - Migration consultant ## Tool **Kind:** assessment **Questions:** #### How many third-party (ISV) add-on products run inside your GP or AX system? **Options:** ##### None **Score:** 10 ##### 1 to 3 **Score:** 7 ##### 4 to 8 **Score:** 3 ##### More than 8 **Score:** 0 #### Do you have a current vendor and a known successor for each add-on? **Options:** ##### Yes, all have a successor on the target platform **Score:** 10 ##### Most do **Score:** 6 ##### Some vendors are gone or unknown **Score:** 2 ##### We have not checked **Score:** 0 #### How many custom reports (SSRS, Crystal, SmartList, Management Reporter) are in regular use? **Options:** ##### Fewer than 10 **Score:** 10 ##### 10 to 40 **Score:** 7 ##### 41 to 100 **Score:** 3 ##### More than 100 **Score:** 0 #### How are custom forms or business logic built (Dexterity, VBA, Modifier, X++ customisations)? **Options:** ##### Mostly standard, little custom code **Score:** 10 ##### Some documented customisations **Score:** 6 ##### Many customisations, partly documented **Score:** 2 ##### Heavily customised and undocumented **Score:** 0 #### How many integrations read or write ERP data (EDI, eCommerce, payroll, banks, CRM)? **Options:** ##### None or 1 **Score:** 10 ##### 2 to 4 **Score:** 7 ##### 5 to 10 **Score:** 3 ##### More than 10 **Score:** 0 #### How are those integrations built? **Options:** ##### Documented, vendor supported APIs **Score:** 10 ##### Mixture of APIs and scheduled files **Score:** 6 ##### Direct SQL writes or scripts **Score:** 2 ##### Unknown or built by people who have left **Score:** 0 #### Does anyone on staff or retainer know the customisation source code? **Options:** ##### Yes, with source in version control **Score:** 10 ##### Yes, but source is on local drives **Score:** 5 ##### Only an outside contractor **Score:** 2 ##### No one **Score:** 0 #### Which SQL Server and Windows versions host the system? **Options:** ##### Supported versions **Score:** 10 ##### Supported but nearing end of support **Score:** 6 ##### One component is out of support **Score:** 2 ##### Several components are out of support **Score:** 0 #### How much business process depends on add-on or custom features that standard target-ERP functions do not cover? **Options:** ##### Very little **Score:** 10 ##### Some, with workarounds **Score:** 6 ##### Significant, needs redesign **Score:** 2 ##### Core processes depend on it **Score:** 0 #### Have you documented the add-on and integration inventory with owners? **Options:** ##### Yes, complete and current **Score:** 10 ##### Partly **Score:** 5 ##### Only in people's heads **Score:** 1 ##### No **Score:** 0 **Bands:** #### High dependency **Min:** 0 **Max:** 34 **Verdict:** Your system is tightly bound to add-ons, custom code and integrations. Migration will be driven by these, not by core financials. **Recommendations:** - Build a full inventory of add-ons, customisations and integrations before choosing a target - Rank each by business criticality and replacement option - Budget separately for replacement and rebuild work - Consider a phased move that isolates the riskiest integrations #### Moderate dependency **Min:** 35 **Max:** 59 **Verdict:** You have meaningful add-on and custom exposure with some gaps in documentation or ownership. **Recommendations:** - Confirm a successor or workaround for every add-on - Move source code into version control now - Document integration data flows and frequency #### Manageable dependency **Min:** 60 **Max:** 84 **Verdict:** Most of your processes are standard and the extensions are known. Planning effort should be modest. **Recommendations:** - Validate the few remaining add-ons against the target platform - Keep the inventory current through the project - Rebuild reports early to avoid late surprises #### Low dependency **Min:** 85 **Max:** 100 **Verdict:** You run largely standard functionality with little custom exposure, which keeps migration risk low. **Recommendations:** - Focus planning on data quality and cutover - Use standard target-ERP functions instead of recreating old customisations - Retire reports and integrations nobody uses ## Content **Intro:** 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. **Sections:** #### How to use the assessment **Body:** 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. **Bullets:** - 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 **Body:** 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 **Body:** 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 **Body:** 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. **Cta:** 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. **Faq:** #### What counts as an ISV add-on? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** 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. ## Search terms dynamics gp isv add-ons migration, gp third party modules, gp customization assessment, ax isv dependency, legacy erp integration inventory, gp to business central add-on replacement --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json