Great Plains and QuickBooks Desktop both have end-of-life dates. Here's what they actually mean for your FP&A, whether you stay or go.

Great Plains and QuickBooks Desktop both have end-of-life dates. Here's what they actually mean for your FP&A, whether you stay or go.

It's 2:17 PM on a Tuesday. Rebecca, Controller at a 180-person specialty-chemicals distributor in western Pennsylvania, is sitting through her second Microsoft partner call this month. Great Plains has run the close at her company for 22 years. She inherited it in 2013. Two Controllers before her built the chart of accounts. Three of the five people in Finance still write it as "GP" in their notes, not "Dynamics GP."

The partner is pointing at a Microsoft lifecycle page and using the phrase "modern lifecycle." He mentions Business Central. He mentions a fixed-fee migration package. He mentions a customer of theirs who moved off GP in 14 months.

Rebecca is not panicking. She is not in a rush. What she is doing is math. GP still closes her books cleanly on business day six every month. Her FP&A model lives in a 17-workbook Excel chain that pulls trial balances out of GP each cycle. Her CFO is comfortable with the current cadence. Her IT director has never once flagged GP as a problem system. Her audit partner has zero issues with it. The system works.

What Rebecca is actually trying to figure out is whether Microsoft's dates mean she has to make the migration decision this quarter, next year, or in three years. And separately, whatever she decides about the ERP, what should she do about the fact that the FP&A layer stacked on top of it is aging faster than the general ledger ever will.

This piece is written for the Controller and the VP Finance running Great Plains, or QuickBooks Desktop, or another on-prem ledger that has a published sunset window on it. It is not written to sell you on migration. Both Microsoft and Intuit have posted the lifecycle dates on their own product pages, and both sets of dates are calmer than the sales calls make them sound. What follows is what the dates say, what the dates do not say, and where inside this decision your FP&A layer sits, so you can pull it out and think about it separately.

‍

What Microsoft actually said about Dynamics GP

Microsoft's Dynamics GP announcements in 2024 named specific things. Some of them are worth quoting in the language Microsoft used.

Microsoft communicated that Dynamics GP is entering a "no new versions" phase. The product continues to receive security updates. Mainstream support winds down through the late 2020s on Microsoft's Modern Lifecycle schedule; extended support (security patches only) continues after that. Microsoft is not turning the servers off. Microsoft is not disabling licenses. What Microsoft is stating is that Dynamics GP has reached the end of active feature development, and that new roadmap investment is going into Business Central.

For a Controller reading this in 2026, the practical read is straightforward. Great Plains will run in its current form for the next several years of active support and a further stretch of security-only support. It will not receive new features, new Microsoft-authored integrations, or new versions. If your bank feed breaks, if your tax table needs an update, if a security patch requires a hot fix, Microsoft is contractually obligated to service you inside the extended-support window. What Microsoft is not obligated to do is add anything new.

That is a slow, published, orderly sunset. It is not a fire drill.

The reason it feels like a fire drill on the partner calls is that the Microsoft partner channel is compensated to move customers off GP earlier than the lifecycle dates require. The reseller earns implementation revenue on the Business Central migration. The advisor earns bill hours on the transition. The channel partner earns subscription commission on the cloud license. None of them is fabricating the dates. Each of them is stacking urgency on top of them, because their P&L runs on migration events, not on customers running the same GL for another six years.

Your P&L does not run on migration events. Your P&L runs on a clean close, an accurate variance narrative, a defensible board pack, and a workforce budget that ties out to your payroll system. Great Plains delivers those things today. It will deliver them for as long as Microsoft keeps servicing the extended-support tail. Whether you migrate at year three, year five, or year seven is a decision about your business. It is not a decision about whether the servers will keep running.

‍

What Intuit actually said about QuickBooks Desktop

Intuit's QuickBooks Desktop announcements over 2023 and 2024 traced a similar shape.

