Will Your GP Customizations, Reports, and Add-Ons Survive a Migration?

Why this is the question that derails migrations late, not early

Most GP migration conversations start with dates and budgets, and only later does someone ask the question that actually determines how painful the project will be: what happens to the custom report the AP team built in 2016, the ISV module that handles your commission calculations, or the modified sales order screen your team has used for years? Assuming these will "just carry over" is one of the most common and most costly mistakes in a GP to Business Central migration. This post walks through the realities of Dynamics GP customizations migration: what typically survives, what doesn't, and how to find out before it becomes a surprise mid-project.

What the Cloud Migration Tool actually does

Microsoft's Cloud Migration Tool handles standard GP tables and open transactions reasonably well, but it has real limits worth understanding upfront. Historical data gets placed into separate snapshot tables rather than becoming live, workable Business Central records, which means it's visible for reference but not something you can transact against going forward. The tool also does not migrate ISV or custom tables, and some GP structures, such as Unit of Measure Schedules, have no direct equivalent in Business Central at all. None of this means the tool is broken; it means it was built for a specific, standard scope, and your environment almost certainly extends beyond that scope somewhere. That said, it is a common practice to bypass the use of this tool and go through the effort to perform an export of the relevant data from GP so that it can be imported into Business Central.

ISV add-ons: three different outcomes, and you need to know which is which

Assuming your GP add-ons, whether for payment processing, advanced reporting, warehouse management, or eCommerce connections, will transfer seamlessly is a costly mistake. In practice, every ISV module you rely on falls into one of three categories. Some are no longer necessary because Business Central includes native functionality that replaces or improves on what the add-on did in GP. Others require an updated, Business Central-specific version from the same vendor, which may involve new licensing and configuration work. And some are no longer maintained at all; in certain cases, the ISV product doesn't even exist in the Business Central environment, which forces a genuine rebuild or a different vendor altogether. Auditing every ISV add-on against these three outcomes before scoping the project is the single most effective way to avoid a mid-migration surprise.

Custom reports need to be rebuilt, not migrated

Because Business Central's reporting model is structured around dimensions rather than GP's report writer or SmartList Builder approach, custom reports generally cannot be exported and dropped into the new system. Each one needs to be recreated using Business Central's reporting tools, which is a real opportunity as well as a cost: it's a natural point to retire reports nobody actually opens anymore and rebuild only the ones your finance team genuinely relies on. If your team has invested in a dedicated BI & Reporting layer, this rebuild is best planned in parallel with the migration rather than treated as an afterthought once the core system is live.

Customizations and modified screens: expect a redesign, not a port

Deep customizations to GP screens or workflows, built through Dexterity, Modifier, or VBA over the years, don't have a direct migration path because Business Central's extensibility model works differently from GP's. This is usually where organizations with a long GP history face their biggest scope decision: replicate the old customization exactly in the new platform, or use the migration as the moment to ask whether that customization is still solving a real problem. If the functionality of the customization is still needed, then an assessment is needed to determine if Business Central's native functionality can be used, an ISV should be considered, or if some level of customization is ultimately required. In many cases, teams find several long-standing customizations were compensating for a GP limitation that simply doesn't exist in Business Central.

A practical audit before you scope the project

You can list every ISV add-on currently in use and its vendor's Business Central roadmap status. You can flag every custom report by owner and by how often it's actually opened. You can identify every screen modification and the business reason it was originally built. You can note any GP structures, like Unit of Measure Schedules, that have no direct Business Central equivalent. Running this audit before requesting a migration quote turns a vague "will everything transfer" worry into a concrete list your Dynamics GP services partner can scope against, which is also the single best way to keep a migration budget from moving after the project has already started.

A clear-eyed Dynamics GP customizations migration plan is what separates a smooth Business Central move from a mid-project scramble. If you'd like a second set of eyes on your ISV, reporting, and customization inventory, contact us before you request a firm quote.

Frequently Asked Questions

Will we lose our historical transaction data?

No, but it changes shape. Historical data is typically migrated into snapshot tables for reference and reporting rather than as live, transactable records in Business Central. Most finance teams find this sufficient for audit and lookback purposes, but it's worth confirming against your specific compliance needs early.

Do all of our ISV add-ons need to be replaced?

Not necessarily. Some become unnecessary because Business Central natively covers the same function, some need an updated Business Central-specific version, and only some genuinely have no path forward. The only way to know which applies to your specific add-ons is to check each one against its vendor's current roadmap.

Can we just export our GP reports and import them into Business Central?

No. The underlying reporting models are different enough that reports need to be rebuilt in Business Central's tools rather than imported directly. This is a good opportunity to prune reports that are no longer useful rather than rebuilding everything by default.

What happens to customizations built specifically for our business?

They typically need to be redesigned rather than ported directly, since GP's customization tools (Dexterity, Modifier, VBA) don't map one-to-one onto Business Central's extension model. Many organizations discover during this process that a customization was compensating for a gap that Business Central already closes natively.

How early should we start this audit?

Before requesting a firm migration quote, not after. Customization, report, and ISV inventories directly drive cost and timeline in any Dynamics GP customizations migration, so doing this work early prevents the scope and budget from shifting once the project is already underway.

References

This post draws on published guidance about the Cloud Migration Tool's data handling and ISV migration pitfalls from ERP Software Blog, Rand Group, and related Dynamics 365 migration analyses, alongside Microsoft's own Dynamics GP and Business Central documentation.