Dynamics GP to Business Central Migration: What AP Needs

On 25 September 2024, Microsoft confirmed that Dynamics GP is reaching the end of its product support and has announced two major deadlines:

1. December 31, 2029: Product enhancements, regulatory updates, and technical support will end
2. April 30, 2031: Security updates and patches will end. 

Microsoft is ending Dynamics GP support as it continues to focus its innovation and investment on cloud solutions and technologies. It is encouraging GP customers to transition to Dynamics 365 Business Central, which offers cloud-based capabilities, AI tools, and security features. 

With Dynamics GP product support ending in some years, users now have a defined deadline to plan and complete their migration to Business Central. Before defining the project scope, confirm two points:

• Which lifecycle policy applies to your GP version, since older releases may have earlier end-of-support dates
• How your AP process will operate during and after the transition, because AP is one of the functions that’s most affected by an Enterprise Resource Planning (ERP) change and is often addressed too late

This guide covers the complete migration timeline, what Microsoft's cloud migration tool transfers, what it leaves behind, the step-by-step migration process, and the AP considerations most migration plans overlook.

The Timeline: What Microsoft Has Actually Committed To

The deadline for Dynamics GP customers is December 31, 2029. On this date, Microsoft will end product enhancements, regulatory updates, tax updates, service packs, and technical support for GP. Security updates will continue until April 30, 2031, giving organizations additional time to plan and complete their move to Business Central.

Caption: Dynamics GP Sales and Support Timeline

With the dates confirmed, the focus shifts to migration scope: what Microsoft’s cloud migration tool transfers from Dynamics GP and what must be configured or rebuilt for Accounts Payable.

What the Migration Tool Moves, and What It Does Not

The migration tool moves key GP financial and operational data into Business Central, including vendor records, outstanding Payables transactions, open purchase orders, and selected historical data. However, AP workflows and processes still need to be configured separately for the new Business Central environment. 

Here’s a more detailed breakdown of what moves and what doesn’t: 

Caption: What Moves From Dynamics GP to Business Central 

The migration tool gets the underlying AP data into Business Central, but it does not recreate the AP operation around that data. That makes the pre-migration planning phase critical, particularly for workflows, approvals, invoice intake, and document access. 

A Pre-Migration Checklist for AP

Before migrating, Accounts Payable AP teams should review their current data, open transactions, workflows, and approval processes. 

The following pre-migration checklist will help you identify what will move to Business Central and what needs to be configured separately: 

• Document your current approval matrix: Record thresholds, exceptions, and delegation rules. These configurations do not migrate. Rebuilding them from memory can create gaps.
• Confirm which lifecycle policy applies to your GP version: Older Fixed Lifecycle releases have earlier end-of-support dates, and support for some versions has already ended.
• Inventory every integration connected to AP: Include bank files, positive pay, payment providers, Electronic Data Interchange (EDI), and Independent Software Vendor (ISV) add-ons. Determine whether each integration must be reconfigured, replaced, or rebuilt.
• Decide the retention plan for invoice images and approval history: These records may require a different approach. A database copy in Azure Data Lake may retain the data, but it does not provide the same experience as a searchable document archive.
• Agree on a single invoice intake point during the parallel run: GP stays live while Business Central is read-only, so invoices need one unambiguous destination.
• Decide migration scope early: Pick your oldest historical year and company list, since scope drives replication time.
• Establish baseline AP metrics: Record your current cost per invoice and processing cycle time so you can measure improvements after migration.
• Check the cutover window against your financial close and audit calendar: Avoid month-end or year-end close, audit periods, and scheduled Business Central environment updates to reduce operational disruption.

Completing these checks before migration gives AP a clearer view of what needs to migrate, what needs to be rebuilt, and what needs to be decided before cutover. This preparation makes the migration easier to plan and validate. 

Dynamics GP to Business Central Migration: Step by Step

