How long must employers keep payroll records after migrating off Dynamics GP?

The IRS requires employment tax records be retained for at least 4 years after the tax due date or payment date. The FLSA requires 3 years for payroll records. ERISA requires 6 years for retirement plan records. States like New York require 6 years, and Tennessee requires 7 years. Multi-state employers must apply the longest applicable window.

What GP SQL tables contain payroll history data?

The key tables are UPR30100 (Payroll Check History — every check ever issued), UPR30300 (Payroll Transaction History — line-item detail for each check), UPR30301 (YTD summaries per employee), UPR30200 (Tax Liability History), and UPR30400/30401 (Distribution History). Master data lives in UPR00100, UPR00300, UPR00400, UPR00500, UPR00600, UPR00700, and UPR00800.

What happens to payroll data if I switch payroll providers mid-year during a GP migration?

Mid-year transitions require exact YTD wage and tax data to transfer to the new system. Without it, you risk duplicate Social Security and unemployment tax withholding, incorrect quarterly 941 filings, and W-2 errors. Best practice is to align the cutover with January 1 or the start of a calendar quarter — never mid-quarter.

Can I migrate GP payroll history directly into Paylocity or ADP?

Most standalone HRIS platforms only accept active employees and current-year YTD balances. ADP's midyear conversion guide asks for current-year 941s and YTD summaries, not multi-year check history. Historical paycheck data must be extracted from GP and stored in a separate, queryable compliance archive.

Dynamics GP Payroll Data Migration: The Complete Technical Guide

Payroll is the module most likely to be forgotten in a Dynamics GP migration — and the one most likely to cause a compliance crisis when it is. Microsoft's Cloud Migration Tool, the standard path from GP to Business Central, does not migrate payroll data. Your GL, AP, AR, and inventory move through the pipeline. Your payroll history stays behind in SQL. (learn.microsoft.com)

This creates a problem that most implementation partners surface too late: the data with the strictest federal and state retention requirements is the data with no supported migration path. If you are a CFO or IT director midway through a GP-to-BC project and just realized your payroll data is not moving, this guide covers exactly why, what is at risk, and how to extract it safely.

For broader context on handling historical financial data alongside payroll, see Dynamics GP to Business Central: Migrating 20 Years of History.

The GP Payroll Trap: Why Standard Migration Tools Leave Your Data Behind

Three structural facts create this problem:

1. Microsoft discontinued GP's Extended HR and Payroll modules in March 2022. The Extended Human Resources and Payroll suite — Payroll Extensions, Advanced Payroll, Advanced HR, and PTO Manager — was removed from the GP price list and transferred to Integrity Data, the ISV that originally developed them. Core Payroll (included in the GP Starter Pack) still receives tax updates through the GP lifecycle, but the extended modules are now a third-party product. Many GP customers are already running a hybrid payroll setup before they even start their migration. (integrity-data.com)

2. Business Central does not include a native US payroll module. BC handles financials, supply chain, and project accounting. Payroll is explicitly delegated to third-party ISVs — Integrity Data's Payroll NOW, Greenshades, or standalone platforms like ADP, Paylocity, and Ceridian/Dayforce. Your ERP migration target and your payroll migration target are almost certainly two different systems.

3. Microsoft's Cloud Migration Tool explicitly excludes payroll. The tool handles chart of accounts, customers, vendors, items, open AP/AR, GL history, and vendor 1099 data. It does not touch the UPR (United Payroll) table family. Microsoft's own documentation lists supported historical snapshots for GL, receivables, payables, sales order processing, purchase receipts, and inventory — but not payroll. (learn.microsoft.com)

Warning

This is not a gap — it is a design decision. Because BC has no payroll engine, there is no target schema for payroll data inside BC. The migration tool has nowhere to put it. Do not confuse vendor 1099 migration (which is supported from payables) with payroll history — W-2 paycheck history, quarter-to-date wage detail, garnishment records, benefit deductions, and accrual balances are entirely separate work.

Business Central's own payroll documentation describes importing transactions created by a payroll provider into the general journal — mapping external accounts to G/L accounts and posting them. The base payroll XMLPort accepts tab-delimited PostingDate, Account, Amount, and Description. That is a financial posting format, not a landing zone for employee-level GP paycheck history. (learn.microsoft.com)

