---
title: How to Audit Dynamics GP Customizations Before Migration
slug: how-to-audit-dynamics-gp-customizations-before-migration
date: 2026-06-22
author: Raaj
categories: [Microsoft Dynamics GP]
excerpt: "Step-by-step guide to auditing Dynamics GP customizations — Dexterity, ISVs, custom SQL, integrations, and reporting — before migrating to Business Central."
tldr: "Before migrating from Dynamics GP, systematically audit Dexterity chunks, ISV products, custom SQL, integrations, and reports — the Cloud Migration Tool skips all of them."
canonical: https://clonepartner.com/blog/how-to-audit-dynamics-gp-customizations-before-migration/
---

# How to Audit Dynamics GP Customizations Before Migration


Every Dynamics GP environment that has been running for 10–20 years has a customization problem: nobody has a complete list. Dexterity chunks were installed by a partner who left years ago. Someone wrote SQL triggers on the company database. An ISV product was added for a specific workflow, and the person who configured it is retired. A controller needed a custom posting report in 2012 and a developer modified a Dexterity form to make it happen.

If you do not inventory all of this before migrating to Business Central or another cloud ERP, undocumented customizations become data gaps, broken workflows, or silent data loss on day one.

**A Dynamics GP customization audit** is a verified inventory of every non-standard dictionary, modified form and report, SQL object, integration endpoint, and external report that touches GP data. Microsoft's Cloud Migration Tool moves standard GP data into Business Central online, but it does not inventory Dexterity dictionaries, modified windows, custom SQL, or reporting dependencies. <cite index="28-1,28-2">Customizations in Dynamics GP are not directly transferred. They are either rebuilt using Business Central extensions, replaced with standard functionality, or supported through third-party apps.</cite>

