The 2028 Deadline: What IT Leaders Need to Know About Dynamics GP End-of-Life and Azure-First Migration Paths

Dynamics GP's mainstream support end date is approaching, and that means IT leaders responsible for their organization's ERP infrastructure need to make a decision — not eventually, but within the next 12–18 months. After mainstream support ends, you're on extended support: security patches only, no new features, no regulatory updates, no tax table refreshes, and escalating costs for an increasingly limited support experience.

If you're the IT leader who will be answering the question "what's our plan?" when the CFO or CEO asks — and they will ask — here's what you need to know and what you need to start planning for now.

What Changes After Dynamics GP Mainstream Support Ends?

The shift from mainstream to extended support isn't a cliff — it's a slow erosion that affects every layer of your ERP environment:

• No feature updates: Tax table changes, regulatory compliance updates (1099 forms, payroll tax rates, state reporting requirements), and functionality improvements stop completely. Your finance team will need to handle these manually or through third-party workarounds — each one adding cost and risk.

• Security risk increases significantly: Patch frequency drops, and on-premise servers become a larger attack surface. GP environments typically run on Windows Server with SQL Server — both of which require their own patching cadence. When Microsoft stops actively developing for GP, the security attention that platform receives diminishes with it.

• Third-party ISV support erodes: Independent Software Vendors who build add-ons for GP (payment processing, advanced reporting, warehouse management, eCommerce connectors) stop certifying their products for unsupported versions. Some ISVs have already announced end-of-support timelines for their GP modules. When your payment processing add-on stops working after an OS update and the ISV says "we no longer support that version," you're in a difficult position.

• Talent availability shrinks: Fewer consultants maintain GP skills as the market moves to D365. The consultants who do still work on GP charge premium rates — we've seen 25–40% increases in GP-specific consulting rates over the past three years. Your internal team members with deep GP knowledge are also aging out, and replacements aren't learning GP in school or in early-career roles.

  
  

What Is the Azure-First Migration Path from GP to Business Central?

Microsoft's recommended path for GP customers is migration to Dynamics 365 Business Central — a cloud-native ERP built on Azure. This isn't a like-for-like upgrade; it's a platform shift.

Here's what IT needs to evaluate:

Data Migration

Microsoft provides built-in migration tools specifically designed for GP-to-BC transitions. These tools handle master data (chart of accounts, customers, vendors, items), open transactions (receivables, payables, purchase orders, sales orders), and configuration data. Historical transactional data requires a decision: migrate selectively for reporting continuity, archive to a read-only SQL database, or move to Power BI for historical analysis. Most organizations choose a hybrid — migrating 2–3 years of transaction history and archiving the rest.

Customization Assessment

This is where most IT leaders underestimate the work. Every GP environment accumulates customizations over its lifetime — modified reports, custom SmartList objects, VBA integrations, Dexterity modifications, eConnect configurations, third-party add-ons. Each one needs to be inventoried and classified:

• Standard in BC: Many GP customizations exist because GP lacked functionality that BC includes natively. Bank reconciliation automation, approval workflows, dimension-based reporting, and multi-currency handling are all built into BC. These customizations don't need to be migrated — they need to be retired.

• Power Platform alternatives: Customizations that automated specific business processes often map cleanly to Power Automate flows or Power Apps applications. A custom GP integration that pushed data to a third-party system via a scheduled SQL job can typically be replaced with a Power Automate connector in hours, not weeks.

• Custom AL development: A smaller subset of customizations — typically deep business logic embedded in the ERP — requires development in BC's AL language. These should be evaluated for whether the underlying business need still exists before rebuilding them.

Integration Mapping

Document every integration point in your current GP environment. For each one, identify the method (ODBC, eConnect, web service, flat file, manual), the direction (inbound, outbound, bidirectional), the frequency (real-time, scheduled, batch), and the owner (who maintains it when it breaks). BC's API surface covers most integration scenarios through standard REST APIs and OData endpoints. Custom ODBC connections and eConnect integrations need to be replaced with standard connectors — which is additional work upfront but dramatically reduces maintenance long-term.

Infrastructure Decommission Plan

Moving to cloud-native BC eliminates a significant infrastructure footprint: SQL Server licensing (often $15,000–$40,000 annually for mid-market deployments), Windows Server licensing and patching, physical or virtual server hardware on a 4–5 year refresh cycle, backup infrastructure and management, and disaster recovery environments. Your IT team gets that management capacity back for higher-value work.

What Does the 5-Year Total Cost of Ownership Comparison Look Like?

When you model TCO over five years — hardware refresh cycles, SQL licensing, server administration time, patching, backup management, DR testing, consultant rate increases, plus the opportunity cost of features you can't access — cloud D365 Business Central typically breaks even with legacy GP in year 2 and delivers 30–40% lower total cost by year 5.

The variables that affect your specific number: how many customizations require AL development, how many integrations need rebuilding, how much historical data you migrate, and whether you run a phased rollout or a single cutover. A structured assessment with a Microsoft partner can model these variables for your environment in 2–3 weeks.

The Window to Migrate Comfortably Is Closing

A GP-to-BC migration typically takes 4–7 months of active implementation for mid-market organizations. Add 2–3 months for discovery and planning. If you haven't started the assessment, the window to complete a comfortable, well-planned migration before the support deadline is narrowing.

The organizations that will have the hardest time are the ones that start planning after the deadline pressure hits — when every Microsoft partner's calendar is full of other GP customers who waited just as long.

Start the assessment now while you have scheduling flexibility and negotiating leverage.

Take Turnkey's free Dynamics 365 Suitability Assessment to map out what your specific GP environment needs.