This leaves organizations with a fragmented data problem. Financial data moves to Business Central. Payroll data must be routed to a completely different schema in a third-party application — and historical payroll data may have no destination in either system.

IRS, FLSA, and State Compliance: The Risks of Stranded GP Payroll History

Payroll record retention is governed by overlapping federal and state mandates. When you decommission your GP SQL Server, every record in those databases must remain accessible for the duration of the longest applicable retention window — or you are exposed. (irs.gov)

Authority	Record Type	Minimum Retention
IRS	Employment tax records (W-2s, 941s, tax deposits)	4 years after tax due date or payment, whichever is later
FLSA (DOL)	Payroll records (wages, hours, deductions)	3 years
FLSA (DOL)	Wage computation records (timecards, schedules)	2 years
EEOC / ADEA	Personnel and payroll records	3 years
ERISA	Retirement plan records (401k contributions, matches)	6 years

Those are the floors. States regularly exceed them. New York requires 6 years for wage-and-hour records. Tennessee requires 7 years for tax-related payroll documentation. Multi-state employers must apply the longest window across all jurisdictions where they have employees. (ny.gov)

The practical implication: if you are decommissioning GP in 2026, you need payroll records accessible through at least 2030 (IRS) and potentially 2032–2033 (New York, ERISA). Shutting down the SQL Server before extracting and archiving this data is a compliance violation waiting to happen.

Danger

Garnishment and benefit deduction history carries its own risk. Court-ordered garnishments, child support withholdings, and benefit deduction records must be preserved beyond the standard windows if litigation or claims are pending. Losing these records can expose employers to contempt-of-court risk.

If you rely on your implementation partner's standard data extraction, you will likely get active employee master files and top-level year-to-date balances. The detailed check history, garnishment records, benefit deduction history, and quarterly tax filings will remain locked in the deprecated GP environment.

For guidance on handling the PII and security aspects of payroll extraction, see How to Safely Migrate Sensitive Employee & Payroll Data.

Understanding GP's UPR Tables: Where Your Payroll Data Actually Lives

Dynamics GP stores payroll data in a structured SQL table family prefixed with UPR (United Payroll). To safely extract this data, you must bypass the application layer. GP's SmartLists are notorious for timing out on large datasets, hitting row limits, and flattening relational data — which strips out critical employer-side tax liabilities and benefit matches. Direct SQL extraction is the only reliable method.

Master data tables

Table	Name	What It Holds
UPR00100	Employee Master	Employee ID, name, SSN, address, status, hire/term dates
UPR00102	Address Master	Employee address records
UPR00300	Tax Information Master	Federal, state, and local tax filing status, withholding allowances
UPR00400	Pay Code Master	Pay type definitions (hourly, salary, overtime, commission)
UPR00500	Deduction Master	Employee deduction configurations (401k, insurance, garnishments)
UPR00600	Benefit Master	Employer benefit configurations
UPR00700	State Tax Master	State-level tax withholding setup
UPR00800	Local Tax Master	Local jurisdiction tax setup

History tables (the compliance-critical data)

Table	Name	What It Holds
UPR30100	Payroll Check History	Every check ever issued — gross, net, check number, date, void status
UPR30200	Tax Liability History	Detailed breakdown of taxes withheld and employer matching liability
UPR30300	Payroll Transaction History	Line-item detail for every paycheck — each pay code, deduction, tax line
UPR30301	Transaction History Header	Summarized YTD data per employee per year
UPR30400/30401	Distribution History	GL distribution detail for payroll postings
UPR00900	Employee Summary	Aggregated employee totals — reconciles against UPR30100 and UPR30300

(dyndeveloper.com)

The relationship that matters

UPR30100 (Check History) and UPR30300 (Transaction History) are the two tables that reconstruct a complete paycheck. UPR30100 gives you the check-level record. UPR30300 gives you every line item on that check — federal withholding, state tax, Social Security, Medicare, each deduction code, each benefit.

If your migration script only pulls from UPR30100, you will have net pay amounts but no itemized deductions — rendering the data useless for an IRS audit.

