Microsoft Dynamics GP support ends in 2029. See migration options and how utilities move off GP without breaking the billing-to-ledger integration.
Microsoft Dynamics GP migration is the move off Microsoft's legacy Dynamics GP accounting system, which Microsoft is retiring, onto a supported replacement such as Dynamics 365 Business Central or another ERP. Microsoft has confirmed that Dynamics GP support ends on December 31, 2029, with security updates continuing only to April 30, 2031, so utilities that run GP as their financial system now have a fixed deadline to plan around. For a utility, the migration is not only an accounting project: GP is usually connected to the billing and customer information system, so the real risk is the billing integration that has to keep working when the accounting system underneath it changes.
Microsoft Dynamics GP, long known as Great Plains, has been a common accounting and general-ledger system for small and mid-size organizations, including many utilities. That era is ending on a published schedule. According to Microsoft's end-of-support announcement, mainstream support for Dynamics GP ends December 31, 2029, and security patches stop on April 30, 2031. Older versions reach their limits sooner, and Microsoft's stated direction is to move GP customers to Dynamics 365 Business Central.
For a utility, a deadline on the accounting system is not a back-office footnote. GP rarely stands alone. It is usually wired into the billing and customer information system that runs the utility day to day, which means the migration touches the systems that produce bills and post revenue, not only the ones that close the books.
Before planning a migration, it helps to be precise about what GP actually does for a utility, because that defines what the replacement and the integrations have to cover:
The billing and customer information system sits next to GP, not inside it. Meter reads, rate calculations, and customer bills are produced in the billing platform, and the resulting revenue and receivables are posted to GP through a general-ledger export or integration. That connection is the part of a GP migration a utility most needs to protect.
When you replace Dynamics GP, what happens to the interface that posts your billed revenue to the ledger?
Utilities on GP generally face three paths. Each has a different cost profile and a different effect on the billing integration:
There is no zero-work option, because support ending means staying on GP is a growing security and compliance risk rather than a stable choice. Whichever target a utility picks, the billing-to-ledger connection has to be rebuilt and revalidated, which is why the migration should be scoped from the billing side as well as the accounting side.
A GP migration for a utility works best when the billing integration is treated as a first-class part of the plan, not an afterthought discovered at cutover. Work through it in six steps:
The same discipline applies to any legacy migration, which is why the approach in migrating legacy utility systems to the cloud carries over directly: inventory the integrations, test on real data, and prove the result before cutover.
The data migration is usually the longest and riskiest part of a GP project. Utilities carry years of financial history, open receivables tied to customer accounts, and reconciliations that auditors expect to be traceable. Moving that cleanly means deciding what transfers in full, what is summarized, and what stays in an archive for reference.
The billing side of this has its own data concern: customer balances and billed-but-unposted revenue have to line up across the billing system and the new ledger on the day of cutover. This is the same care that utility software data migration demands on the customer-and-billing side, and the two migrations have to be reconciled against each other, not run in isolation.
Is your billing platform's ledger export locked to Dynamics GP, or can it point at whatever system replaces it?
This is the question that decides how painful a GP migration is for a utility. If the billing system's revenue posting was custom-built against GP specifically, the migration means rebuilding that interface from scratch, which is a project with cost and risk of its own. If the billing platform exports to accounting through a configurable general-ledger mapping and an open API, pointing it at Business Central or another ERP is a configuration task rather than a rebuild.
SMART360 is the billing and customer information side of this picture, not the accounting system. It produces bills, tracks revenue and receivables, applies GL mapping, and exports to an ERP; for full municipal accounting it integrates with an ERP partner rather than replacing one. That separation is the point during a GP migration: because the billing platform is not tied to GP internally, moving the accounting system underneath it does not require rebuilding how bills are produced. The utility changes the export target, revalidates the mapping, and keeps billing running.
Large organizations have finance teams and system integrators to run an ERP migration. A small or mid-size utility usually does not, which makes the GP deadline harder to absorb, not easier. The same lean staff that runs billing, meter reads, and customer service also has to plan the accounting move, and the window to do it without rushing is closing as the 2029 date approaches and experienced migration help gets scarcer.
The practical approach for a smaller utility is to treat the GP deadline as a reason to simplify rather than to rebuild the same complexity on a new platform. Separating the billing and customer system from the accounting system, and connecting them through a clean integration, means the next accounting change is a smaller event than this one. That is part of the broader case for modernizing legacy utility technology: fewer tightly-coupled systems, each replaceable on its own, instead of one migration that puts billing and accounting at risk together.
Microsoft has confirmed that mainstream support for Dynamics GP ends on December 31, 2029, covering product enhancements, tax and regulatory updates, and technical support. Security updates continue only until April 30, 2031. Older GP versions reach their support limits earlier, so organizations running them face deadlines before 2029. Microsoft's recommended path is migration to Dynamics 365 Business Central.
The main options are moving to Dynamics 365 Business Central, which is Microsoft's recommended successor, moving to a different ERP or accounting system, or moving to a municipal or utility-focused financial system. Each requires rebuilding the general-ledger structure and any integrations, including the connection that posts billed utility revenue from the billing system into the ledger.
In most utilities, the billing and customer information system posts revenue and receivables into GP through a general-ledger export or integration. When GP is replaced, that interface has to be rebuilt and revalidated against the new system. If the billing platform exports through a configurable GL mapping and an open API, this is a configuration change; if the integration was custom-coded to GP, it is a larger rebuild.
A GP migration typically takes several months to over a year, depending on the size of the organization, the volume of financial history, and the number of integrations. Because support ends in 2029 and experienced migration resources grow scarcer as more organizations move at once, utilities are generally advised to scope the project well ahead of the deadline rather than close to it.
Microsoft Dynamics GP migration is now a scheduled event, not an open question: support ends December 31, 2029, and utilities that run GP as their financial system have to plan the move. For a utility, the migration is more than an accounting change, because GP is usually connected to the billing and customer system that produces revenue. The utilities that come through it cleanly are the ones that scope the billing integration alongside the accounting move, migrate and reconcile the data on both sides, and prove a full cycle in parallel before retiring GP. Treating the deadline as a reason to separate billing from accounting, and connect them through a clean integration, turns the next accounting change from a crisis into a routine one.
Bynry Inc.
8 The Green STE.R,
Dover, Kent,
Delaware 19901
+1 732-630-0285
Bynry Inc.
Serene Tower, Pakharbaug
Pune, Maharashtra 411021
+91 93252-51217
