Dynamics GP to Business Central With a Chart of Accounts Rebuild for a 450-employee Non-Profit
A grant-funded non-profit ran Dynamics GP with a 4-segment account code grown to 2,900 active accounts. We treated the move as a re-implementation, collapsed the segments into dimensions, and brought history as summary rather than detail.
About the Client
The Challenge
The finance director could not answer the question grant officers ask most — how much of this award is left — without opening a spreadsheet. GP held the numbers across a 4-segment account code where one segment meant fund, one programme, one the funder, and the fourth had changed meaning twice. Every restricted fund balance was assembled by hand from a SmartList export, taking 3 a month.
The code had also multiplied. A new grant needed a new segment value, segment values combined into physical accounts, and the chart had reached 2,900 active accounts, most holding a handful of transactions. Correcting journals were a standing line in the close checklist.
The organisation assumed there was an upgrade path. There is not. GP and Business Central share no data model, posting engine or account structure, so the move is a re-implementation with a data load attached, which puts the chart of accounts back on the table. The deadline needs stating precisely too, because the sector has compressed it into 'GP dies in 2029'. Dynamics GP 18.x carries two different end dates: enhancements and regulatory and tax updates stop on 31 December 2029, security updates run to 30 April 2031. The 2029 date is a payroll and tax compliance cliff, not an unpatched-system one, and planning to the wrong one moves the programme by a year.
The pressure to bring everything across came from a sensible place: auditors ask for prior year comparatives, programme managers want three years of spend on a grant. But migrating 2 years of detail means keeping the structure it was posted against — carrying the 4-segment code into Business Central and losing the reason for moving.
Our Approach
We separated two decisions people usually make together: what the chart of accounts should look like, and how much history to bring. The first, done properly, makes the second easy.
Chart of Accounts and Dimension Design (Weeks 1-5)
Took the 4 GP segments apart and asked what each was for. Natural account stayed as the Business Central G/L account and collapsed to 310 accounts. Fund, programme, funder, location and functional expense classification became dimensions. The shape of that decision is fixed: two global dimensions, written onto every ledger entry and usable as filters on reports, batch jobs and XMLports, plus up to eight shortcut dimensions surfaced as fields on journals, documents and entries. Changing a global dimension afterwards rewrites every posted entry, which is why a purpose-built logged batch process exists for it. We picked the two globals, fund and programme, against the reports the organisation is legally required to produce.
Fund Accounting Without a Fund Accounting Module (Weeks 4-9)
Business Central has no native fund accounting, and pretending otherwise is how these projects fail. Restricted and unrestricted net asset classes became a dimension with mandatory value posting on the relevant account ranges, so an unclassified posting is rejected at entry rather than found at close. Release from restriction runs as a journal between classes, award budgets as G/L budgets by dimension combination, shared costs through recurring journals.
Migration Tool Where It Fits, Manual Where It Does Not (Weeks 8-14)
We used Microsoft's GP cloud migration tool for customers, vendors, items and open transactions, after mapping its arithmetic. Ledger balances arrive as summary transactions per fiscal period, not posted detail, and years GP marks historical arrive open. Receivables and payables arrive as open items at remaining balance: a part-paid invoice migrates as the residual, with no payment history behind it. Unit of measure schedules have no target concept; only individual units migrate. It also decomposes the account code by itself — main segment to the G/L account, every remaining segment to a dimension — so left alone it picks your dimension model, including the segment whose meaning had changed twice. We drove the ledger through configuration packages and a mapping table instead: each GP account combination to one account plus a designed dimension set.
History Decision and Archive (Weeks 10-16)
Microsoft publishes no rule on how much history to bring. It publishes two mechanisms for keeping history out of the live ledger — an optional GP Historical Snapshot writing full transaction detail into extension tables under an Oldest Snapshot Year setting, and a copy of the GP database into Azure Data Lake Storage Gen2 — and leaves the choice to the customer. The 'bring two years' convention is partner practice, ours included, not documented guidance. We brought open receivables and payables at document level, open purchase commitments, and 2 of monthly ledger summary by account and dimension. Older detail went to Azure SQL with Power BI over it.
Parallel Close and Go-Live (Weeks 15-20)
Ran two month-ends in both systems. Parallel running is tedious and it is the only thing that finds what a test script will not: a posting group pointing at the wrong account, a dimension default missing on an occasional vendor, an allocation that rounds differently. Trial balance, aged receivables and payables, bank recs and every restricted fund reconciled before GP went read-only.
Solution Architecture
Chart of accounts: 310 natural accounts, with fund, programme, funder, location and functional expense carried as dimensions rather than segments
Dimension enforcement: Default dimensions on customers, vendors, items and G/L accounts, with mandatory value posting on restricted ranges so miscoding is blocked at entry
Fund and grant tracking: G/L budgets by dimension combination for award budgets, and the projects module for grant-funded delivery. Designed with our Business Central consulting team
History: Open items and 2 of summarised monthly ledger; full GP detail archived to Azure SQL and surfaced through Power BI
Reporting: Financial reports for the statement of financial position and statement of activities, plus a functional expense statement from the dimension set
Results
Client identity withheld under confidentiality. Figures are representative of engagements of this scope.
Technologies Used
Key Takeaways
If your organization is facing a similar challenge, here's what we learned:
Plan to two dates, not one. GP 18.x loses enhancements and regulatory and tax updates on 31 December 2029, security updates on 30 April 2031. The 2029 date is a compliance problem. Say which one you are planning against.
There is no GP upgrade path, and that is the good news. No shared data model means a re-implementation, so the chart of accounts, posting groups and approval routes are all back on the table. A lift-and-shift wastes the only chance you get.
Segmented accounts should become dimensions, not accounts. GP encodes analysis into the account code; Business Central separates the two. The migration tool makes that conversion for you, one dimension per leftover segment, unless you design it first.
Get the two global dimensions right the first time. Global dimensions are written onto every ledger entry, and changing one later rewrites all posted entries with the system locked. Choose them against statutory reporting.
Nobody publishes a rule for how much history to bring. Detail history forces you to keep the structure it was posted against. Open items, summarised comparatives and old detail archived somewhere queryable is our recommendation, not a documented one. Our Dynamics 365 consulting plans assume two parallel cycles.
Related Case Studies
Planning a Move Off Dynamics GP?
The chart of accounts decision and the history decision shape everything else in a GP replacement. We work both through before quoting a timeline.