← All posts

How to Migrate Payroll and AP/AR History to a New Platform

August 20, 2026 · LedgerSwitch Team

When your firm decides to change accounting platforms, the general ledger is only the beginning. If you run payroll in-house, track customer invoices, or manage vendor bills, you need to migrate payroll and AP/AR history along with your core financials—or risk losing years of operational context the moment you flip the switch.

Migrating payroll, accounts payable, and accounts receivable history means moving transaction-level detail with field-level fidelity: every invoice line item, every paycheck stub, every payment application, and every aging bucket. Unlike GL-only migrations that summarize balances into opening journal entries, AP/AR and payroll migrations preserve the transactional substrate your team uses to answer customer inquiries, reconcile vendor statements, generate 1099s, and reconstruct wage histories. The core challenge is mapping hundreds of subsidiary-ledger fields across platforms with different data models while maintaining referential integrity and ensuring your cutover date aligns with payroll cycles, billing periods, and month-end close.

Key Takeaways

Why Subsidiary Ledgers Matter Beyond the General Ledger

The general ledger records what happened; subsidiary ledgers record how and with whom. Your AP sub-ledger links every check and ACH to the vendor invoice it paid, preserving the audit trail required to respond to vendor inquiries, generate accurate 1099-NEC and 1099-MISC forms, and reconstruct spending by category or project. Your AR sub-ledger connects every customer payment to the invoices it satisfied, enabling you to re-send statements, calculate days sales outstanding by customer segment, and defend revenue recognition positions during audits.

Payroll history is even more sensitive. Each payroll run contains employee-level wage detail, tax withholdings, benefit deductions, employer contributions, and garnishments. You need this data intact to issue corrected W-2s, respond to unemployment claims, defend wage-and-hour disputes, and calculate vesting schedules for retirement plans. A summary journal entry crediting cash and debiting payroll expense might balance your books, but it will not let you answer the question "how much did we withhold for this employee's 401(k) in Q2 2025?"

When firms migrate only the GL, they typically export a CSV of account balances as of the cutover date and post a single opening balance journal entry in the new system. This approach works for accounts that represent aggregated value—fixed assets, accumulated depreciation, retained earnings—but breaks down for transactional accounts where the balance is the sum of hundreds or thousands of open line items. If your AR balance is 487,000 dollars, you need to know which customers owe which invoices, when those invoices are due, and which areundefineddays past due versus current. A single 487,000 dollar debit to AR in your new system tells you none of that.

What Data Do You Actually Need to Migrate?

The minimum viable dataset for AP/AR and payroll migration depends on how far back your team needs to drill and what statutory retention periods apply.

For accounts payable, the core data set includes:

For accounts receivable, plan to move:

For payroll, the required scope typically includes:

Deciding how many years of closed history to migrate is a trade-off between completeness and complexity. Regulatory retention periods for payroll records typically run three to seven years depending on jurisdiction and record type, but migrating a full seven years of payroll runs can triple your data volume and field-mapping workload. Many firms compromise by migrating the current calendar year plus one prior year in full transactional detail, then summarizing older years as annual or quarterly roll-ups. This approach preserves the detail you need for W-2 corrections and audits while keeping the migration tractable. For AP and AR, two to three years of transaction history usually suffices unless you operate in an industry with unusually long payment cycles or contract lookback provisions.

Mapping Fields Across Different Data Models

Every accounting platform organizes subsidiary ledger data differently. What QuickBooks Desktop calls a "bill" might map to a "vendor invoice" in NetSuite, a "payable" in Sage Intacct, or an "expense report" in Xero depending on workflow. What one system stores as a single multi-line invoice, another might split across a header table, a line-item table, and a separate payment-application table with foreign-key relationships.

When you migrate payroll and AP/AR history, expect to mapundefinedtoundefinedfields per transaction type. For an AP invoice, that includes:

AR invoices carry similar complexity, plus item or service codes, quantity and unit price, shipping terms, and sales tax jurisdiction. Payroll records add earnings codes, benefit codes, withholding categories, and employer-contribution accounts—all of which must map precisely to the codes defined in your new payroll module or the totals will not reconcile.

The mapping process is both mechanical and interpretive. You can script a transformation that replaces old vendor IDs with new ones and old account numbers with their new-system equivalents, but you cannot automate the judgment call about whether "Office Supplies" in the old system should map to accountundefinedorundefinedin the new one, or whether a custom "Project Manager" class should become a department, a location, or a user-defined field. These decisions require someone who understands your chart of accounts, your reporting structure, and the nuances of how your team actually uses the data.

Common mapping pitfalls include:

Building and testing the field map is the longest phase of any subsidiary-ledger migration. Budget one to two weeks for an experienced data analyst to draft the initial mapping spec, then another one to two weeks for iterative testing and refinement. If you are using LedgerSwitch or similar migration software, much of the mechanical transformation happens automatically once you define the mapping rules, but the upfront design work remains essential.

Timing Your Cutover Around Payroll and Billing Cycles

Your cutover date is the line in the sand: transactions before this date live in the old system, transactions on or after it live in the new. For GL-only migrations, the cutover typically happens at month-end or quarter-end to align with your close calendar. For payroll and AP/AR migrations, you face additional constraints.

Payroll runs on a fixed cycle—weekly, biweekly, semimonthly, or monthly—and each run calculates quarter-to-date and year-to-date totals that must remain unbroken. The cleanest cutover is immediately after you finalize a payroll run and before you start the next. This avoids split-period payrolls where some employees appear in the old system and others in the new, and ensures your QTD and YTD accumulators migrate intact. For calendar-year filers, Januaryundefinedis ideal because it resets YTD counters and aligns with W-2 reporting. The next-best option is the first day of a new quarter, which at least resets QTD figures and simplifiesundefinedreconciliation. Avoid mid-cycle cutovers unless you are prepared to manually split and reconcile a single pay period across two systems.

Accounts payable and receivable do not have hard cycle boundaries, but practical considerations push you toward month-end or quarter-end cutover. If you cut over mid-month, you will need to produce two sets of vendor aging reports for that month—one from the old system covering the first half, one from the new system covering the second half—and manually combine them for management review. Your AP team will need to check both systems when a vendor calls asking about an invoice. Customers will receive statements generated from two different platforms. Cutting over at the end of a billing period lets you issue final statements from the old system, transfer all open balances, and start fresh in the new system without confusion.

In practice, most firms target the first day of a new fiscal quarter that coincides with the day after a payroll run posts. For a firm with biweekly payroll, that might mean identifying the first Friday payroll that falls on or just before March 31, June 30, September 30, or December 31, processing that run in the old system, then switching to the new system for the following pay period that starts the new quarter. This alignment typically requires the cutover decision to be made at least one full quarter in advance so you can schedule data extraction, mapping, testing, and user training around the target date.

Building and Testing the Migration Package

Once you have defined your scope and mapping rules, the technical migration follows a multi-pass workflow.

Extract full transaction detail from the old system. Most platforms support CSV or Excel export of invoices, bills, payments, and payroll runs, but watch for row limits (Excel caps at 1,048,576 rows) and encoding issues with special characters in customer or vendor names. API-based extraction is cleaner when available and avoids the manual export/download loop, but not all legacy systems expose subsidiary-ledger data through their APIs. Pulling payroll data often requires elevated permissions or assistance from your payroll administrator because wage data is considered sensitive.

Transform the extracted data according to your field map. This step includes recoding account numbers, vendor and customer IDs, class and department codes, and any custom fields; splitting or consolidating records where necessary; reformatting dates; and populating required fields that were optional in the old system. You will also need to handle orphaned records—payments that reference invoices not in your migration set, or invoice line items that reference deleted or inactive accounts—by either expanding the migration scope to include the missing records or posting adjustment entries to reconcile the differences.