-- Illustrative GP payroll extract: check headers + line detail
SELECT
    h.EMPLOYID,
    h.CHEKNMBR,
    h.PYADNMBR,
    h.CHEKDATE,
    h.GRWGPRN   AS gross_wages,
    t.PAYROLCD  AS payroll_code,
    CASE t.PYRLRTYP
        WHEN 1 THEN 'Pay'
        WHEN 2 THEN 'Deduction'
        WHEN 3 THEN 'Benefit'
        WHEN 4 THEN 'Tax'
        WHEN 5 THEN 'LocalTax'
        ELSE 'Other'
    END         AS component_type,
    t.UPRTRXAM  AS component_amount
FROM UPR30100 h
JOIN UPR30300 t
  ON t.EMPLOYID = h.EMPLOYID
 AND t.CHEKNMBR = h.CHEKNMBR
 AND t.PYADNMBR = h.PYADNMBR
WHERE h.CHEKDATE >= '2024-01-01'
ORDER BY h.CHEKDATE, h.EMPLOYID, h.CHEKNMBR, t.PAYROLCD;

Use that as a pattern, not copy-paste truth. GP versions, void/reissue behavior, Integrity Data extensions, and custom payroll modifications change what you must join and how you classify lines. If you use Integrity Data modules or custom tables, remember: Microsoft's migration FAQ states that custom tables do not move unless someone defines the mappings. (learn.microsoft.com)

For the broader story of why ERP data layers break during migration, see Why ERP Migrations Fail at the Data Layer: 9 Core Patterns.

Target System Dilemma: Business Central ISVs vs. Standalone HRIS

Once you have extracted GP payroll data, where does it go? The answer depends on your target payroll platform — and each path has different data intake requirements.

Path 1: Embedded BC payroll ISV (Integrity Data Payroll NOW, Greenshades)

These products run inside Business Central and post payroll journal entries directly to the BC general ledger. Integrity Data is the natural successor for GP payroll customers, given they now own the Extended HR and Payroll modules. (appsource.microsoft.com)

What they typically want for onboarding:

Active employee master records with current tax setups
Current-year YTD balances (wages, taxes, deductions)
Active deduction and benefit configurations
Accrual balances (PTO, sick time)

What they typically do not ingest:

Multi-year check history
Historical transaction detail from prior years
Terminated employee records older than current year

The gap is significant. The ISV gets what it needs to process the next payroll run. Your compliance team loses access to everything that came before.

Path 2: Standalone payroll/HRIS (ADP, Paylocity, Ceridian/Dayforce)

These platforms integrate with Business Central via API or file-based sync for GL postings. They handle payroll processing, tax filing, and employee self-service independently.

What they typically want for onboarding:

Employee demographics and active tax elections
YTD wage and tax totals (current year only)
Current benefit elections and deduction schedules
Direct deposit banking details
Copies of current-year Form 941s and garnishment orders

What they typically do not ingest:

Historical paycheck detail prior to the migration year
Legacy pay code mappings
Multi-year tax filing history

ADP's midyear conversion guide asks for current-year Form 941s, year-to-date payroll summaries by employee and quarter, deduction lists, direct deposit data, and copies of garnishment orders. Paylocity recommends quarter-end or year-end as the easiest switch point and calls for historical payroll records, tax returns, pay stubs, and W-2s. (adp.com)

Dayforce's YTD load tools require exact employee matching and careful configuration. Its historical pay-run import path has constraints — some recalculation workflows require database access, must be completed before go-live, and can double amounts if the wrong tax lines are flagged for recalculation. (help.dayforce.com)

Both paths converge on the same problem: your new payroll system only wants current-year operational data. Years of legally required historical data has no destination in either system. That history must be extracted, transformed, and archived independently.

Mid-Year Migrations: YTD Balances, Accruals, and Tax Filings

Mid-year payroll transitions are the highest-risk scenario in any GP migration. If you cut over to a new payroll provider mid-year, the new system must have perfect YTD data for every employee — or your quarterly 941 filings, annual W-2s, and wage-base calculations will be wrong.

Here is what breaks:

