Dynamics GP Migrations · Canada
Dynamics GP has an end date. Your Canadian payroll has an earlier one.
Microsoft has set the clock on Great Plains. New licences are gone, and regulatory updates stop at the end of 2029. For Canadian sites running GP Canadian Payroll, that is the date the CRA tax tables stop arriving. We move Canadian organizations off GP to QuickBooks with full history, reconciled per entity, and client data processed in Canada throughout.
Plan backwards from your year end, not forwards from the deadline.
The Clock
The four dates Microsoft has published
None of these are rumours or partner speculation. They are Microsoft’s own lifecycle dates for Dynamics GP.
| Date | What happens | What it means for you |
|---|---|---|
| 1 April 2025 | End of sales for new perpetual licences | Already passed. No new perpetual GP. |
| 1 April 2026 | End of sales for new subscription licences | Already passed. Existing customers can add users but cannot buy new instances. |
| 31 December 2029 | End of product enhancements, regulatory updates, service packs and technical support. Final year-end update. | The date that actually matters. Regulatory updates include the Canadian Payroll tax tables. After this, GP cannot be kept CRA-current. |
| 30 April 2031 | End of security updates and subscription billing | Official end of life. An unsupported system holding your general ledger. |
Most GP sites focus on 2031 and relax. If you run Canadian Payroll in GP, your real deadline is 31 December 2029, and you want to be off well before the final year-end update rather than immediately after it.
Why Now
Why Canadian GP sites are moving, and not waiting for 2031
Canadian Payroll stops being compliant first
GP Canadian Payroll depends on Microsoft shipping an annual tax update with the CRA tables, T4 handling and year-end changes. Those are regulatory updates, and they end on 31 December 2029. Payroll is the module that fails first, and it fails on a date, not gradually.
The upgrade path is a re-implementation
Business Central is not an upgrade from GP in any meaningful sense. New data model, new extensibility model, new licensing, and your Dexterity customisations and ISV modules do not carry across. The quote reflects all of that, and for a lot of Canadian mid-market GP sites it is out of proportion to the business it supports.
The skills are leaving
GP consulting has been shrinking for years and end of sales accelerated it. Partners are moving their practices to Business Central. Finding someone who can safely touch a GP install, its Dexterity customisations and its SQL layer costs more every year.
Scope, Stated Plainly
What moves, and what does not
GP keeps a lot of its meaning outside the general ledger. This is where a careless migration loses things.
What moves
- Chart of accounts, including the segmented account framework
- Customers, vendors and items across the RM, PM, SOP and POP series
- Full transactional history from both open and history tables
- Open AR and AP with aging intact
- Inventory items and valuation, tied to your closing stock position
- Multicurrency balances with realised and unrealised positions
- Analytical Accounting dimensional data, mapped to destination structures
- GST, HST, PST and QST codes with filing history and input tax credit detail
- Basic payroll records, carried at summary level
What does not, and why
- Dexterity customisations and Modifier or VBA changes, which are GP-native code
- Report Writer report definitions, rebuilt rather than converted
- Management Reporter row, column and tree definitions
- SmartList and SmartList Builder definitions, rebuilt in the destination
- Integration Manager and eConnect integrations, which are re-selected
- Third-party ISV modules and the data held in their own tables
- Security roles and task-level permissions, rebuilt to your approval matrix
Everything here is inventoried in discovery with an explicit decision: replace, rebuild, or retire. The ISV tables are the one people forget, because the data does not live in the GP company database they expect.
Risk Register
What discovery looks for in a GP environment
Eight checks, every project, before a price is quoted.
The account framework
GP accounts are segmented, and those segments usually carry division, department, location or product meaning that predates anyone currently in the finance team. Flattening the segments into a single account string destroys the reporting. Each segment is mapped to a destination structure, or explicitly retired, before extraction.
Open years versus history tables
GP moves closed years into separate history tables. A migration that reads only the open tables silently loses every closed year. History is extracted from both, and the year-end close boundaries are reconciled so comparatives still work.
Analytical Accounting
Where Analytical Accounting is in use, the dimensional codes live in their own tables alongside the GL rather than inside it. AA data has to be extracted and joined deliberately. It is the single most commonly dropped dataset in a GP migration, and its absence is only noticed at the first management pack.
Canadian Payroll history
GP Canadian Payroll holds its own history, year-end wage files and T4 data. Basic payroll migrates at summary level so the general ledger stays correct. The detailed records stay with the archived GP company, which is what CRA retention expects anyway.
Multicurrency and revaluation
Multicurrency Management carries exchange tables, revaluation history and realised and unrealised gain and loss positions. These are reconciled on both sides at cutover rather than reconstructed afterwards from a spreadsheet.
SmartList and Management Reporter dependencies
SmartLists feed exports, and Management Reporter row, column and tree definitions feed the statements your board sees. Both are rebuilt rather than converted, so the full inventory including anything scheduled or emailed is taken during analysis.
Third-party ISV data
Payment automation, document management, tax engines and shipping modules store data in their own tables inside the GP databases. Each one is inventoried and given a decision, because a migration scoped only against native GP tables will miss all of it.
Multiple company databases
GP holds one database per company. Which companies migrate, which consolidate, and how intercompany balances resolve is settled before extraction. Changing it afterwards means reposting history.
Method
How a Dynamics GP migration runs
Listen
Companies, GP version, account framework, module list, Analytical Accounting, ISVs, customisations and your year end, mapped in one session.
Analyze
Extraction straight from the GP SQL databases, a data audit, and a fixed-scope quote. Cost and go-live date agreed before you commit.
Accelerate
Migration runs alongside live GP. Your team keeps posting and keeps closing. Nothing pauses.
Review
Penny-level reconciliation, comparatives checked across closed years, controller sign-off, then cutover at a period close.
Built for Canadian Books
The part a US migration plan does not account for
Canadian Payroll and the 2029 deadline
GP Canadian Payroll is a distinct module with its own Microsoft-published year-end and tax updates carrying the CRA tables. Those are regulatory updates, and they stop on 31 December 2029.
Basic payroll migration is included and carried at summary level so the general ledger stays correct. Detailed payroll history remains in the archived GP company, which is what Canadian year-end and audit processes expect.
Four sales tax regimes, sometimes at once
Ontario, Nova Scotia, New Brunswick, Prince Edward Island and Newfoundland and Labrador use HST, administered federally. British Columbia, Saskatchewan and Manitoba charge GST plus a separately administered PST with its own registration. Quebec charges GST plus QST. Alberta and the territories are GST only.
A multi-company GP install spanning provinces carries several registrations at once. Each tax code is mapped to the correct regime and registration, because a code in the wrong bucket is a filing problem, not a display problem.
Input tax credit history has to survive
Your ITC position is built from transaction-level detail, not a summary balance. Rebuilding tax codes from scratch and loading history without them removes the trail behind your filed returns, and it is only missed when a prior period is reviewed.
Tax codes, filing history and the underlying detail move together so previously filed returns still reconcile.
Six years of records, and the CRA expects them in Canada
The CRA requires books and records to be kept six years from the end of the last tax year they relate to, and expects them kept at your Canadian place of business unless you have permission to keep them elsewhere.
This is why the GP company databases are archived and retained read-only rather than decommissioned at cutover, and why client data is processed in Canada for the duration of the engagement.
Destination
QuickBooks Online Advanced, or QuickBooks Enterprise
Both are real destinations for a GP exit. Which fits is a discovery answer, and it changes the scope and the price.
QuickBooks Online Advanced fits when
- You want the SQL Server and the GP application tier gone entirely
- Your finance team is distributed and cloud access matters
- Company count is modest and consolidation is periodic
- Account framework segments map cleanly onto classes, locations and projects
- Inventory is straightforward, or already lives in a dedicated system
QuickBooks Enterprise fits when
- GP inventory is genuinely complex: assemblies, multiple sites, lots or serials
- Transaction volume is high enough that list and file size limits matter
- You need advanced pricing rules or heavier reporting against large volumes
- Your team is in one place and comfortable with a desktop workflow
If your GP install is genuinely running manufacturing, distribution or field service through ISV modules, the financial move is only part of the project and the operational replacement has to be solved first. We will say so on the call.
Timelines and Investment
What a Dynamics GP exit costs, and how long it takes
Scoped after discovery, quoted as a fixed price, agreed before you commit.
| Engagement | Timeline | Investment |
|---|---|---|
| Standard Dynamics GP to QuickBooks migration | 30 days | Starting at CAD $10k |
| Multi-company or extended history migration | 4 to 8 weeks | CAD $15k to $25k |
| Heavy customisation and ISV rationalisation | 8 to 12 weeks | Scoped to environment |
Figures in Canadian dollars. Final scope and price are confirmed after the data assessment, and the go-live date is agreed at the same time.
The Other Answer
When Business Central is the right call instead
We are not the right answer for every GP site, and saying so costs us nothing.
You genuinely run operations in GP
Where manufacturing, distribution or field service is running through GP and its ISVs, and those modules are actually used, Business Central keeps that shape. QuickBooks does not, and pretending otherwise helps nobody.
Heavy multi-entity with continuous consolidation
Many companies consolidating on a real cycle with intercompany automation is a Business Central or tier-one requirement, not a QuickBooks one.
You have already bought the licences
If Business Central is contracted and the implementation is underway, the useful question is not whether to move but who is doing the data. That is a different conversation and we are happy to have it.
Where the honest answer is that GP was oversized for your business all along, QuickBooks is usually cheaper than the upgrade and faster than the re-implementation. Discovery tells you which situation you are in.
Proof
A national organization, off an on-premise ERP, in four weeks
Dairy Farmers of Canada, the national policy and promotional organization representing Canadian dairy producers, retired an on-premise Sage 300 environment for QuickBooks Online Advanced, with cloud access for a distributed finance team and the server and its licensing overhead gone. On the Dynamics GP side specifically, we have delivered a multi-entity manufacturer off GP to QuickBooks Online on the original date, with entity-level reporting preserved and no disruption to daily operations.
Questions Canadian CFOs ask
Before you book
When exactly does Dynamics GP stop working?
It does not stop working. Microsoft ends product enhancements, regulatory updates and technical support on 31 December 2029, and security updates on 30 April 2031. The software keeps opening. What stops is being able to keep it compliant and patched.
We run GP Canadian Payroll. What is our real deadline?
31 December 2029, not 2031. The CRA tax tables reach you through Microsoft regulatory updates, and those end with the final year-end update. Plan to be off before that year end rather than immediately after it.
Which GP versions can you migrate?
GP 2013 through GP 18.x, and older Great Plains installs case by case once we see the SQL databases. Extraction runs against the databases directly rather than through GP tooling, so the version matters less than the data.
Do we need our GP partner involved?
Not usually. We need a SQL backup or read access to the company databases, plus documentation of customisations and ISV modules if it exists. Where a partner is still engaged we work with them.
What happens to Analytical Accounting data?
It is extracted from its own tables and mapped to destination structures alongside the GL. AA is the single most commonly dropped dataset in a GP migration because it does not live inside the general ledger, so it is scoped explicitly.
Will our closed years come across?
Yes. GP moves closed years into history tables, and a migration reading only the open tables loses all of them. We extract from both and reconcile the year-end boundaries so comparatives still work.
How is Canadian sales tax handled?
GST, HST, PST and QST codes are mapped to the correct regime and registration, with filing history and input tax credit detail, so previously filed returns still reconcile after the move.
Where is our data during the migration?
In Canada. Client data is processed in Canada for the duration of the engagement, and the GP company databases are archived and retained read-only. Nothing on the source side is deleted by us.
What about our Dexterity customisations and ISV modules?
Inventoried in discovery, each with an explicit decision to replicate, replace with destination capability, or retire. The financial impact of each is what migrates. ISV data lives in its own tables and is scoped separately.
How much detailed history can we bring?
Standard scope is full open items plus two to three years of detailed history, with earlier years carried as opening balances by period. Deeper history is possible and is priced in discovery rather than assumed.
Can we shut down the SQL Server afterwards?
Keep an archived backup and a documented restore path for your CRA retention period. Most clients decommission the live GP application tier once the first close in the new system is complete.
Can our accounting firm run this and keep the client?
Yes. Refer, white-label or co-deliver. The terms are written down and the engagement routes back to the firm. We do not take your client.
Accounting firm with a client on this platform?
Refer, white-label, or co-deliver the migration with our team while you keep the client relationship.
Playbooks
Before you decide, read the mechanics
Short, checkable pieces on the contract clauses and system limits that usually decide this. Each one names a document or a report you already own.
The uplift clause costs more than the discount you win
A 6 percent discount erased by a 7 percent annual escalator. All three years priced out, and the four documents to pull before you respond to a renewal.
When a QuickBooks Desktop file gets too big
The published list limits, five signs a file is ageing badly, and what Condense Data actually fixes.
Discovery Call
Book a Dynamics GP discovery call
Ninety minutes on your dimensions, entities and renewal clock. Fixed-scope quote after: or an honest recommendation to stay.
