What if changing your GL didn't reset your FP&A to zero?

If your company is weighing a move off Dynamics GP, you've already seen the timeline, the license math, and the IT case for doing it. What the proposal probably didn't mention is what the migration does to finance.

The general ledger conversion itself is the part you can plan for. Chart of accounts remap, cutover date, opening balances, parallel run, sign-off. It's hard work, but it's bounded work. You can put it on a Gantt chart and watch it close out.

The part nobody puts on the Gantt chart is your FP&A model. Three years of driver-based revenue forecasts. A workforce plan at position level, with wage bands, overtime rules that differ by site, benefits and payroll tax by state. A dozen board views, each with a variance narrative that took a full close cycle to get right. The rolling forecast your CFO now opens in every leadership meeting. The budget your team just finished. All of it built, line by line, on top of GP data and a chart of accounts that is about to change underneath you.

Ask what the migration means for FP&A and the answer is usually some version of "we'll rebuild it once the new GL is live." Six months, give or take. Meanwhile your CFO expects the rolling forecast running the day the new system goes live, because the alternative is walking into a board meeting and explaining why the numbers went dark.

This piece is written for the Controller and the VP Finance who are quietly running the migration math and realizing the ERP quote is not the real cost. The rebuild is. And who want to know whether there is a version of a GL migration where the FP&A model stays put and the connector re-points to the new ledger.

‍

The migration cost nobody quotes

Every GL migration proposal has three cost lines. The software license for the new system. The implementation partner. The internal time from finance, IT, and operations to run the cutover.

None of those lines include what a Controller actually loses when the GL underneath the FP&A model changes.

The workforce model is the first casualty. Position-level budgets, wage bands, merit-increase rules, fringe calculations, payroll-tax logic by state or province. In an Excel-driven FP&A world, all of that is a set of formulas anchored to positions and to GL account codes. Change the account codes, break the formulas. A 240-position roster with six wage bands and multi-state payroll is a two-to-three-month rebuild for a two-person FP&A team.

Historical actuals are the second casualty. Three years of monthly actuals sitting in the master workbook, tied to the old chart of accounts. In the standard migration, those actuals are either re-exported and re-mapped by hand, or the team accepts that they are starting variance history over at year zero. The board reports that compared actuals to a three-year baseline lose the baseline.

Driver-based forecasts are the third. A rolling forecast that pulls current-month actuals, projects out 12 months on unit-driver assumptions, and reconciles back to the P&L is not a template. It is a chain of calculations built against specific GL accounts. When the accounts change, every driver-to-account tie breaks. Rebuild is measured in weeks.

Board views are the fourth. The variance narratives that took months to build. The layout the CFO now presents from every month. The consolidation logic across entities.

The 2026 budget the team just finished is the fifth. In the standard playbook, that budget gets ported into the new GL as a set of opening entries, and the model behind it, the assumptions and the driver logic, is retired.

None of this is in the ERP quote. It shows up 90 days into the migration, when the FP&A team realizes what they have to rebuild, and the CFO realizes the board pack is not going to be ready for the quarter after go-live.

The reason it shows up is not the ERP vendor's fault. The reason it shows up is that in most companies, the FP&A model lives inside the workbook set that sits directly downstream of the GL. When you replace the GL, you replace the address the workbook is pulling from, and everything that was anchored to that address needs re-anchoring.

‍

The FP&A layer is a separate address

Here is the mechanical claim: your FP&A layer does not have to live inside the GL, and it does not have to live inside a workbook chain that talks to one specific GL. It can live in an FP&A system that talks to whatever GL you point it at.

That distinction matters because it changes what a migration is.

If the FP&A layer is a workbook chain glued to a specific GL, a migration is a rebuild. If the FP&A layer is a separate FP&A system with its own model structure, its own driver logic, its own workforce module, and its own budget history, then a migration is a re-point. You change what the FP&A system is reading from. The model itself does not move.

That is what a purpose-built FP&A platform does, and it is the part of the argument that gets lost when people think about FP&A software as "better Excel" or "faster reporting on the ERP data." The point is not that the FP&A software is smart. The point is that the model has its own address, and its own persistence, independent of the ledger.

Concretely, in an FP&A system like Centage:

1. Your chart of accounts is a mapping table, not a hardcoded reference. The FP&A model uses its own account structure. The GL connector translates from the ledger's chart into the FP&A model's chart. When the GL changes, you update the mapping table. The model's account structure does not change.

2. Your workforce model lives at position level, not GL-code level. Every position has a wage band, a start date, a benefits load, a payroll-tax rule. Those attributes belong to the position, not to a GL account. They travel with the model. When the GL changes, positions still exist and still calculate. What changes is which GL account each position's expense rolls up to, which is again a mapping table.