Validate the transformed data before you load it. At minimum, check that total debits equal total credits for AP and AR batches, that per-employee YTD totals match your last filed 941, and that aging reports from the transformed data match aging reports from the old system. Run a trial import into a sandbox or test instance of the new system and review error logs for validation failures, duplicate key violations, and missing required fields. Expect multiple rounds of correction: the first test load typically surfacesundefinedtoundefinedissues that require mapping adjustments or data cleanup in the source system.

Load the validated data into the new production system during a scheduled maintenance window. Post the opening balance journal entries for any accounts not covered by the detailed migration. Reconcile every subsidiary ledger to its controlling account in the general ledger: AR sub-ledger total to AR control account, AP sub-ledger total to AP control account, payroll liability accounts to the payroll detail. Any variance must be researched and resolved before you reopen the system for daily use.

Parallel run for at least one cycle. Continue maintaining the old system in parallel with the new system for one pay period, one billing cycle, or one month—whichever is appropriate for your business. Enter new transactions in both systems (or enter them in the new system and verify the old system would have produced the same result for historical transactions). Compare aging reports, payment histories, and tax reports side by side. This parallel period gives your team confidence that the new system produces the same outputs as the old one and provides a fallback if you discover a critical mapping error early.

LedgerSwitch automates much of this workflow by maintaining pre-built field maps for common platform pairs, handling the extract-transform-load orchestration, and generating reconciliation reports that highlight variances between source and target. For complex migrations involving payroll and multiple subsidiary ledgers, automation reduces the timeline from four to six weeks down to two to three weeks and eliminates entire classes of manual error, but you still own the upfront decisions about scope, cutover timing, and mapping rules. Learn more about how it works and typical migration timelines.

Common Pitfalls and How to Avoid Them

Even with careful planning, subsidiary-ledger migrations hit predictable snags.

Dirty source data is the number-one cause of migration delays. Duplicate vendor records, invoices with missing dates, customers with invalid ZIP codes, payroll runs with unbalanced deductions—every data quality issue in your old system becomes a blocker in the new one because modern platforms enforce stricter validation rules. Begin data cleanup at least two weeks before your scheduled extraction date. Deduplicate vendor and customer lists, fix incomplete addresses, close or void draft transactions that should have been finalized, and reconcile any subsidiary ledger accounts that do not tie to the GL.

Mismatched open-item balances occur when an invoice shows as paid in the GL but still appears open in the AR sub-ledger, or vice versa. This typically happens when someone posted a manual journal entry to adjust an account without applying the corresponding payment or credit in the subsidiary ledger. Before migration, run an open-item report for AP and AR and reconcile it to the GL balance. Any invoice older than your payment terms that still shows as open is a red flag.

Tax withholding mismatches between payroll detail and filed forms will trigger IRS notices. Before migrating payroll, pull a year-to-date wage and tax report from the old system and compare the federal income tax, Social Security, and Medicare totals to your last filed Form 941. If they do not match within a few dollars (rounding differences are normal), investigate and correct the discrepancy in the old system before you migrate. Migrating incorrect YTD totals will carry the error forward and force you to file amended returns.

Losing payment application detail happens when the migration process consolidates multiple invoice payments into a single lump sum. If a customer paid three invoices with one check, you need to preserve which invoices that check satisfied and in what amounts. Otherwise, your aging report will show old invoices as open even though the customer paid on time. Make sure your migration tool or script preserves payment application records, not just payment totals.

Cutover coordination failures create the "which system do I use?" problem. Communicate the cutover schedule clearly: afterundefinedPM on Friday, June 30, the old system is read-only for reference; all new transactions go into the new system starting Monday, July 3. Assign someone to monitor both systems during the first week to catch any team member who mistakenly enters a transaction in the old system out of habit.

Frequently Asked Questions

Do I need to migrate payroll history if I only switched accounting software and kept the same payroll provider?