Intuit stopped selling QuickBooks Desktop Pro Plus and Premier Plus to new subscribers after September 30, 2024. QuickBooks Desktop Enterprise moved to a subscription-only sales motion. Existing users continue to receive renewals inside the discontinuation window for their specific product version. QuickBooks Desktop's 2022 product line reached end-of-service on May 31, 2025. Subsequent versions carry their own timelines, with a widely-discussed 2027 window for the most-installed Enterprise release currently in market.

The read on this is the same as GP. Intuit is steering its base toward QuickBooks Online and, for larger customers, toward Intuit Enterprise Suite. The desktop product line is not disappearing tomorrow. It is being wound down over several years. A community-services nonprofit on QuickBooks Desktop Enterprise 22 is not going to lose access on May 31st. What they are going to lose is the ability to buy an incremental year of support past whichever renewal cycle their license carries.

If you are on QBD Enterprise today with a 2024 or 2025 renewal, you have a working system through at least 2026 and often through 2027 depending on your version. That is a two-to-three-year decision window. It is a business calendar. It is not a countdown clock.

‍

The two decisions the announcements force, and neither of them is FP&A

For a Controller running Great Plains or QuickBooks Desktop today, the vendor lifecycle sets two decisions on the calendar. Not one. Not urgent. Two, both worth taking seriously and both worth taking separately.

Decision 1:

Do we stay, or do we go? Staying means paying for extended support (or the equivalent Intuit-side renewal), budgeting for a future migration in a specific target year, and treating GP or QBD as the working ledger for the intervening period. Going means picking a target platform (Business Central, Sage Intacct, or NetSuite in the mid-market; QuickBooks Online for the smallest customers; Intuit Enterprise Suite for larger QBD shops), sequencing an implementation project over 6 to 18 months, and running a cutover with parallel-run and sign-off. Both are legitimate answers. Neither is forced by the mainstream-support end date.

The signal for staying: the current system delivers a clean, on-time close; there is no strategic driver (M&A, entity restructuring, a cloud mandate from a parent company) forcing the platform change; the migration budget could be redirected to higher-impact projects; the finance team is stable and knows the current system deeply. Many mid-market Controllers will hear themselves in that description.

The signal for going: a compelling event (acquisition, ERP consolidation across a group, a board mandate); the current version has known reliability issues (a patched Citrix stack, an unstable payroll module, custom integrations built by a developer who left in 2019); the CFO is comfortable with the migration cost line and the disruption; there is a defensible timeline that lands the cutover outside a critical planning cycle. Also legitimate.

The choice is a strategic business decision about where the finance function is going over the next five years. It is not a security ranking of the two paths. Both carry real cost. Both carry real risk. Both are decided on the ERP's own merits, on your business's own calendar.

Decision 2:

What FP&A layer should sit above whichever ledger you end up with? This is the separate decision. Notice that it is separate. If you stay on GP, you still need a working FP&A layer to close the manual workbook gap the current setup depends on. If you go to Business Central, you still need a working FP&A layer, because Business Central is a general ledger, not an FP&A platform. Either way, the FP&A question arrives. Either way, "keep the Excel chain" is not the same answer as "pick a platform."

That the FP&A decision is separate from the ERP decision is the point most partner conversations miss. The partner is selling the ERP move. The advisor may be selling the ERP move. The reseller is definitely selling the ERP move. None of them is selling you FP&A. Their pitch tends to assume you will rebuild your FP&A model as part of the migration, inside the new ERP's reporting tools, and re-do everything you spent years building in Excel. That assumption is expensive. It is where 40 to 60 percent of the migration's real cost hides.

‍

What the stay path looks like

For the Controller who has decided to keep Great Plains or QuickBooks Desktop in place through the extended-support window, the FP&A question is straightforward. You already know your GL works. What you are trying to close is the manual gap between the ledger and your board pack.

Every legacy on-prem GL has the same shape. It holds actuals. It runs the trial balance. It closes the books when the Controller signs off. What it does not do is planning, forecasting, driver-based revenue modeling, position-level workforce budgets, or 12-view board packs. Those pieces have always lived in Excel. On Great Plains. On Sage 100. On Blackbaud Financial Edge NXT. On MIP. On Elite. On Multiview. On QuickBooks Desktop. On SYSPRO. On Deltek. The general ledger was never the actual problem. The workbook chain glued to the ledger is the problem.