3. Your driver logic is expressed as business drivers, not as cell references. Units × price × mix, headcount × fully-loaded cost, allocation percentages by fund or by department. These are model constructs. They reference GL accounts through the mapping, not directly.

‍4. Your budget and forecast history is stored inside the FP&A system. Prior-year actuals loaded into the FP&A cube stay in the cube. Prior-year budgets stay. Variance history stays. When the GL changes, that history does not evaporate.

5. Your board reports are queries against the FP&A model, not against the GL. Layouts, variance narratives, drill-throughs, consolidation groupings. All of them run against the FP&A system's own data, which is fed by the GL, not native to it.

Once you see the model as a separate address, the migration question becomes different. It stops being "how do we rebuild everything on the new system" and starts being "how do we re-point the connector and re-map the accounts."

‍

What actually happens when you re-point

The specific work of a GL re-point on a connected FP&A system is small enough to fit in a checklist.

Step 1. Stand up the connector to the new GL. For every GL that ships with a supported connector, this is a configuration step, not a project. Point the FP&A system at the new ledger's API or scheduled-file endpoint. Authenticate. Confirm actuals pull. For the receiving GL, this typically takes hours to a day. If the new GL is on the FP&A vendor's supported list, no custom work is required. If it is not, that is the vendor question you asked before you signed the vendor. (See our connector-tier interrogation blog for the questions that separate the two.)

Step 2. Re-map the chart of accounts. The FP&A system holds its own chart. The old GL had a mapping table into that chart. The new GL has a new mapping table into the same chart. Building the new mapping is the biggest single piece of work in the migration, and it is bounded: 500 to 5,000 account rows, depending on segment structure, mapped once, sanity-checked, signed off. A two-person FP&A team can complete this in one to two weeks for a mid-sized company. It is bounded because you already made the semantic decisions when you built the model the first time. You are not deciding what "Salaries and Wages" means. You are deciding which new GL account codes roll into the FP&A model's "Salaries and Wages" bucket.

Step 3. Pull historical actuals through the new connector against the new mapping. This is a batch job. The FP&A system loads whatever period of history the new GL can supply, translates through the new mapping, and stores the actuals in the FP&A cube. Typical range: 24 to 36 months of monthly actuals. Runtime: hours, not weeks. The output is that the FP&A cube now has the same trailing-history it had before the migration, translated through the new ledger's chart.

Step 4. Parallel-run for one close cycle. Run one month on both systems. Verify the actuals tie. Verify the workforce model still calculates. Verify the board reports render. This is the same parallel-run any responsible GL migration would have anyway, only now it also validates the FP&A layer.

Step 5. Cut over. The old GL turns off. The FP&A model keeps running. Budgets stay. Forecasts stay. Workforce model stays. History stays. What changed is the source system feeding the cube.

That is the entire re-point sequence. It is small because most of the work of an FP&A model, the structure of the chart, the workforce math, the driver logic, the layouts, the consolidation rules, was done when the model was built. The migration does not re-litigate those decisions. It re-maps them to a new set of account codes.

Worked example: a mid-size community-services nonprofit moving from QuickBooks Desktop to a modern cloud GL.

A community-services nonprofit with a $28 million operating budget, 12 program areas, and 22 restricted-fund grants ran its close on QuickBooks Desktop for 12 years. Their FP&A layer, built on Centage, handled the parts QuickBooks Desktop never could: the 22-fund allocation math, the position-level personnel budget with grant-restricted funding sources, the multi-year cost-per-participant rolling forecast the executive director takes to the board.

