Dynamics GP End of Support: What to Do Before 31 December 2029

When does Dynamics GP support end, and what stops on each date?

There are two dates, and they mean different things. Microsoft ends Dynamics GP support for enhancements, tax updates and technical support on 31 December 2029, with security updates until 30 April 2031. Both come from Microsoft's Dynamics GP lifecycle page, which is worth bookmarking rather than relying on a date quoted secondhand.

Nothing switches off on either day. GP keeps posting, your data stays where it is, and users keep logging in. What ends is the supply of tax changes, new capability and help from Microsoft, and later the security patches. For a finance system that is a slow but real risk: the tax update you do not receive, or the vulnerability that stays open, is the one auditors ask about. Your own servers, SQL Server and add-ons run on their own support clocks, and the earliest of all those dates is your real deadline.

Who should be planning a move off Dynamics GP now?

Anyone who will still depend on GP at the end of 2029. In practice that means the people below, and the sooner they share one plan the easier it gets.

• Finance directors and controllers at companies running Dynamics GP, who own the tax, audit and close risk.
• IT leads who run the GP servers, SQL Server and the integrations around them.
• Companies with GP and an on-premises CRM side by side: the same deadline thinking applies to Dynamics 365 on-premises end of life.
• Microsoft partners with GP clients who need more Business Central capacity: Solzet works white-label inside your delivery process.
• Running Dynamics NAV rather than GP? The NAV to Business Central migration checklist is the right starting point.

What are the realistic options for Dynamics GP customers?

Five, and only one of them is staying put. The right one depends on how well GP fits the business today, how clean the data is and whether the company has outgrown a mid-sized ERP.

How does the cloud migration from Dynamics GP to Business Central work?

Dynamics GP data from GP 2015 and later can be migrated to Business Central online with the built-in cloud migration tool, and a historical GP snapshot can also be migrated. That makes the data route the best-documented part of the move. The work around it is where projects succeed or struggle.

The tool moves data. It does not decide what your add-ons become, rebuild your customisations, redesign your integrations or retrain your users, so those run as their own workstreams alongside the trial migrations. If you run a GP version older than GP 2015, check Microsoft's current guidance for your version; the assessment then settles whether an upgrade within GP or a clean Business Central implementation with selected data is the shorter route.

• Set up the Business Central online environment and the companies that will receive data.
• Clean GP master data first: duplicate customers and vendors, inactive items and accounts, and records nobody can explain.
• Run a trial migration into a test environment, not the production one.
• Reconcile with GP: trial balance, customer and vendor open items, inventory quantities and values.
• Repeat until the trial is uneventful, then run the final migration at cutover.
• Decide whether the historical GP snapshot comes across, or whether GP stays read only for history.

Should a GP company move to Business Central or Finance and Operations?

For most GP customers, Business Central. Business Central is Microsoft's ERP for small and mid-sized organizations, covering finance, sales, purchasing, inventory, projects, manufacturing, warehouse and service management in one system, and it is the target of the GP cloud migration tool. Finance and Operations is Microsoft's ERP family for larger and more complex organizations: Dynamics 365 Finance, Supply Chain Management, Commerce, Project Operations and Human Resources capabilities. A GP company that has grown into several legal entities across countries, or into deep production and warehouse processes, should assess it before committing.

What happens to GP add-ons, customisations and integrations?

Each one gets a decision, and the decisions are the real scope of the project. Business Central extensions are written in AL, using the AL Language extension for Visual Studio Code, so anything custom that the business still needs is rebuilt as an extension rather than carried across. Third-party add-ons are replaced by their vendor's Business Central app where one exists, often found on Microsoft Marketplace (AppSource), or by standard functionality or an alternative app.

Integrations are redesigned around Business Central APIs, because Business Central online runs in the Microsoft cloud rather than on the network where GP sat. If you run Dynamics 365 Sales, Business Central connects to it through the Dataverse connection, and the Business Central Virtual Table app exposes Business Central data in Dataverse without copying it; the CRM side is covered on our Dynamics 365 Customer Engagement consulting page. If your CRM is a custom-built CRM rather than Dynamics 365, the same Business Central APIs serve it.

How should the move off Dynamics GP be planned?

Backwards from a go-live date you choose, not forwards from whenever the project happens to start. Eight steps, in order; each one produces what the next needs.

1. 1

   Inventory what you run on GP

   List the GP version, companies, modules in daily use, third-party add-ons, customisations, reports, integrations, users by role and the servers underneath, with the support date of each piece.

2. 2

   Choose the target and confirm the fit

   Decide between Business Central online, Business Central on-premises and Finance and Operations using company size, entity structure, supply chain depth and where the data must live.

3. 3

   Decide every add-on and customisation

   For each one, choose standard Business Central functionality, an app from Microsoft Marketplace (AppSource), an AL extension or retirement, and write acceptance criteria for whatever is rebuilt.

4. 4

   Decide the data scope

   Agree which companies, how much detailed history, whether a historical GP snapshot comes across, and what is cleaned before the first trial migration.

5. 5

   Pick the go-live date

   Choose a period boundary, ideally a year end or quarter start, that leaves room for at least one fallback date before 31 December 2029.

6. 6

   Run trial migrations and test

   Migrate into a test environment, reconcile balances and open items with GP, test whole processes, extensions, documents and integrations, and finish with user acceptance by key users.

7. 7

   Cut over and train

   Rehearse the cutover, freeze GP, run the final migration, reconcile and sign off, train users by role and support the first period-end close.

8. 8

   Keep GP read only, then retire it

   Keep GP available read only for history and audit questions for an agreed period, then archive the data and retire the servers.

What is the risk of leaving the GP decision until close to the deadline?

Every GP customer faces the same two dates, so the people who can do the work get busier as they approach. Waiting rarely makes the move smaller, and it removes the room for a second attempt if the first go-live date slips.

• Tax updates from Microsoft end on 31 December 2029, which matters most to companies that rely on them.
• A late start leaves no fallback date before the deadline if testing finds problems.
• Add-on vendors set their own plans for GP, and each one can move your deadline earlier.
• The people who know how your GP was configured may not be around by then.
• A rushed migration tends to carry old workarounds across instead of retiring them.

What can a GP customer do in the next month?

Small, useful steps that every path needs, whichever option you choose later.

• Write down every GP support date that applies to you, plus the support dates of your servers, SQL Server and add-ons.
• List the add-ons and ask each vendor about its Business Central plans.
• List the integrations, with an owner for each.
• Ask finance which reports and spreadsheets the close depends on.
• Freeze new GP customisation, so the scope stops growing.
• Book a fixed-scope assessment, so the decision rests on your estate rather than on general advice.

How does Solzet help Dynamics GP customers move?

Solzet implements Dynamics 365 Business Central online, builds AL extensions and integrations, and migrates companies from Dynamics NAV, Dynamics GP, 1C and other ERPs. A GP engagement starts with a fixed-scope assessment that produces the first four planning steps for your estate: the inventory, the target and fit, the decision for every add-on and customisation, and the data scope. The written output stands on its own.

Delivery then runs the trial migrations, the AL extensions, the integrations, testing, cutover and training, with a decision point at the end of each phase. The same team designs the CRM side when you run Dynamics 365 Customer Engagement, so customers, orders and invoices mean the same thing in both systems. Where Finance and Operations is the better fit, we implement that instead. The service is described on migration to Business Central, and the rest of our guides are in the guides library.