Microsoft’s recommended migration process for Dynamics GP to Business Central Online covers assessment, preparation, setup, data replication, upgrade, validation, and go-live. 

The steps below break down these stages with a focus on AP: 

Step 1: Migration Assessment

What Happens:

Microsoft’s migration assessment tool reviews your GP structure, flags likely problems, and gives you migration options based on what it finds. Run the assessment early to understand potential migration issues, available migration paths, and project complexity.

For AP, use this stage to:

• Review your vendor master for inactive, duplicate, or incomplete records
• Identify open invoices, credits, and other outstanding payables
• Check how vendor classes and posting accounts are currently configured
• Flag AP customizations or integrations that may need to be rebuilt in Business Central

Step 2: Preparation

What Happens:

Build the migration plan, covering timeline, resources, and approach. Verify prerequisites, including the GP 2015 or later requirement. Clean and validate the source data before migration, as inaccurate or incomplete GP data can create issues in Business Central.

For AP, prepare by:

• Defining who owns AP data cleanup, testing, approvals, and sign-off
• Reviewing vendor addresses, payment terms, posting accounts, and bank information
• Resolving old or incorrect outstanding transactions before migration
• Documenting AP workflows and integrations that need to work on day one

Step 3: Cloud Migration Setup

What Happens:

No business data is migrated during this phase. Running the Cloud Migration Setup assisted setup guide in Business Central Online establishes the connection between your on-premises database and the online environment, creates the replication pipeline, and lets you select the companies to migrate. Data is copied only when you initiate replication.

Before moving forward:

• Confirm the AP companies are included in the migration scope
• Make sure the required users and permissions are configured
• Establish the sandbox environment for your first migration run
• Keep GP as the operating AP system until the migration is complete

Step 4: Company Migration Configuration

What Happens:

Select the companies and the specific data to migrate. This is where you choose your oldest historical year and configure which records and data to migrate. 

For AP, confirm:

• Whether all vendors or only active vendors should migrate
• Which historical AP data needs to remain accessible
• Whether vendor class posting accounts should migrate as vendor posting groups
• Whether 1099 information and amounts need to be included
• Whether open purchase orders should be migrated

Step 5: Data Replication

What Happens:

Selecting Run Migration Now copies your Dynamics GP data to Business Central Online. After replication, you can review the results, resolve any issues, and rerun the process as needed before completing the data upgrade. Microsoft recommends testing the migration in a sandbox environment before running it in production.

During the AP test migration:

• Compare vendor counts between GP and Business Central
• Check open invoice balances and transaction types
• Verify vendor addresses, payment information, and posting groups
• Check open POs and remaining quantities
• Record discrepancies and resolve them before the production run

Step 6: Data Upgrade

What Happens:

On the Cloud Migration Management page, select Run Data Upgrade. Before proceeding, confirm that data from every company in scope has been replicated to the online database.

After the data upgrade completes successfully, you cannot replicate data again from an earlier version. Doing so could corrupt the online database by mixing upgraded and non-upgraded records.

Before running the upgrade:

• Confirm that all companies have finished data replication
• Complete your AP reconciliation checks from the sandbox migration
• Resolve migration errors before proceeding
• Confirm that AP users know when the system will be unavailable for normal processing

Step 7: Data Validation

What Happens:

Validation compares the source data in GP against migrated data in Business Central and reports discrepancies. It can run automatically after migration or manually whenever you want.

Validate AP specifically by checking:

• Vendor master records and addresses
• Open AP documents and remaining balances
• Vendor bank account information
• Vendor posting groups and related General Ledger (GL) accounts
• 1099 data, where applicable
• Open POs and outstanding quantities.

Step 8: Completion and Follow-up

What Happens:

Configure the new environment, set up user access and permissions, then go live and decommission the on-premises deployment.

Before AP goes live:

• Confirm AP users have the correct Business Central roles and permissions
• Test invoice entry, approvals, posting, payments, and reporting
• Verify AP integrations and downstream processes
• Reconcile migrated AP balances against GP
• Define a clear cutoff for AP processing in GP and the start of processing in Business Central