With GP mainstream support ending **December 31, 2029** and security patches stopping **April 30, 2031**, the migration window is narrowing. For the full timeline and risk analysis, see [The Ultimate 2026 Guide to Dynamics 365 On-Premise End of Life](https://clonepartner.com/blog/blog/dynamics-365-on-premise-end-of-life-2026-guide/). For the broader historical data strategy, see [Dynamics GP to Business Central: Migrating 20 Years of History](https://clonepartner.com/blog/blog/dynamics-gp-to-business-central-migrating-20-years-of-history/).

This guide walks through a systematic, step-by-step audit process that GP administrators and IT managers can execute against a live GP environment. It covers every customization layer — Dexterity, Modifier, VBA, VST, ISV products, custom SQL, integrations, and reporting — and explains the migration implications of each.

## Why a Dynamics GP Customization Audit Is the Most Critical Pre-Migration Step

Moving from Dynamics GP to Business Central is not a lift-and-shift. GP is an on-premise, segmented ERP built on a proprietary language (Dexterity). Business Central is a cloud-native, dimension-based platform built on AL extensions. Because Business Central Online is a true SaaS product, you cannot access the underlying SQL database directly. You cannot modify base application code. You cannot write custom stored procedures.

Every piece of custom logic in GP must be rebuilt as an event-driven AL extension, replaced by an AppSource application, or retired.

<cite index="21-9,21-10,21-11,21-12">The cloud migration tool migrates system and company setup, master data, and transactions table by table — and if a table fails or the schema does not match, the error is captured and migration moves to the next table.</cite> It does not migrate Dexterity customizations, VBA code, or custom SQL logic.

The practical consequence: if you have custom fields stored in ISV tables, custom stored procedures enforcing business rules, or modified forms capturing data that standard GP does not, the migration tool will skip all of it. Your finance team will discover the gaps in UAT — or worse, after go-live.

| Customization surface | Where to find it first | Migration implication |
|---|---|---|
| Dexterity chunk / dictionary | Customization Status, `Dynamics.set` | Rebuild in AL or replace with AppSource app |
| Modified form/report | `SY09200`, `SY10800`, `Forms.dic`, `Reports.dic` | Rebuild as BC page/report extension or retire |
| ISV module | `Dynamics.set`, Registration window | Find BC equivalent, rebuild, or archive |
| SQL proc/view/trigger | `sys.objects`, `sys.sql_modules` | Rewrite against BC APIs, extensions, or reporting |
| eConnect / GP Web Services / VST | Developer Toolkit footprint, AddIns folder | Replace with REST/OData API integrations |
| SSRS / MR / SmartList / Excel | Report Server, MR library, SmartList favorites | Rebuild against BC's data model |

A systematic audit prevents these failures by creating a definitive inventory of what exists, what is actually used, and what needs to be rebuilt. For the broader patterns behind data-layer migration failures, see [Why ERP Migrations Fail at the Data Layer: 9 Core Patterns](https://clonepartner.com/blog/blog/why-erp-migrations-fail-at-the-data-layer-9-core-patterns/).

## Step 1: Identify Dexterity Chunks and Modified Forms

**Dexterity** is the proprietary development environment that GP itself was built on. <cite index="6-1,6-2">Dynamics GP was written using the Dexterity programming environment, and Dexterity was designed so any modifications could appear to be part of Great Plains without touching source code.</cite> Any third-party product or custom enhancement built in Dexterity is distributed as a **.cnk (chunk) file** — a self-installing dictionary that adds or modifies GP functionality.

None of this code can be ported to Business Central. It must all be identified and either rewritten in AL or replaced.

### Check the Customization Status Window

Navigate to **Tools → Customize → Customization Status**.

<cite index="2-1,2-2,2-3,2-4">The Customization Status window lists the Dynamics GP modules and Dexterity-based ISV solutions or customizations that are installed and active. The problem with this window is that it is not always obvious which items are standard GP modules and which are ISV solutions or customizations.</cite> If you know the standard GP module list, you can pick out the non-standard entries. If you do not, proceed to the Dynamics.set file.

### Inspect the Dynamics.set File

<cite index="2-5,2-6">Locate the Dynamics.set file in `C:\Program Files\Microsoft Dynamics\GP` (or the application directory where you installed GP) and open it with Notepad. The Dynamics.set file is essentially the same list displayed in the Customization Status window, but it includes additional technical info such as the number of modules installed, the module IDs, and dictionary paths.</cite>

The file structure is straightforward: a count at the top, then pairs of module ID numbers and names, followed by three dictionary paths per module (main `.dic`, `FORMS.DIC`, `REPORTS.DIC`). Product ID `0` is standard GP. Anything else is an ISV product or a custom Dexterity dictionary.

<cite index="2-27,2-28">One thing to look for is whether GP is set up to use "shared dictionaries," meaning all workstations point to a single copy of a modified Forms.dic and Reports.dic. If the path for the FORMS.DIC or REPORTS.DIC differs from the Dynamics.dic line, it is a sign that GP is set up to use shared dictionaries, which usually means there are modified forms or reports.</cite>

Document every non-standard entry. For each one, record:

- Module ID and name
- Dictionary paths for `Dynamics.dic`, `Forms.dic`, `Reports.dic`, and any custom dictionaries
- Whether the Dexterity source code is available
- The vendor or developer who built it
- Whether the dictionary appears on every workstation or only on admin or power-user machines
- Whether it is actively used

> [!WARNING]
> Dexterity code **cannot** be ported to Business Central. BC uses the AL language and an entirely different extension model. Every Dexterity customization must be rebuilt as an AL extension or replaced with an AppSource app. If you do not have the source code, you cannot even analyze what it does — and <cite index="2-18,2-19">custom integrations developed using Visual Studio require the full source code to be upgraded. If a customer has switched partners, it may be difficult to get the source code.</cite> If a dictionary exists in `Dynamics.set` but nobody can explain what it does, assume it is live until testing proves otherwise.

### Check Customization Maintenance for Modifier and VBA

Navigate to **Tools → Customize → Customization Maintenance**.

<cite index="8-5,8-6">The Customization Maintenance window lists modified forms, modified reports, and custom VBA code and references that are active on the workstation.</cite> <cite index="5-17">If you have made customizations to GP using VBA, there will be a dot at the end of the window's page title.</cite>

Export any customizations as `.package` files for backup before migration planning begins. Ask the finance and operations teams if they still use the specific fields or logic contained within them — a modification built for GP 2010 may no longer be necessary in Business Central due to native feature updates.

## Step 2: Query System Tables for Alternate Forms and Reports Assignments

The Customization Status window tells you *what dictionaries are installed*. The system database tables tell you *what alternate forms and reports are actively assigned to users*.

The key tables are in the **DYNAMICS** (system) database:

| Table | Purpose |
|---|---|
| **SY09200** | Alternate or modified form and report ID master |
| **SY10800** | Alternate or modified form and report ID assignment master |
| **SY10500** | Role assignment master |
| **SY10600** | Tasks assignments master |
| **SY10700** | Operations assignments master |

<cite index="11-1">These security tables are in the DYNAMICS system database and store the master records and security assignments for alternate forms.</cite>

> [!WARNING]
> If legacy audit notes reference `SY01100` or `SY01200` for alternate form discovery, verify before relying on them. Microsoft identifies `SY01100` as the **Posting Account Master** — useful for understanding posting configuration, but not the right table for discovering alternate forms and reports. ([learn.microsoft.com](https://learn.microsoft.com/en-us/troubleshoot/dynamics/gp/frequently-asked-questions-role-based-security))

Run this query against the DYNAMICS database to join the Alternate/Modified Form and Report ID Master with the Assignment Master:

```sql
SELECT 
    a.USERID AS 'User/Class ID',
    a.DICTID AS 'Dictionary ID',
    b.PRODNAME AS 'Product Name',
    a.SECURITYID AS 'Security ID',
    b.Secrty_Name AS 'Resource Name',
    CASE b.RESTYPE 
        WHEN 2 THEN 'Form'
        WHEN 23 THEN 'Report' 
        ELSE 'Other' 
    END AS 'Resource Type'
FROM SY10800 a
INNER JOIN SY09200 b 
    ON a.DICTID = b.DICTID 
    AND a.SECURITYID = b.SECURITYID 
    AND a.RESTYPE = b.RESTYPE
WHERE a.CMPANYID > 0
ORDER BY a.USERID, b.RESTYPE, b.PRODNAME;
```

<cite index="18-8,18-9">The SECRESTYPE field represents the Resource Type: 2 = Windows, 23 = Reports.</cite> Any row where the Dictionary ID points to a non-standard dictionary represents customized behavior that users depend on.

If your GP environment went through old security conversions, also check for converted assignments that may still exist years later:

```sql
SELECT * FROM DYNAMICS.dbo.SY10800 WHERE SECMODALTID LIKE 'CNV%';
SELECT * FROM DYNAMICS.dbo.SY09200 WHERE SECMODALTID LIKE 'CNV%';
```

Many teams mistake these converted security artifacts for actively maintained customization sets. ([learn.microsoft.com](https://learn.microsoft.com/en-us/troubleshoot/dynamics/gp/frequently-asked-questions-role-based-security))

Cross-reference the query results against the Dynamics.set entries. If a dictionary appears in SY10800 but not in the Dynamics.set file on any workstation, you have an orphaned assignment — a configuration pointing to a dictionary that may no longer exist.

**Migration implication:** Every alternate form and modified report in these tables represents customized behavior that users rely on. Business Central uses a different object model — pages, reports, and extensions in AL — so treat each modified form or report as a functional requirement to re-implement or retire, not as an artifact that will come over during data load.

## Step 3: Inventory ISV Products and Third-Party Add-ins

GP environments commonly run ISV products from vendors like Binary Stream (multi-entity management), Mekorma (check printing), eOne SmartConnect (integrations), Nodus Technologies, KwikTag, and Panatrack. Some have built Business Central equivalents. Many have not.

<cite index="54-14,54-15">Increasingly more third-party products that companies using GP know and love — like KwikTag and Binary Stream MEM — have made their products available for Business Central.</cite> But this is not universal.

To build your ISV inventory:

1. **Review the Customization Status window and Dynamics.set** — every ISV product appears as a separate dictionary entry with its own module ID.
2. **Check the Third Party Products window** — accessible via **Help → About Microsoft Dynamics GP → Additional → Third Party Products** (path may vary by version).
3. **Query the DB_Upgrade table:** Run `SELECT * FROM DYNAMICS..DB_Upgrade` in SQL Server Management Studio. This table tracks the version numbers of every product installed across all company databases. It is the most reliable way to spot orphaned ISV tables that are no longer actively used but still hold historical data.
4. **Check your licensing** — ISV products often require separate registration keys. Your GP partner should have records of what was purchased.

An important detail: removing a GP feature does **not** remove its tables from the database. That is why old GP environments keep dead modules and live data side by side. ([learn.microsoft.com](https://learn.microsoft.com/en-us/dynamics-gp/installation/installing-additional-components?utm_source=openai)) If finance or operations says "we stopped using that years ago," verify at the SQL and reporting layer before you believe it.

For every ISV identified, determine:

- Does the vendor offer a BC AppSource equivalent?
- If yes, does the BC version support the same functionality?
- If no, can the functionality be replicated natively in BC or through custom AL development?
- What data does the ISV store in its own tables, and how will that data be migrated?

> [!NOTE]
> The Cloud Migration Tool can migrate ISV table data *only if* the ISV has published a BC extension that maps those tables. If the ISV has not published a BC migration extension, the data in those tables will be left behind unless you extract it separately.

If an ISV holds critical historical data — like custom tax calculations or specialized inventory attributes — that data must be explicitly mapped in your migration plan. For strategies on moving heavy transactional history, see [Dynamics GP to Business Central: Migrating 20 Years of History](https://clonepartner.com/blog/blog/dynamics-gp-to-business-central-migrating-20-years-of-history/).

## Step 4: Find Custom SQL Objects — Stored Procedures, Views, and Triggers

This is where most audits fail. Over a decade of GP usage, someone — a former DBA, a consultant, an internal developer — almost certainly wrote custom SQL objects directly on the company databases. Even Microsoft's own GP integration layer (eConnect) is built on SQL stored procedures and triggers. If the vendor's own tools are that SQL-heavy, assume your consultants were too.

These objects might include:

- **Stored procedures** for custom integrations or batch processing
- **Views** for reporting (SSRS, Crystal Reports, Excel)
- **Triggers** that fire on INSERT, UPDATE, or DELETE to enforce business rules or sync data to external systems
- **Functions** (scalar and table-valued) for calculated fields
- **SQL Agent Jobs** that automate data processing on a schedule

Run this query against each GP company database **and** the DYNAMICS database to find non-Microsoft objects:

```sql
SELECT 
    DB_NAME() AS DatabaseName,
    o.type_desc AS ObjectType,
    s.name AS SchemaName,
    o.name AS ObjectName,
    o.create_date,
    o.modify_date
FROM sys.objects o
JOIN sys.schemas s ON s.schema_id = o.schema_id
WHERE o.is_ms_shipped = 0
  AND o.type IN ('P', 'V', 'TR', 'FN', 'IF', 'TF')
ORDER BY o.type_desc, s.name, o.name;
```

This returns all user-created stored procedures (`P`), views (`V`), triggers (`TR`), and functions (`FN`, `IF`, `TF`). Standard GP objects typically use prefixes like `zDP_`, `ta`, or `sm`. Custom objects usually lack these prefixes or use company-specific naming conventions.

To find which objects reference specific GP tables, search the definitions:

```sql
SELECT 
    OBJECT_NAME(sm.object_id) AS ObjectName,
    o.type_desc AS ObjectType
FROM sys.sql_modules sm
JOIN sys.objects o ON sm.object_id = o.object_id
WHERE o.is_ms_shipped = 0
  AND (sm.definition LIKE '%SOP10100%'
    OR sm.definition LIKE '%RM20101%'
    OR sm.definition LIKE '%GL20000%'
    OR sm.definition LIKE '%PM00200%');
```

Replace those table names with the ones most relevant to your environment. Expand the search with your company database names, custom table prefixes, and SQL Agent job references.

Pay special attention to triggers on high-volume tables like `SOP10100` (Sales Transaction Work) or `RM20101` (Receivables Open Transactions). A custom trigger here often implies an integration with an external system — a warehouse management tool, a CRM, an e-commerce platform — that will break when GP is decommissioned.

> [!CAUTION]
> **This is a hard stop.** <cite index="59-11,59-12">Once you move to cloud-based Business Central SaaS, users can no longer access SQL Server directly. This means any reports or logic that query SQL Server directly will not work anymore.</cite> Every custom stored procedure, view, and trigger must be rewritten as AL code inside a BC extension, replaced by Power Automate flows, APIs, or Power BI datasets, or retired if the business logic is no longer needed. Business Central Online does not support `ExternalSQL` table types. ([learn.microsoft.com](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/webservices/web-services))

There is another hidden impact: Microsoft maps the main GP account segment to the Business Central account number and the remaining segments to dimensions. Any SQL report, trigger, or integration that parses GP account strings directly will need logic changes even if the business concept survives. ([learn.microsoft.com](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/administration/migrate-dynamics-gp))

## Step 5: Map eConnect, Web Services, and Visual Studio Tools Add-ins

GP integrations typically rely on three legacy technologies. All three are obsolete in the Business Central architecture.

### eConnect Integrations

<cite index="35-1,35-2,35-3,35-4,35-5">eConnect is a set of files, tools, and services that allow applications to integrate with Microsoft Dynamics GP data. eConnect contains a special set of SQL stored procedures installed in each GP company database. These stored procedures enforce the business rules and logic in GP to ensure that only valid data is imported.</cite>

eConnect is the backbone of most GP integrations. It relies on direct SQL Server connectivity and on-premise infrastructure.

To find eConnect integrations:

- Search for eConnect stored procedure calls in your application code (look for `taCreateSopHdrInsert`, `taRmTransaction`, etc.)
- Check the eConnect Integration Service configuration: `C:\Program Files\Microsoft Dynamics\eConnect\Service`
- Ask your development team about any .NET applications that reference `Microsoft.Dynamics.GP.eConnect` assemblies
- Document any custom pre/post procedures around eConnect calls

### Visual Studio Tools (VST) Add-ins

<cite index="2-11,2-12">Add-ins are DLL files developed using Dynamics GP Visual Studio Tools and Visual Studio .NET. These are customizations that can offer all of the power and flexibility of .NET, yet run within the context of Dynamics GP.</cite>

Check the AddIns directory:

```
C:\Program Files\Microsoft Dynamics\GP\AddIns
```

<cite index="2-13">By default, there are approximately 15 files installed in the AddIns directory, most of which are named "Microsoft.Dynamics.GP...", making them easy to rule out as customizations.</cite> Any DLL that does not follow the Microsoft naming convention is a custom or ISV add-in that needs to be documented.

### GP Web Services

If your GP instance has Web Services for Dynamics GP configured, document every endpoint and consumer. These services expose GP business objects over SOAP/HTTP and will not exist in a BC environment.

For each integration across all three layers, record the service accounts, credentials, authentication model, and the exact data payload moving through the endpoint. Every external application — your e-commerce storefront, your 3PL provider, your CRM — will need to be repointed to Business Central's REST APIs and OData V4 endpoints.

**Migration implication:** Business Central recommends REST APIs as the preferred integration path. SOAP support will be removed in a later release, and Basic Auth access keys are already unsupported in Business Central online. ([learn.microsoft.com](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/webservices/web-services)) GP integrations that depended on client events, in-process UI behavior, or long-lived state need redesign, not line-for-line translation.

If you use an execution tool like eOne SmartConnect or Scribe, log into those platforms and export a list of all active maps pointing to your GP SQL server. Treat SmartConnect as a **rebuild tool** on the target side, not a discovery tool — it does not replace the audit. ([eonesolutions.com](https://www.eonesolutions.com/blog/using-custom-business-central-apis-in-smartconnect/?utm_source=openai))

## Step 6: Document External Reporting — SSRS, Management Reporter, SmartList, and Excel

<cite index="57-1,57-2">Dynamics GP users have an overload of reporting options. The suite includes Report Writer, SQL Server Reporting Services (SSRS), SmartLists with SmartList Builder, Excel Reports, Crystal Reports, Management Reporter, Analysis Cubes for Excel, and ISV solutions.</cite>

Every one of these tools queries the GP SQL database directly. When you migrate, the underlying data model changes completely. GP uses a segmented chart of accounts (e.g., `GL10000` and `GL20000` tables); Business Central uses a dimension-based model (`G/L Entry` table).

### SSRS Reports

- Inventory all `.rdl` files deployed to your SSRS report server
- Identify which GP tables each report queries
- Flag reports that join to custom tables or views
- Document subscriptions and drilldown dependencies

<cite index="30-1,30-2">GP's reporting tools, built on SSRS or SQL, have no direct pathway into Business Central's modern reporting stack, which uses RDLC and Power BI. Every modified invoice, purchase order, or sales order must be rebuilt.</cite>

### Management Reporter

- Document all row definitions, column definitions, and reporting trees
- <cite index="56-14,56-15,56-16">Management Reporter is a reporting application used to create, maintain, deploy, and view financial statements, pulling directly from Dynamics GP. Note that Management Reporter will only be available until 2026.</cite> BC replaces this with Financial Reporting (Account Schedules) and Power BI.

### SmartList Favorites

- Export all saved SmartList favorites — these represent the ad-hoc queries your team relies on daily
- <cite index="53-10">SmartList is a much-loved tool in Dynamics GP that offers a central location where you can report and search on all aspects of your company data.</cite>
- Check for custom SmartLists built with SmartList Builder (query the `SLB` tables) or SmartList Designer (which can be built on SQL views)
- BC does not have a direct SmartList equivalent, though the newer Analysis Mode features offer similar functionality

### Crystal Reports and Excel Reports

- Identify any Crystal reports that connect to GP data via ODBC
- Document Excel reports that use refreshable Office Data Connection (ODC) technology to maintain a direct link to the company database — these are classic "nobody told the migration team" dependencies

> [!TIP]
> Start the reporting inventory early — it often takes longer than the data migration itself. For reporting requirements that are purely historical, Microsoft's GP Historical Snapshot in Business Central can land data in extension tables accessible via Power BI and Power Apps. That will not replace interactive GP-era workflows, but it can reduce the number of legacy reports you need to recreate one by one.

## The Audit Deliverable: Your Executable Migration Worklist

Do not stop at inventory. The output of this audit is a single document — typically a spreadsheet — that your implementation partner, your migration team, and your project sponsor can all reference.

Structure it with these tabs:

| Tab | Contents |
|---|---|
| **Dexterity & Modifier** | Every non-standard dictionary from the Dynamics.set file, with module ID, vendor, source code status, and active/inactive flag |
| **Alternate Forms/Reports** | SY09200/SY10800 query results mapped to dictionaries and assigned users |
| **ISV Products** | Each ISV product, its vendor, BC equivalent availability, and data table list |
| **Custom SQL** | Every non-Microsoft stored procedure, view, trigger, and function, with the GP tables they reference |
| **Integrations** | eConnect endpoints, VST add-ins, Web Services consumers, and what each integration does |
| **Reports** | Every SSRS report, Management Reporter definition, SmartList favorite, Crystal report, and Excel report, with owner and usage frequency |

For each item, assign one of four **dispositions**:

- **Rebuild** — required behavior, no acceptable native replacement
- **Replace** — a BC feature or AppSource app can take over
- **Retire** — no longer used, remove from scope
- **Archive** — historical access only, no live-process dependency

Every item should also have a business owner, criticality rating, validation method, and go-live dependency. If you cannot explain the business purpose of an item, flag it for user validation before design workshops begin. This is the exact point where an "unused" modified pick ticket turns out to be the warehouse's month-end control document.

This is also where you separate **data migration** from **application implementation**. A good implementation partner redesigns workflows in Business Central. A good migration team extracts GP data from standard tables, custom tables, and ISV tables without losing history or meaning. Those are related jobs, but they are not the same job. For the failure patterns that show up when teams blur them together, see [Why ERP Migrations Fail at the Data Layer: 9 Core Patterns](https://clonepartner.com/blog/blog/why-erp-migrations-fail-at-the-data-layer-9-core-patterns/).

## How ClonePartner Handles the Data Layer During Your ERP Migration

The customization audit tells you *what exists*. The next question is: what happens to the data those customizations created?

Your implementation partner handles converting GP business processes into BC-native workflows and AL extensions. That is their domain. The underlying data — the records in ISV tables, the transactions in custom fields, the historical data that standard migration tools skip — that is where ClonePartner comes in.

We extract data directly from GP's SQL Server, including custom tables and ISV-specific table structures. We transform that data to match Business Central's dimension-based architecture. And we load it via API with guaranteed accuracy and zero downtime. We work alongside your implementation partner so they can focus on building the new system while we handle the data heavy-lifting.

When you have 15–20 years of history, custom fields on every major transaction table, and ISV data that the Cloud Migration Tool ignores, that is exactly the kind of problem we solve.

<cite index="28-14,28-15,28-16">There are an estimated 15,000 companies in the U.S. still running Dynamics GP, but only about 40 qualified partners with deep experience executing GP to BC migrations at scale. With an average capacity of 2 migrations per partner per month, the entire ecosystem can complete roughly 1,000 migrations per year.</cite> If you wait, you are competing for scarce partner capacity.

Start the audit. Document everything. Then bring in the right teams for the right layers.

> Planning a Dynamics GP migration and not sure what data lives in your custom tables? ClonePartner handles the data extraction, mapping, and migration layer — so your implementation partner can focus on building, not digging through SQL.
>
> [Talk to us](https://cal.com/clonepartner/meet?duration=30)

## Frequently asked questions

### Can Dexterity customizations be migrated to Business Central?

No. Dexterity code cannot be ported to Business Central. BC uses the AL programming language and a different extension model. Every Dexterity customization must be rebuilt as an AL extension or replaced with an AppSource app.

### What GP system tables track alternate and modified forms?

The key tables are in the DYNAMICS system database: SY09200 stores the alternate/modified form and report ID master records, and SY10800 stores the assignment mappings that link those forms to users. SY10500, SY10600, and SY10700 handle role, task, and operations assignments respectively.

### Does Microsoft's Cloud Migration Tool migrate custom SQL objects from GP?

No. The Cloud Migration Tool migrates standard GP data table by table. Custom stored procedures, views, triggers, and functions in the GP company database are not migrated. Business Central SaaS does not allow direct SQL access, so all custom SQL logic must be rewritten as AL code, replaced with APIs or Power Automate flows, or retired.

### What happens to eConnect integrations when migrating to Business Central?

eConnect relies on on-premises SQL stored procedures and direct database connectivity. Business Central replaces this with REST-based OData v4 APIs and custom API pages built in AL. Every eConnect integration must be rewritten to use BC's API framework.

### How do I find custom stored procedures in a Dynamics GP database?

Query sys.objects in each GP company database filtering for user-created objects (is_ms_shipped = 0) with type codes P (procedures), V (views), TR (triggers), and FN/IF/TF (functions). Use sys.sql_modules to search object definitions for specific GP table references.