That workbook chain has a specific failure mode. A manual trial-balance export from GP into a master workbook every month. Formulas that break silently when a new GL account gets added. A rolling forecast that lives in one power-user's head. A close that takes six to ten business days because most of the time is manual assembly, not manual thinking. Fear that a number on the board pack is wrong and nobody would know until the auditor found it.

Fixing that failure mode does not require moving the GL. It requires connecting the current GL to a purpose-built FP&A layer that pulls the trial balance automatically, holds the model outside the ledger, and produces the board pack in minutes instead of days. That layer works on Great Plains today. It will work on Great Plains for as long as Great Plains is running on the server. The switching cost of the FP&A layer is 4 to 6 weeks of finance-owned implementation. That is one order of magnitude smaller than the 12-to-18-month cost of a full ledger migration.

For the operator-level detail of what a monthly close looks like inside a connected FP&A layer on Great Plains, Blackbaud Financial Edge NXT, or MIP, we wrote that separately in What a monthly close actually looks like on a legacy GL. That is the technical companion to the stay path.

‍Jenny Barker, Senior Budget Manager, HASCO. HASCO is a public housing authority that budgets more than 6,000 individually-tracked line items across its portfolio. Its general ledger is Elite, a legacy on-prem ledger that carries a native connector to Centage. Her verbatim on the actuals pull:

‍"I hit a couple of buttons, wait a few minutes and all my actuals data comes right into Centage."

The read: HASCO is not migrating off Elite. Elite runs the ledger. Centage runs the FP&A layer above it. The two systems talk on a schedule the Budget Manager controls. The 6,000-line-item board pack pulls actuals from Elite on-demand, into a Centage model Jenny built and maintains. That is the stay configuration in one sentence. The ledger keeps running. The FP&A layer connects to it. The manual assembly disappears. Whether the same organization decides in five years to move off Elite is a question about Elite, not a question about the FP&A layer.

‍

What the go path looks like

For the Controller who has decided to move, on a near-term calendar or a defined multi-year plan, the FP&A question changes shape but does not go away.

The standard playbook is: pick the new ERP, run the implementation, cut over the ledger, and then rebuild the FP&A model in the new ERP's reporting tools or in a fresh workbook chain against the new chart of accounts. That playbook works. It is also where the FP&A rebuild cost hides. The ERP quote covers the license, the partner, and the internal cutover. It does not cover the FP&A rebuild. That line item surfaces 90 days into the project, when the finance team realizes the workforce model, the driver-based forecast, the historical variance library, and the board pack are all glued to the old GL's account codes.

The alternative playbook is smaller. Move the FP&A layer to a purpose-built platform now, before the migration is committed, on top of the current GL. Get a working setup that closes cleanly, produces the board pack automatically, and holds the model at its own address (not glued to the ledger). Then, when the ERP migration runs, the FP&A layer stays put. The connector re-points to the new ledger. The chart-of-accounts crosswalk gets rebuilt. The workforce model, budget, forecast, and board views all persist. What moves is the source system feeding the FP&A cube. What does not move is any of the FP&A logic your team spent years building.

Doing this now, before the ERP migration is committed, has two effects. First, you get the FP&A benefit today: the automated close, the position-level workforce budget, the on-demand board pack. That benefit accrues from day one, whether the ERP migration ever happens or lands in year five. Second, if the migration does happen, you eliminate the FP&A rebuild line item entirely. Both effects are real. Neither depends on the migration timeline you eventually choose.

For the mechanical detail of what a GL re-point actually looks like on a connected FP&A system, we wrote that in a separate piece: What if changing your GL didn't reset your FP&A to zero?. The short version: five things survive (workforce model, driver logic, historical actuals, budgets, board reports); one thing gets re-done (the chart-of-accounts crosswalk). That is the entire delta of a re-point. It is the technical companion to the go path.