Once the migration is complete, AP should be able to process invoices, approvals, payments, and reporting in Business Central without relying on GP. The final checks should confirm that the entire AP process works correctly before GP is retired.

5 Common AP Migration Risks 

AP migration risks usually come from inaccurate vendor data, unreconciled transactions, undocumented workflows, and AP processes that aren't ready for the new ERP. Identifying these issues before migration gives your team time to fix them before they affect testing or go-live. 

1. Approval Workflows Are Not Fully Documented

Approval rules built up over years in Dynamics GP can include amount thresholds, departments, locations, vendors, and exceptions. If those rules are not documented before migration, some invoices may be routed incorrectly or sit without an approver.

How to Reduce the Risk:

• Document approval rules by department, amount, entity, or location
• Identify exceptions and backup approvers
• Test those rules against actual invoices and different approval scenarios 
• Recreate and test the workflows in the AP automation system before go-live

2. Invoice Intake is Unclear During the Transition

During a parallel run, vendors may continue sending invoices to the same email address or submission channel while the new ERP and AP process are being configured. Without a clear intake process, the same invoice can enter two systems or fail to reach the AP team.

How to Reduce the Risk:

• Decide where vendors should send invoices during the transition
• Define which system is responsible for capturing and processing invoices
• Set a cutoff date for the old process
• Test invoice routing from receipt through approval before go-live

3. Historical Invoice Documents Are Not Accessible After Migration

Moving vendor balances and open transactions does not necessarily mean the invoice images and supporting documents attached to those records are available in the new ERP. AP may still need those documents for audits, payment questions, or vendor disputes.

How to Reduce the Risk:

• Identify which historical invoices and supporting documents need to remain accessible
• Decide whether they will be migrated, retained in GP, or moved to a separate document repository
• Confirm that users can search and retrieve those records before decommissioning GP
• Keep approval records and supporting documentation with the corresponding invoice where required

4. AP Integrations Are Not Tested Before Go-Live

Payment files, bank connections, remittance information, and other integrations may depend on the existing GP setup. If those connections are not tested with the new ERP and AP workflow, payments can be delayed after cutover.

How to Reduce the Risk:

• List every system connected to the current AP process
• Identify which integrations need to be rebuilt or reconfigured
• Test payment files, bank processes, and remittance workflows end to end
• Include AP integrations in user acceptance testing rather than treating them as a post-go-live task

For a new ERP connection, integration design, data mapping, testing, and validation may require additional planning.

5. AP Changes Too Much at the Same Time

An ERP migration already requires AP staff to learn a new system. Changing invoice intake, approval rules, document access, and payment processes at the same time can make it harder to identify where problems are coming from.

How to Reduce the Risk:

• Separate ERP changes from AP process changes where possible
• Document the new invoice workflow before training begins
• Give AP users time to test common scenarios in the new system
• Monitor invoice processing, approvals, exceptions, and payment timing after go-live
• Address workflow problems quickly rather than redesigning the entire AP process at once

Most of these risks can be reduced before go-live with better documentation, testing, and clear ownership. The goal is to ensure AP knows what's changing before the first invoice reaches Business Central. 

What Changes for AP After Moving to Business Central 

The biggest AP changes are in how invoices are captured, approved, reported, and stored. Business Central replaces several GP tools and workflows, but it still leaves gaps around invoice capture, exception handling, and document management that AP teams need to address during implementation. 

The table below compares the AP capabilities available in each system.

Caption: AP capabilities compared between Dynamics GP and Business Central 

Before switching from GP, test each AP process in Business Central and document where native functionality is sufficient and where additional tools are required. 

Should You Automate AP Before, During, or After the Migration?

The best time to automate AP depends on your migration stage:

