Migrating off GP payroll before the regulatory updates stop

Why payroll has the sharpest deadline in your GP estate

Most GP modules degrade gracefully after support ends. General ledger math does not change when Microsoft stops shipping updates, and a posted journal entry from 2024 is exactly as correct in 2031 as it was the day you posted it. Payroll is different, because payroll is only correct relative to this year’s rules, and the rules change every year, sometimes more than once.

GP payroll depends on a stream of updates Microsoft ships annually and sometimes mid-year: US federal and state tax tables, FICA wage bases, 401(k) contribution limits, W-2 and 1099 form changes, and for Canadian payroll the CRA tax tables, CPP and EI rates, and T4 formats. Microsoft’s own lifecycle policy states that mainstream support, product enhancements, and tax and regulatory updates for Dynamics GP end on December 31, 20291. That date is not arbitrary. Microsoft had originally targeted an earlier cutoff and pushed it out specifically so GP customers could complete a full year end payroll and tax cycle before losing tax table updates entirely1. Read that as Microsoft telling you, in its own scheduling decision, how seriously to take the payroll piece of this migration.

For context on the wider GP timeline: new perpetual license sales ended April 1, 2025, and new subscription license sales end April 1, 2026, meaning no organization can newly acquire GP in any form after that date2. Security updates and patches continue longer than tax updates do, until April 30, 2031, which is the true hard stop for running GP at all1. Payroll’s clock runs out more than a year before that final security date, which is the point: your ERP replacement project can reasonably run past 2029, but your payroll system cannot.

Here is what the December 2029 date means concretely. The 2029 tax year is the last one GP can run correctly. In January 2030, your federal, state, and provincial withholding tables are frozen at 2029 values. Every rate change and wage base limit change for 2030 goes unapplied, and every paycheck GP calculates is quietly wrong in ways your employees will not notice but the IRS and CRA eventually will. Under withholding, incorrect CPP contributions, and outdated year end forms are not bugs you can live with. They are compliance failures with statutory penalties attached, and “our payroll software was end of life” is not a defense the IRS recognizes.

So the real deadline is not December 2029. It is your last safe go-live before it, and for payroll that means a January 1 cutover, which makes January 1, 2029 the last comfortable one and January 1, 2030 not an option at all. Work backward from that and the planning window is now, not in 2028.

What “regulatory updates” actually covers

It helps to be precise about what stops, because “updates” undersells it. GP’s payroll and HR module stores its setup and history in its own family of tables (the payroll module uses its long standing UPR table prefix across employee master records, pay and deduction and benefit code setup, tax setup, and transaction history), and Microsoft’s regulatory updates rewrite the tax calculation logic and reference data those tables depend on, not just a display or a report.

Concretely, a GP regulatory update in a normal year changes: the federal and state withholding tax tables and formulas; the annual Social Security wage base and Medicare additional tax thresholds; 401(k), HSA, and other pretax deferral limits; FUTA and, where applicable, SUTA rate and wage base changes; W-2, W-3, and 1099-NEC form and e-file layout changes; and, for Canadian payroll, the CRA’s federal and provincial tax tables, the CPP and EI contribution rates and maximums, and the T4 and T4A form specifications. Some years these are minor rate tweaks. Some years, like a change to withholding methodology or a new reporting box, they are structural. Either way, the update is what keeps a GP paycheck matching the law as of the date it was run, and none of it is something a finance team can safely approximate by hand.

This is also why payroll cannot simply “keep working” after 2029 the way a dormant AP module might. AP with no new updates still posts invoices correctly, because invoice posting logic does not change year to year. Payroll’s core calculation logic is a moving target by design, and GP’s target stops moving on December 31, 2029 while the real world’s does not.

The compliance cost of running payroll on unsupported software

It is tempting to treat “run GP payroll one more year past support” as a soft risk, the kind of thing that might be fine if nothing goes wrong. The IRS does not see it that way. Payroll tax deposits are governed by a statutory penalty structure under IRC section 6656, published in IRS Publication 15, the Circular E Employer’s Tax Guide, and it escalates fast3.

Notice what drives this ladder: it is deposit timing, not tax accuracy. A late deposit caused by anything, a system that calculated the wrong withholding amount, a payroll clerk who did not know the wage base had changed, a batch job that ran on outdated tables, gets the same escalating penalty as a deposit that was simply late for administrative reasons. Frozen tax tables after 2029 do not cause a one-time error you catch and fix. They cause a recurring, compounding pattern of miscalculated deposits, and each miscalculation resets the clock on this ladder. A company that discovers in March that its January and February deposits were wrong because of a stale wage base is not looking at one penalty. It is looking at one penalty per affected deposit, per taxing jurisdiction, potentially across federal, state, and in some cases local withholding, plus the equivalent CRA penalty structure on the Canadian side for CPP, EI, and income tax remittances.

This is the argument for treating payroll as a compliance system with a hard deadline, not an ERP module with a soft one. The $450,000 median ERP implementation and its 15.5 month timeline (see our cost and timeline guides) are business decisions you can phase and negotiate. A frozen federal tax table is not a business decision. It is a fact you will be operating against, starting the first pay period of 2030, whether or not your ERP replacement is ready.

Where GP payroll can go

You have three destination patterns, and the right one depends more on your headcount and complexity than on your ERP choice.