Social Security wage base limits. Social Security taxes stop at an annual wage base limit. If YTD wages are not migrated accurately, the new system cannot determine when to stop withholding the 6.2% employee share. Employees who have already hit the cap get double-taxed. Employers overpay their match — and cannot recover it easily.
FUTA and SUTA wage bases. State unemployment tax wage bases vary by state and reset annually. Without YTD wage data, the new system treats every employee as if they have not earned anything yet — triggering duplicate employer-side unemployment tax.
401(k) and HSA contribution limits. Annual limits apply across all employers and systems. Without YTD contribution data, employees risk exceeding IRS limits, creating excess contribution penalties.
Quarterly 941 reconciliation. When two systems file for portions of the same quarter, the combined 941s must reconcile to the penny. Misaligned filings trigger IRS notices, penalties, and manual corrections that can drag on for months.
W-2 responsibility. If you migrate mid-year, you need to determine in advance which system issues the annual W-2. If it is the new system, it needs the full-year picture from both providers.
Multi-state reciprocity. GP handles multi-state taxation based on physical work locations and resident states. Mapping these complex reciprocity agreements into a new system often fails if the underlying location codes from UPR00700 and UPR00800 are not perfectly translated. If you have employees in 15 states, that is 15 different tax jurisdiction configurations — and standard ISV import templates often reject records with unrecognized state codes or local tax IDs.
Accrual balances. PTO and sick leave accruals must be extracted precisely at the cutover date. If an employee takes PTO during the blackout period between systems, the balance must be manually reconciled.

Tip

Best practice: migrate payroll at the start of a quarter — ideally January 1. If a mid-year transition is unavoidable, align it with a quarter boundary (April 1, July 1, or October 1). Never cut over mid-quarter. The reconciliation complexity doubles. (adp.com)

How to Extract and Archive GP Payroll Data Safely

The extraction breaks into two workstreams: operational data for the new payroll system and historical data for the compliance archive.

Workstream 1: Operational data for the new payroll system

This is the data your new provider needs to process the first payroll run. Extract it from GP as close to the cutover date as possible:

-- Active employee master records
SELECT * FROM UPR00100 
WHERE INACTIVE = 0 AND EMPLOYID NOT IN (
  SELECT EMPLOYID FROM UPR00100 WHERE TERMINATED = 1
)
 
-- Current-year YTD wage and tax totals
SELECT * FROM UPR30301 
WHERE YEAR1 = '2026'
 
-- Active deduction and benefit assignments
SELECT * FROM UPR00500 WHERE INACTIVE = 0
SELECT * FROM UPR00600 WHERE INACTIVE = 0
 
-- Current tax setup
SELECT * FROM UPR00300
SELECT * FROM UPR00700  -- State tax
SELECT * FROM UPR00800  -- Local tax

This data must be transformed to match the target system's import template. Every payroll ISV has its own field naming, code structure, and validation rules. GP's pay type codes (Hour = 1, Salary = 2, Overtime = 6) do not map 1:1 to any external system. Build a code crosswalk that maps every legacy pay, deduction, benefit, and tax code to the target system's structures — and explicitly mark each code as active, merged, retired, or archive-only.

Workstream 2: Historical archive for compliance

This is everything you need to satisfy IRS, FLSA, EEOC, ERISA, and state auditors after GP is decommissioned:

-- Full check history with line-item detail (all years)
SELECT c.*, t.* 
FROM UPR30100 c
JOIN UPR30300 t ON c.EMPLOYID = t.EMPLOYID 
  AND c.YEAR1 = t.YEAR1 
  AND c.PAYRCORD = t.PAYRCORD
ORDER BY c.EMPLOYID, c.YEAR1, c.CHEKDATE
 
-- Distribution history for GL reconciliation
SELECT * FROM UPR30400
SELECT * FROM UPR30401
 
-- Employee summary for cross-reference
SELECT * FROM UPR00900

The archive must be:

Queryable. A pile of CSVs in a SharePoint folder is not an archive. Auditors need to look up a specific employee's check history for a specific quarter. Use a relational database, a structured data warehouse, or a purpose-built compliance archive. IRS guidance allows electronic recordkeeping, but the records must preserve enough transaction-level detail to identify underlying transactions and source documents. (irs.gov)
Secured. Payroll data contains SSNs, banking details, and compensation data. Encryption at rest and role-based access are non-negotiable.
Documented. Include a data dictionary mapping every field, every code, and every table relationship. Three years from now, when someone needs to pull a garnishment record, they should not need a GP expert to interpret the schema.
Retention-aware. Tag each record with the applicable retention window. Build automated alerts for when records become eligible for destruction.