If your payroll processing remains with the same third-party provider (ADP, Paychex, Gusto, etc.), you typically do not need to migrate payroll transaction history into your new accounting system because the payroll provider retains that data and continues to generate W-2s and tax filings from their records. You only need to migrate the summary journal entries that post payroll expense and liabilities to your general ledger. However, if you are moving from a third-party provider to in-house payroll or switching payroll providers, you must migrate at least the current calendar year of payroll detail to maintain year-to-date totals and tax withholding accuracy.

How far back should I migrate AP and AR transaction history?

Most firms migrate the current fiscal year plus one or two prior years of detailed transaction history for accounts payable and receivable. This range covers the invoices and payments your team actively references, supports customer and vendor inquiries, and satisfies typical audit lookback periods. Older history can be summarized as annual or quarterly totals, or retained in read-only archives of the old system. If your contracts include long payment terms, retainage provisions, or warranty claims that reference transactions older than two years, extend your migration window accordingly.

Can I migrate AP and AR without migrating the general ledger?

Technically yes, but in practice the subsidiary ledgers and GL must migrate together to maintain referential integrity. Every AP invoice and AR invoice posts to GL accounts, and the sum of the sub-ledger detail must equal the balance in the corresponding control account. If you migrate only the subsidiary ledgers and post opening balances manually in the GL, you risk discrepancies that will take weeks to reconcile. Migration tools like LedgerSwitch migrate the GL and subsidiary ledgers as a coordinated package, ensuring every invoice, payment, and journal entry lands in the correct account with the correct balance.

What happens to recurring invoices and bills during migration?

Recurring invoice templates and scheduled bills are configuration, not transactional data, and must be recreated manually in the new system rather than migrated via data import. Before cutover, document every recurring invoice (monthly service contracts, subscription billing, retainer agreements) and every recurring bill (rent, utilities, software subscriptions) with the recurrence pattern, amount, start and end dates, and customer or vendor. After migration, set up the recurring templates in the new system and verify the first generated invoice or bill matches your expectations. Do this during the parallel-run period so any mistakes surface before you turn off the old system.

How do I handle open purchase orders and sales orders during migration?

Open purchase orders and sales orders reference future transactions and typically do not migrate as cleanly as historical invoices and payments because every platform handles order fulfillment workflow differently. The safest approach is to fulfill or close all open orders in the old system before cutover, then create new orders in the new system for any ongoing work. If that is not practical—for example, you have multi-month projects with partial billing—migrate the orders as reference data, manually recreate them in the new system with current status, and reconcile billed versus unbilled amounts carefully to avoid double-billing or lost revenue.

What reports should I run to verify the migration was successful?

Run these reconciliation reports in both the old and new systems immediately after migration and again after the first full billing and payroll cycle: an aged accounts receivable report grouped by customer, an aged accounts payable report grouped by vendor, a payroll summary showing quarter-to-date and year-to-date totals by employee, a balance sheet to confirm all control account balances match, and a general ledger detail report for AP, AR, and payroll liability accounts to verify transaction-level detail transferred correctly. Any variance greater than a few cents due to rounding requires investigation and correction before you finalize the cutover.

Balancing Completeness With Practicality

Migrating payroll and AP/AR history transforms a straightforward GL migration into a multi-week project requiring coordination across accounting, payroll, IT, and operations. The reward is continuity: your team keeps the transactional detail they rely on daily, your auditors see an unbroken trail, your customers and vendors experience no disruption, and your compliance filings remain accurate.

The key is defining your scope early, cleaning your source data before extraction, building a field map that preserves the relationships your business depends on, and timing your cutover to align with natural cycle boundaries. Test thoroughly in parallel, reconcile every account, and document the mapping decisions you made so the next person to touch the system understands why certain fields map the way they do. When done right, a full subsidiary-ledger migration feels seamless from the user's perspective—the system changed, but the data did not.