Payroll inside the new ERP. If your new system has a real payroll module for your countries, this keeps payroll, GL posting, and HR data in one place, the way GP did. The caution: payroll is the weakest module in many ERPs, and Canadian payroll support in particular is thin outside a few platforms. Verify the module actually handles your real situation, multi-state or multi-province operations, union rules, certified payroll on government contracts, before assuming a generic ERP payroll module covers it.

A dedicated payroll service. ADP, Paychex, Ceridian Dayforce, and similar providers do nothing but payroll. They carry the compliance burden of tax table changes and filings themselves, and they integrate with essentially any ERP through a GL journal import or API. Rather than replicating full payroll transaction detail inside the new ERP, the standard pattern is to have the provider export one summarized journal entry per pay run, gross wages by department or cost center, total employer tax expense, net pay clearing, and deductions payable, and post that single journal into the ERP’s general ledger. The detailed payroll register, the system of record for who was paid what and why, stays in the provider’s system, where it is their job to keep it compliant. For most SMB and mid-market GP shops this is the lowest-risk destination, and it decouples the payroll deadline from the larger ERP timeline entirely: you can move payroll out of GP first and migrate the rest of the system on its own schedule.

An outsourced bureau. You send hours and changes; the bureau runs everything, including filings and year end forms. This suits smaller headcounts or lean finance teams that want payroll to stop being their problem at all. You trade some control and cost for the disappearance of an entire risk category.

Whichever you choose, decide early. Payroll providers have implementation queues, and every other GP shop is working against the same deadline you are. The closer to 2029 you start, the worse the queue and the pricing get.

The migration plan, step by step

1. Confirm what GP payroll actually does for you. Before anything else, inventory it: pay codes, deduction and benefit codes, tax setups per state or province, direct deposit, garnishments, accruals for vacation and sick time, GL posting setup, and any Integration Manager jobs or timeclock feeds that load hours into payroll. Include how HR data flows, since GP’s HR module and payroll share underlying tables. Most companies discover payroll does more than anyone currently on staff remembers, especially around garnishments and multi-jurisdiction tax setups nobody has touched in years.

2. Choose the destination and buy it. Evaluate against your real inventory from step 1, not a generic feature checklist. Get the implementation timeline in writing and book the slot. If the broader ERP migration timeline is still uncertain, choose a destination that works standalone, so payroll is not hostage to a larger project’s delays.

3. Map earning and deduction codes and the year to date model. Every GP pay code, deduction, and benefit maps to a code in the new system, and building that mapping needs finance and payroll staff in the room together, because these codes encode policy: taxability, W-2 or T4 box assignment, GL account, and whether an item is pretax or post tax. This is also where you retire dead codes; twenty years of GP accumulates pay codes nobody has used since a policy that changed a decade ago.

4. Migrate employee and year to date data. Employee master data, tax elections (federal, state, provincial, and local, including exemption certificates), direct deposit details, garnishment orders with their governing case numbers, accrual balances, and, if you cut over mid-year, year to date earnings, taxes, and deductions per employee per code. Year to date accuracy is what makes W-2s and T4s come out right at year end, so it gets penny-level validation against GP’s payroll history, employee by employee, not validated in aggregate totals.

5. Run parallel for at least one full cycle. Run the same pay period in both GP and the new system and compare every employee’s gross pay, each individual tax, each deduction, and net pay, line by line. One cycle is the minimum; two or three is better, and make sure the parallel window includes your complicated cases: a bonus run, an active garnishment, a multi-state or multi-province employee, and someone hitting a wage base limit like the Social Security wage cap or an EI maximum. Parallel runs are tedious, and they are also the only thing standing between you and hundreds of wrong paychecks landing in real bank accounts.

6. Reconcile the parallels and resolve every variance. Every difference between GP and the new system gets explained: a mapping error, a rounding convention difference, or a GP misconfiguration you are choosing to fix rather than replicate. No unexplained variance survives to cutover, however small, because a two cent tax rounding difference is sometimes the visible symptom of a wrong wage base sitting underneath it.

7. Cut over at a clean boundary. January 1 is the gold standard: no year to date migration at all, the old year’s W-2s and T4s come entirely from GP, and the new year lives entirely in the new system from its first pay period. A quarter boundary, aligned to your 941 or T4 remittance periods, is the acceptable fallback if January 1 is not reachable. Decide explicitly who files the final year end forms out of GP, and keep GP’s payroll history in your archive plan, since payroll records carry some of the longest retention requirements of anything in your GP estate.

The cost of leaving it late

Payroll migrations compress badly. Every step above has a season: code mapping needs your payroll team’s attention outside of quarter end close, parallel runs need real pay cycles you cannot simulate or compress, and January 1 cutovers only come once a year. A team that starts in early 2027 gets a calm project with a January 2028 or 2029 go-live and slack for surprises. A team that starts in mid-2029 gets a payroll provider’s implementation queue, a mid-year cutover forcing a full year to date migration, one rushed parallel run instead of three, and its first unsupported tax year looming directly behind any slip in the schedule.

There is also a quiet organizational risk: the person who has run GP payroll for fifteen years may retire before 2029 does. Their knowledge of why each pay code exists, which garnishment orders are still active, and which “temporary” tax setup from 2017 is actually load-bearing, is a migration asset with its own deadline, separate from Microsoft’s.

The encouraging part: payroll is the most decouplable piece of a GP exit. You can move it to a dedicated provider years before the rest of GP goes anywhere, take the December 2029 compliance deadline off the table entirely, and let the broader ERP decision proceed at a sane pace on its own merits. If you are early in your GP planning and wondering what to tackle first, this is a strong candidate for the answer.