When the team decided to move the GL to a modern cloud ledger, they did not rebuild the FP&A model. They stood up the new connector, re-mapped the chart (about 900 GL accounts translated into the FP&A model's 240-line internal chart, done over eleven business days by a two-person FP&A team), pulled three years of historical actuals through the new connector, parallel-ran for one close, and cut over. The workforce budget did not move. The 22-fund allocation math did not move. The board reports did not move. The 2026 budget did not move. What moved was the ledger underneath.

Total FP&A-side work: about three weeks of one full-time equivalent, spread over the two-month GL migration window. Zero rebuild of the budget, the forecast, or the workforce model.

That is what a re-point looks like. That is the pattern the piece is about.

‍

Five things that survive, one thing you re-do

To be concrete, here is what survives a GL re-point on a connected FP&A system, and what you do again.

Survives:

• The workforce model at position level, including wage bands, benefits load, payroll-tax rules, and merit logic.  
• The driver-based revenue and expense forecast, including unit drivers, price assumptions, mix rules, and allocation percentages.  
• The historical actuals stored in the FP&A cube, translated through the new mapping.  
• The current-year budget and every prior-year budget still in the system.  
• The board reports, dashboards, and variance layouts.

Re-do:

• The chart-of-accounts mapping table. Once. Not the semantic model, just the crosswalk from new GL account codes into the FP&A model's internal chart. This is real work. A team of two, one to two weeks, for a mid-sized company. It is the entire delta.

That is the whole difference between a rebuild and a re-point. Five things survive because they live in the FP&A system's own model, at their own address. One thing gets re-done because it is the address translation between the new ledger and the FP&A model.

Kristi Goodgion, VP & Controller, Risk Strategies. Risk Strategies is a national insurance brokerage with a complex multi-entity structure and a finance team that runs FP&A against a mid-market ledger stack. Her verbatim on what the FP&A layer does:

‍"Centage replaced our former report writer and eliminated many of the technical issues and spreadsheet errors we faced. It removes manual calculations and reduces risk."

The read: her value isn't in a report generator that ties to one specific GL. It's in an FP&A layer that owns the model logic, so a change downstream in the GL, in a report writer, in an entity structure, doesn't require rebuilding the model. That is the same property that carries the model through a GL migration.

‍

The insurance case

Two facts about GL migrations are worth stating plainly.

First, most mid-market companies on legacy or on-prem GLs are not going to migrate in the next 18 months. On-premise ERP is a working setup that runs real businesses. The stack works, the numbers are right, the close finishes. There is no urgency here. Anyone selling you an FP&A tool on GL-death anxiety is selling from the wrong side of the pitch. (If you want the factual read on what Dynamics GP's and QuickBooks Desktop's lifecycle dates actually mean for a working close, we wrote that separately in Great Plains and QuickBooks Desktop both have end-of-life dates. Facts, no countdown clock.)

Second, if you ever do decide to migrate, the FP&A rebuild is the part that surprises the team, blows the budget, and drags the timeline. This is well-observed. It is not a scary story. It is a cost line that shows up 90 days in, because in the standard playbook, the FP&A model lives inside a workbook chain glued to the current GL.

Put those two facts together and continuity looks like an insurance argument. If you never migrate, the FP&A layer earns its keep on the same-day work: the automated actuals pull, the position-level workforce budget, the rolling forecast the CFO relies on, the board reports that finish in minutes. That is Centage's daily value regardless of what your GL is.

If you do migrate, the FP&A layer stays put. The GL underneath changes. Your model does not rebuild.

That is the shape of the campaign's message pillar #2. Not migration pressure. Not a countdown. A property of the architecture: the FP&A model has its own address, and that means it survives changes to what the model reads from.

The people who benefit from this framing today are Controllers and VP Finances at companies on Dynamics GP, Sage 100, Blackbaud Financial Edge NXT, MIP, QuickBooks Desktop, Epicor, Deltek, SYSPRO, Multiview, or Dynamics NAV, who are running the FP&A layer inside Excel and who are aware that at some point the GL question will come up. Not urgently. Just eventually. The question the piece answers is what happens to the FP&A model when it does.

If your FP&A model lives in a workbook chain today, the answer is: it rebuilds. That is the current cost of a future migration, priced in as a real number.

If your FP&A model lives in a connected FP&A system today, the answer is: it re-points. That is the continuity property. It is the reason to build the FP&A layer independently of the GL, whether or not you ever change the GL.

‍

Take-home

Continuity is not a sales pitch about migration. It is a property of where the FP&A model lives. When the model lives at its own address, in a system that connects TO the GL rather than living INSIDE the GL, changing the ledger becomes a re-point, not a rebuild.

If you want the specific vendor questions to ask, the tier-stack of connector types, and the checklist for interrogating any FP&A vendor about your specific GL, that is what our connector-that-holds blog covers. It is the technical companion to this piece.

If your migration math is starting to add up in ways that surprise you, run it properly. Get the Legacy-GL FP&A Integration Scorecard — tab three is the migration-continuity planner: line by line, what survives a GL switch and what gets rebuilt. Fill it in before anyone asks you to scope the FP&A side of the project.

‍

If you would rather talk it through, book a 15-minute call with a Centage FP&A operator who has worked a GL re-point end to end. Start with your actual model, not a slide deck.

Centage is FP&A software built for finance teams at growing mid-market companies. The model logic, the workforce module, the driver-based forecasting, and the board reporting sit in one connected system, with supported connectors into Dynamics GP, Sage 100, Blackbaud Financial Edge NXT, Dynamics NAV, SYSPRO, Elite, Multiview, and the modern cloud ledgers. Implementation is four to six weeks, finance-owned, no IT project. When your GL changes, the model stays put.