When the GL migrates, the driver model doesn't.
When the GL migrates, the driver model doesn't.
September 1, 2026
Your drivers were fine. Your on-prem GL isn’t going to be.
Especially if you’re on GP, Sage 100, or QuickBooks Desktop.
Welcome back to Bridging the Deficit, your go-to resource for financial planning insights, the kind you can actually use, not just theory.
This week: Microsoft has named a date for Dynamics GP’s end of life, and what that means for the driver model you built on top of it.
Microsoft has named a date for Dynamics GP’s end-of-life. Sage is pushing Sage 100 customers toward Intacct. QuickBooks Desktop sunsets in 2027. The number every CFO on one of those systems should be tracking isn’t the sunset date. It’s how many driver formulas underneath it are still pointing at accounts that won’t exist in FY28.
For a lot of finance teams, the honest answer to that question is “all of them.” Six years of driver models built on top of the same GL, layer on layer, with the working assumption that the accounts underneath weren’t going anywhere. Now the accounts are going somewhere. And the driver model doesn’t know yet.
The strange part is that the calendar feels fine. The driver model runs. Actuals tie. FY26 closed cleanly. The migration project is a distant thing on the FY27 IT deck. Kickoff in Q2, cutover in Q4. “Clean up planning tools” is listed as line item 14 on a 40-line plan. That line item is where a year of finance work either survives the transition or gets rebuilt from scratch on the other side.
In this issue:
- Three things break at the same time
- The portable driver layer
- What Centage does here, plainly
Three things break at the same time
The compound math is what makes it expensive. On an aging on-prem GL, three things quietly break at the same time once the migration date lands on the schedule.
First, chart-of-accounts drift.
Six years on the same GL, and nobody has touched the driver-to-account mapping since 2019. Half the account codes have been reused. A few have been split. The driver formulas don’t know that either.
Second, batch extracts, not live.
CSV or CIF, monthly, into a workbook. The drivers are already referencing month-old actuals in the healthy state; when the GL changes underneath, those extracts start returning fields that no longer exist.
Third, the migration itself.
New GL, new accounts, new dimensions, new schema. Every driver formula that hard-coded the old GL’s account codes becomes an FY28 rebuild the day after go-live.
Which is why “we’ll figure it out during the migration” is usually the most expensive answer available. The migration project already has fifteen priorities in front of the planning workbook. By the time anyone gets to line item 14, the finance team is out of runway and the plan year has already started.
That line item is where a year of finance work either survives the transition or gets rebuilt from scratch on the other side. Half of the finance leaders reading this know which line it is on their own IT deck. Most of them can’t tell you what would happen to their driver formulas if the GL changed underneath them tomorrow.
The portable driver layer
The finance leaders who make it through cleanly are the ones who built their driver model to not care which GL is underneath it. Three mechanics do most of the work.
1. Reference named business dimensions, never raw account codes.
Drivers point at “segment revenue” or “headcount by role” or “freight cost per shipped unit,” not at 4100-05 or Acct_Rev_Sub_West. When the accounts change, the drivers don’t. Every hard-coded account code in a driver formula is a landmine the migration will step on.
2. One mapping sheet, one place.
The connection between the driver’s named dimension and the GL’s actual account codes lives in exactly one tab. When the GL migrates, you re-point that one tab. Not forty-seven sheets. Not three hundred formulas. One tab, one re-point, one afternoon.
3. The 90-day migration dry-run.
Ninety days before cutover, rebuild the actuals feed against the target GL’s schema in a parallel workbook, and run last quarter’s driver model against it. If the drivers reproduce the numbers you already know, the migration is a two-week task. If they don’t, you have ninety days to fix it before the go-live weekend, not four hours in a hotel room the Sunday after.
The finance function with a seat at the migration decision is a different one from the finance function that inherits its consequences a year later.
What Centage does here, plainly
At Centage, we’re seeing the on-prem GL wave surface across every family: GP, Sage 100, Blackbaud FE NXT, MIP, QBD, Deltek, Epicor, SYSPRO. If you’re on one of those and the migration is on next year’s plan, the test worth running now is the 90-day dry-run in mechanic three. It costs a day and it either surfaces the landmines or gives you the receipt that they aren’t there.
- Driver logic that lives above the GL, using named business dimensions instead of raw account codes.
- One mapping sheet routes chart-of-accounts changes to every driver in one place.
- Actuals feed re-points against the target GL’s schema without touching the model.
- Finance-owned. No IT project. Four to six week implementation.
Not you. Not your team. The formulas that break in a migration are the workbook’s, not yours.
About Centage
Centage builds FP&A software for finance teams that have outgrown Excel. Budgeting, forecasting, reporting, and scenario planning in one place, connected to whichever GL you run.
Finance-owned. No IT project. Four to six week implementation. Used by 500+ mid-market and nonprofit finance teams.