• Before migration: Best when there is enough time to configure and test AP workflows before moving to Business Central.
• During migration: Suitable when AP automation must be designed alongside the new ERP environment.
• After migration: Practical when go-live is close, and the current AP process can continue temporarily.

Let’s look at each option below.

1. AP Automation Before Migration

Automate before the migration when you have six or more months before go-live, and your current AP process is already causing problems. You can build and test approval workflows, document the process, and give the AP team time to get comfortable with the new workflow while Dynamics GP is still familiar. By the time Business Central goes live, the AP process is already established.

2. AP Automation During Migration

Automate during the migration when the project is already underway, and your AP challenges are significant enough to justify the additional work. This approach can align AP automation with the new ERP design, but it requires clear ownership and coordinated testing because both systems are being configured simultaneously.

3. AP Automation After Migration

Automate after the migration when go-live is approaching, the migration budget is already committed, and your invoice volume is manageable enough to continue with the existing process temporarily. This can work, but plan for the transition cost. You may need to configure temporary approval processes in Business Central and then replace or extend them when AP automation is introduced.

What to Look for in AP Automation During a GP Migration

Choose an AP automation solution that can support both Dynamics GP and Business Central without forcing teams to rebuild workflows, lose document access, or change invoice intake during migration. Evaluate the following capabilities before selecting a solution.

• ERP independence: The automation layer should work with GP today and Business Central tomorrow, without a reimplementation in between. If a solution supports only one ERP, it may need to be replaced or significantly reconfigured during migration.
• Configuration portability: Ask directly whether approval workflows, user roles, vendor preferences, and routing rules carry forward when the ERP underneath changes. 
• A document archive that lives outside the ERP: Since invoice images and approval history do not migrate, the archive must exist in a system that is not being replaced. This also avoids having to keep a read-only GP instance solely for document access.
• One intake point for invoices: Whatever handles capture should be the single destination for invoices regardless of which ERP is currently live. This helps keep invoice intake consistent during the parallel-run period.
• Reference customers who have done this transition: Ask for references from customers who moved from GP to Business Central while running the vendor's product. That experience is more relevant than references from customers using Business Central alone.
• Predictable cost at your volume: Per-invoice pricing can behave unexpectedly during a migration when invoice volumes, testing, and reprocessing increase. Make sure you understand how those activities affect your costs.

Dynamics GP to Business Central Migration implementation doesn't have to add another layer of complexity to the migration. MetaViewer is available as a cloud-based or traditionally licensed solution, with MetaViewer experts providing implementation support. This gives teams flexibility to choose an approach that fits your IT environment and migration plan.

Book a Demo to see how MetaViewer can support your AP process through the move from Dynamics GP to Business Central 

FAQs

1. How long does a Dynamics GP to Business Central migration take?

The timeline depends on the number of companies, data volume, customizations, integrations, and how much process redesign is required. A straightforward migration can take a few months, while more complex environments can take considerably longer. 

2. How much does it cost to migrate from Dynamics GP to Business Central?

There is no standard migration price. Cost is driven by factors such as the number of users and companies, historical data requirements, customizations, integrations, and the amount of process redesign required. AP automation, document retention, and integration work should be considered separately when building the overall migration budget.

3. What happens to GP customizations when moving to Business Central?

Customizations should be assessed individually rather than copied automatically. Some can be replaced by standard Business Central functionality, while others may need to be rebuilt as extensions or redesigned. Some legacy customizations may no longer be necessary in the new system.

4. Can a company migrate to Business Central without moving all of its GP customizations?

Yes. In fact, migration is an opportunity to review whether each customization is still necessary. A customization can be retained, replaced with Business Central functionality, redesigned using an extension, or retired if the underlying business requirement has changed. 

5. What happens to GP vendor-specific settings after migration?

Vendor records can migrate, but AP teams should verify how vendor defaults, posting groups, payment terms, bank information, and other settings map to Business Central. Some GP behaviors are handled differently in Business Central, so vendors with complex payment or posting requirements should be tested rather than assumed to work identically after migration