Validation before cutover

Data extraction is meaningless without validation. Run the GP Payroll Summary Report and the 941 Preparation Report for the current quarter. Compare the totals on these reports against the YTD dataset you extracted via SQL. They must match to the penny. If they do not, you have a missing deduction code, an unposted manual check, or a void that was not properly accounted for.

Before first live payroll in the new system, run a parallel validation set that proves: employee YTD gross by quarter, employee tax YTD by authority, deduction and benefit YTD by code, employer match totals, direct deposit totals, garnishment carry-forward, and accrual opening balances. If any of these are off, stop. Payroll errors compound faster than almost any other ERP data error.

Microsoft also documents an optional pattern of copying the GP database to Azure Data Lake for future reference during a Business Central migration. That is useful as a raw backup, but it does not replace a purpose-built payroll archive with clean indexes, security controls, and business-friendly exports. (learn.microsoft.com)

Common Failure Modes in GP Payroll Migrations

Across hundreds of ERP migration engagements, certain payroll-specific failures recur:

1. "We'll handle payroll later." Implementation partners focus on GL, AP, AR, and inventory. Payroll gets pushed to the last sprint. By then, the cutover date is locked and there is no time for proper extraction and validation.

2. SmartList exports treated as complete. SmartList can pull surface-level payroll data but cannot join UPR30100 and UPR30300 with the relational fidelity needed for compliance. You get check-level totals without line-item detail.

3. Historical data left on the GP SQL Server. The plan is to "keep GP running for lookups." But GP requires a Windows Server, SQL Server, and Dexterity runtime — all with their own support lifecycles. Within 2–3 years, the infrastructure decays, SQL Server goes out of support, and accessing the data requires maintaining an increasingly fragile legacy stack. That is not a data strategy. It is a plan to keep a legacy environment alive because nobody built a real archive.

4. YTD data imported without validation. The new payroll provider loads YTD balances from a spreadsheet. Nobody reconciles the imported totals against GP's UPR30301. The first quarterly 941 filing has a five-figure discrepancy. The IRS sends a notice.

5. Multi-state tax history not mapped. GP stores state and local tax history across UPR00700, UPR00800, and UPR30300. Standard ISV import templates often reject records with unrecognized state codes or local tax IDs, and mapping 15+ state jurisdictions requires careful, manual crosswalk work.

6. Custom tables and extensions ignored. If your payroll depends on Integrity Data add-ons, custom payroll reporting tables, or modified GP tables, discovery must happen during extraction — not as a surprise during UAT. Microsoft's migration FAQ confirms custom tables do not move automatically. (learn.microsoft.com)

Make Payroll the First Conversation, Not the Last

The pattern we see over and over: payroll is the hardest part of every GP project, and it is the part that gets planned last. By the time someone realizes the Cloud Migration Tool does not touch UPR tables, the go-live date is 30 days out and the implementation partner is already overextended.

Flip the sequence. Start your GP migration planning with payroll — identify your target system, map the UPR tables, build the extraction scripts, validate the archive format, and reconcile YTD data before you configure your first BC dimension. Everything else in the migration has a supported tool and a documented path. Payroll does not. It needs the most lead time, not the least.

The GP sunset is approaching — support ends December 31, 2029, and security patches stop April 30, 2031. The window to extract payroll data while your GP environment is still healthy and your SQL Server is still patched is closing. For a full planning timeline, see Dynamics GP End of Life: 2025–2031 Timeline & Migration Plan.

ClonePartner extracts directly from GP's SQL UPR tables, bypassing the limitations of SmartList and report-based exports. We separate the two workstreams — operational data for your new payroll ISV and historical data for your compliance archive — and deliver both with a verifiable audit trail. Multi-state tax mappings, custom deduction code transformations, and mid-year YTD reconciliation are part of the standard engagement, not a surprise scope change.