And before you sign an FP&A contract on either path, the connector-that-holds interrogation piece covers the 12 questions to ask any FP&A vendor about your specific general ledger. On the stay path, the questions matter because the connector is the whole point. On the go path, the questions matter because the connector is what makes the re-point work.

‍

The FP&A decision runs on its own calendar

The reason to separate the two decisions is that they run on different timelines, carry different budgets, produce different outcomes, and answer to different stakeholders. Merging them creates one large project that stalls when either half runs into trouble. Keeping them separate lets each move at its natural pace.

The GL decision is a five-year decision. It should be paced to your business's strategic calendar. Mainstream support ending, sales channels being wound down, and vendor pricing shifts are inputs. They are not the whole picture. If Great Plains works and there is no strategic driver for migration, hold. If a compelling event lands (acquisition, entity restructuring, a genuine reliability failure), move. Either way, decide on the ERP's own merits.

The FP&A decision is a much shorter-cycle decision. It is a 4-to-6-week implementation, finance-owned, running against whichever GL you have today. It pays back in the first close cycle after go-live: the manual assembly disappears, the board pack shortens, the workforce budget catches errors before the auditor does. The FP&A decision does not require the ERP decision to be made first. It runs on whichever ledger you have today. It survives whichever ledger you land on tomorrow.

Deferring the FP&A decision because you might migrate is a false economy. If you stay, you carry the Excel workbook chain for another five years, and every close cycle is manual. If you migrate in two years, the FP&A rebuild inside that migration project is bigger than the standalone FP&A implementation would have been today, because you now have to rebuild AND retrain your team AND coordinate with the ERP cutover. In both scenarios, the earlier FP&A decision pays back sooner.

Rebuilding FP&A during the migration is a false convenience. Migration projects are already complex. Migration cutovers are already pressured. Board committees expect the finance function to produce the same-quality reporting the day after cutover as the day before. Layering an FP&A rebuild on top of an ERP cutover creates a stack of coincident risk that experienced Controllers avoid.

The clean sequencing runs the other direction. Get the FP&A layer right now, on top of whichever GL you have today. Make the ERP decision on its own merits, whenever your business needs to make it. When the ERP does move, re-point the FP&A layer. The model persists across the change.

‍

Take-home

The Microsoft and Intuit lifecycle dates are real, and they are calmer than most partner calls make them sound. Great Plains and QuickBooks Desktop are being wound down slowly, with published support windows that give most mid-market users a multi-year horizon to make the ERP call on their own timing. That call is a real decision. It is not the only decision. It is not the most urgent one.

The more urgent decision, for most Controllers running an on-prem legacy ledger today, is the FP&A layer stacked on top. Excel workbook chains fail silently, consume the close cycle, and depend on one person's memory. Fixing that failure mode does not require moving the general ledger. It requires a purpose-built FP&A platform that connects to the current ledger, holds the model at its own address, and comes with you if the ledger ever changes.

If you are running the stay-or-go math on Great Plains or QuickBooks Desktop right now, our companion pieces cover the technical details on both paths: the close cycle on a legacy GL, the connector-tier interrogation checklist, and the FP&A migration continuity mechanics. Each is a companion to a different piece of this decision.

Before your next partner call, take the questions with you. Get the Legacy-GL FP&A Integration Scorecard — twelve questions to ask any FP&A vendor about your specific ledger, plus a migration-continuity planner for the stay-or-go math this piece walks through. It is a worksheet, not a pitch, and it takes about ten minutes to fill in.

‍

If you would rather talk it through, book a 30-minute call with a Centage FP&A operator who has worked customers down both paths. Either way, start with your close calendar, not a partner slide deck.

Centage is FP&A software built for finance teams at growing mid-market companies. The model logic, the workforce module, driver-based forecasting, and board reporting sit in one connected system, with supported connectors into Dynamics GP, Sage 100, Blackbaud Financial Edge NXT, Dynamics NAV, SYSPRO, Elite, Multiview, PeopleSoft, Dynamics 365 Business Central, Sage Intacct, and NetSuite. Implementation is four to six weeks, finance-owned, no IT project. Whether you stay on Great Plains for the next five years or migrate next quarter, the FP&A layer stays with you.