Payroll Migration Plan: Control the Cutover and First Live Pay Run
Updated: 20 hours ago
Choose the first live payday only after you have worked backward through funding, submission, review, and the final transfer of payroll history. A date on the implementation schedule is a proposal. It becomes a usable cutover date when the people responsible for payroll can show what will be paid, which system will pay it, and how they will respond if a required check fails.
This playbook is for a U.S. employer moving an existing payroll operation to another provider. It follows the work from the last old-provider payroll through the first new-provider run and the retirement of old access. It assumes you have already decided to change providers. If the decision itself is still open, separate the case for replacing the provider from the readiness to move.
The central control is a single release decision for a defined pay run. Historical data, live wages, tax filings, funding, and accounting each need an owner, but those owners must approve the same boundary. A migration can pass its employee import and still fail when a late bonus, a deduction change, or an automatic submission crosses that boundary.
Identify the implementation work that still needs an owner. A free SelectSoftware Reviews advisor conversation can help if your provider choice is still open or the selected service leaves essential work uncovered. Describe your pay calendar, transfer requirements, and the tasks your team cannot perform. Ask providers to document which work their quoted service covers.
Work backward from the first live payday
Build the schedule around the new provider's confirmed submission deadline and funding requirements for your account. Do not copy the old provider's deadline or assume a faster payment option will be available on day one. Ask for the effective deadline, time zone, bank-verification requirements, and any restrictions applying to a newly opened account. Record who will confirm that these conditions are satisfied.
From that deadline, reserve time for an independent review of the final payroll preview. Before review, allow time to resolve input exceptions. Before that, schedule the final historical-data load, configuration checks, and the rehearsal. A problem found in the rehearsal must leave enough time to repair and retest before the live submission cutoff. If it does not, the proposed payday needs another route.
There is no universal 30-day migration promise. ADP says switching speed depends on the services being used, the employer's priorities, and access to required data. Treat a provider's proposed schedule as specific to your workforce and service arrangement. A business with several pay groups, multiple states, and unsettled historical corrections needs different preparation from a business with one stable salary payroll.
Give every milestone a latest safe completion time and a consequence if it slips. “Finish configuration Tuesday” is weak unless Tuesday is early enough for retesting. “Approve bank setup by Tuesday at noon, or retain the old-provider payment route for this payday” is actionable only if the old route remains available and its cutoff has also been confirmed.
Protect reviewer availability as carefully as technical setup. A migration manager cannot approve the finance team's accounting mapping simply because the controller is away. Name a qualified backup and make sure that person has access to the relevant evidence. Schedule the release meeting while both a delay and the approved contingency remain possible.
Write the boundary before transferring data
Record the last old-provider check date, the first new-provider check date, and the pay periods attached to each. Include off-cycle runs and payrolls already scheduled for automatic processing. Distinguish the period employees worked from the date they are paid. Otherwise, a team can agree on “October payroll” while referring to different transactions.
For each pay group, identify the one authorized system that will issue the next payment. Keep test calculations out of the live payment route. During a parallel calculation, the old provider can remain the paying system while the new provider calculates a comparison, but confirm the new provider's supported test process before using it. Do not submit a second payable payroll merely to obtain a comparison report.
Use one controlled record for changes during the transition. A rate increase approved after the initial export must be logged, assigned, applied to the correct system, and included in the final validation. Choose a freeze point for the rehearsal dataset and another for live inputs. A freeze is an approval boundary, not a reason to ignore a legitimate employee change.
After the freeze, the payroll owner decides whether a late item belongs in the planned run, a corrected preview, or a separately approved payment. Reopen affected tests when the change alters their assumptions. A new work state, for example, deserves more than checking whether the employee's name still appears in the roster. Track the changed setting and the resulting payroll calculation.
Write tax and reporting responsibilities separately from payment responsibilities. Ask both providers to acknowledge who will handle the transition quarter, year-end forms, prior-period corrections, and notices concerning historical periods. Identify the legal entity and tax accounts covered by each agreement. Never infer filing ownership from the fact that the new provider has imported year-to-date totals.
For an ordinary payroll service provider or reporting-agent arrangement, the employer generally remains responsible for federal employment-tax duties. Publication 15 describes the different third-party arrangements and exceptions, including certified professional employer organizations. If the migration changes that arrangement or the employing entity, have the appropriate tax adviser establish the treatment before applying a routine software-switch plan.
Build a baseline that survives the last old run
Keep a dated source package for each entity and pay group. Include employee records, current pay settings, paid payroll registers, employee-level historical totals, deductions and employer contributions, tax reports, and the accounting information required to reconcile the transition. Identify which reports the receiving provider accepts. A tidy spreadsheet is not necessarily an acceptable import file.
Tie the baseline to a named completed payroll rather than an informal download date. Record the report parameters, employee population, check-date range, and preparer. Include people who were paid during the year even if they have since left, where their records belong in the required history. Keep a clear distinction between paid history and amounts waiting to be paid.
Reconcile at employee and company level. A company total can match while two employees' amounts are assigned incorrectly. Check earnings, taxable wage categories, employee and employer taxes, deductions, and contributions separately. Agree with the receiving provider which detail must be supplied by quarter or check date, instead of assuming one aggregate year-to-date figure meets every requirement.
Import completion is only one checkpoint. Gusto's payroll transfer automation guidance expressly separates data migration from setting up deductions, contributions, and other pay items. Its supported reports and availability also depend on the originating provider. This is a useful example of why an accepted history file cannot establish that a benefit deduction will run correctly next payday.
Verify each migrated pay item against its intended operation: when it starts, when it stops, how it is calculated, who it applies to, and how finance recognizes it. Compare a deduction election with the actual setup and effective date. Resolve tax-treatment questions using the plan's documentation and qualified advice rather than carrying an ambiguous legacy code into the new system.
After the last old-provider run, reconcile the change since the baseline. Include additional payments, voids, corrections, and deduction changes. Send only the provider-approved final update and keep its receipt or acceptance evidence. Recheck totals after that update; do not rely on a reconciliation completed before the final old payroll was paid.
Protect the source package using approved secure transfer and restricted access. Payroll exports contain sensitive employee information. Record who receives them and where the retained copies live. The migration team needs usable evidence, not a collection of uncontrolled attachments that become impossible to distinguish from the final version.
Rehearse the payroll you will actually release
Use the same approved inputs, pay dates, employee population, and configuration assumptions in both calculations. Make intentional differences visible before interpreting a variance. A planned benefit change should not be treated as a system error; an unexplained tax difference should not be dismissed as a planned change.
Compare individual pay results before relying on aggregate totals. For each meaningful difference, record the employee, affected component, amount, cause, owner, correction, and retest result. A net-pay match can conceal offsetting errors in tax or deduction components. Conversely, two systems can produce an explainable difference that requires a reviewed configuration decision rather than an arbitrary balancing adjustment.
Set acceptance rules before seeing the results. Use zero unexplained employee pay differences as a release control, while allowing documented, reviewed differences where the correct treatment produces a different result. This is a recommended operating standard for the migration, not a statutory tolerance or a promise that every calculation must be identical. Do not create a universal “close enough” dollar allowance.
Select exceptional transactions from your own payroll history. Test the scenarios that could invalidate the first live run: an employee changing location, a benefit deduction beginning mid-period, a variable payment, a retroactive correction, or a termination. Work with the provider and the appropriate adviser on legally sensitive calculations. A generic demonstration employee cannot stand in for the pay rules you use.
Prove the interfaces as well as the payroll engine. Reconcile approved time to imported time, including rejected records and later corrections. Test the accounting output against the intended department or job structure. Confirm that benefit and deduction changes reach the receiving setup once, with a clear owner for rejected or delayed records.
Retest the affected result after fixing a configuration defect. Then assess whether the fix affects other employees or pay items. Changing a deduction's calculation method for one employee can alter the whole enrolled population. Keep both the original failing comparison and the successful retest so the release reviewer can follow the correction.
Use the rehearsal to define what you need from the provider. Raise unusable comparison reports or an unclear correction owner with your selected provider before the first live run. If those service gaps require you to reconsider the purchase, a free SelectSoftware Reviews advisor conversation can help you explore alternatives. Ask prospective providers who supplies migration reports and resolves setup issues under the quoted service.
First Payroll Release Board
First-run sequence: freeze the payment boundary, prove the current final preview, authorize one release, then reconcile and hand off. An unresolved checkpoint means hold and retest; use the eight checkpoints below to record the decision.
Use this board for one entity and one identified pay run, repeating it where pay groups have different deadlines or owners. Record the payday, submission deadline and time zone, payroll owner, release approver, and fallback decision deadline at the top. For each checkpoint, add the actual result, evidence location, reviewer, review time, and any unresolved item. Keep these fields in your working record; the blocks below provide the acceptance criteria.
Use three statuses: Ready, Hold, or Not applicable with reason. Ready means the evidence has been reviewed against the current final preview. Hold means the run cannot proceed until the named issue is resolved. A blank entry is Hold. Do not total the statuses into a score: one unresolved payment, history, filing, or funding dependency can outweigh every completed setup task.
1. Boundary and payment ownership
Ready when: the last old-provider run, first new-provider run, pay periods, and any off-cycle payments are identified, with one authorized issuer for each payment.
Evidence: approved boundary statement, scheduled-payroll review, and acknowledgments from the people controlling submission.
Hold when: a test can initiate live payments, an automatic run remains ambiguous, or a late item has no assigned route.
2. Final employee and history population
Ready when: the final paid history and employee population reconcile to the source baseline plus documented changes after the last old-provider run.
Evidence: dated source registers, receiving-system reports, employee-level reconciliation, and acceptance of the final history update.
Hold when: an employee, quarter, correction, or pay component is missing or a control total has no explanation.
3. Current earnings and deductions
Ready when: rates, effective dates, recurring earnings, deductions, active garnishment orders, contributions, and relevant exception calculations agree with approved instructions.
Evidence: configuration review and rehearsal results for the people and pay items affected by the first run.
Hold when: import success is the only evidence, a deduction election lacks corresponding setup, or an unexplained pay difference remains.
4. Tax setup and reporting handoff
Ready when: the relevant tax accounts and settings are reviewed and transition-period filings, year-end reporting, notices, and corrections have explicit owners.
Evidence: provider confirmations and an employer review of the responsibility schedule, with specialist approval where required.
Hold when: both providers appear to own the same filing, neither has accepted it, or a tax-account dependency remains unresolved.
5. Funding and release authority
Ready when: the provider confirms account-specific funding and submission conditions, authorized users can perform the agreed actions, and the final preview has independent approval.
Evidence: funding confirmation, access check, approved preview, and the provider's actual cutoff.
Hold when: bank verification is pending, the approver lacks access, or the available time cannot support the authorized payment route.
6. Time and downstream outputs
Ready when: approved time reconciles to payroll and the tested accounting and benefit handoffs have usable outputs and named receiving owners.
Evidence: input comparison, interface rejection review, sample accounting output, and finance or benefits acceptance.
Hold when: a rejected feed affects pay or a downstream owner cannot explain or use the expected output.
7. Contingency still available
Ready when: a failed checkpoint has an approved response with a responsible person, a real deadline, and confirmation that the payment option remains available.
Evidence: provider-confirmed contingency, contact details, employee communication plan, and the decision time before the fallback cutoff.
Hold when: the only plan is “support will fix it” or reverting would create a second payment or an unclear filing record.
8. Post-release confirmation assigned
Ready when: named people will confirm submission status, funding, employee payment issues, tax-deposit evidence, and the first accounting reconciliation.
Evidence: a scheduled follow-up with required reports and escalation contacts.
Hold when: the implementation team plans to leave immediately after submission without an operating owner accepting the unresolved work.
Release record: identify the approved preview version, the approver and approval time, the person submitting, and the provider's confirmation. If the preview changes after approval, review the affected checks again. Only authorize release when every applicable checkpoint is Ready and no unresolved item contradicts the decision.
Decide what a failed checkpoint will change
Before live submission, a failed gate may mean delaying the provider cutover while retaining the confirmed old-provider route for the intended payday. That option depends on the old service remaining active, the required data being current, and its own funding and submission deadline. Keeping a login does not establish that it can still process your payroll.
If the fallback uses an old system after a final history export, identify the extra paid payroll that must subsequently reach the new provider. Reset the migration boundary and reconcile the updated history. Otherwise, the team can pay employees correctly while leaving the receiving system short of the latest wages and taxes.
After a payroll has been submitted, do not treat rollback as restoring a file. First establish whether it is only calculated, accepted for processing, funded, or already paid. Ask the provider about the supported cancellation or correction route for that exact status. A second submission in the old system can create duplicate payments if the first has progressed further than the team realizes.
An alternative payment method also needs a controlled record. Assign who validates the amount, obtains authorization, records the payment, and coordinates its tax and reporting treatment. Confirm applicable wage-payment requirements with the appropriate adviser. Operational pressure does not make an improvised route safe, and this guide does not prescribe one payment method for every state or failure.
Use a specific employee message if timing or payment delivery changes. State what has been confirmed, the expected next update, and whom employees should contact. Do not promise a revised arrival time before the payment route has been accepted. Keep employee questions out of an unmonitored implementation mailbox.
Close the first run before reducing oversight
Submission confirmation proves one stage of processing. It does not by itself prove that employees received the intended pay, deductions are correct, or the accounting handoff is usable. The payroll owner should collect the provider's status evidence, investigate reported payment problems, and compare the final register with the approved preview.
Finance should reconcile the payroll's cash movement and accounting output, including payroll liabilities and any timing differences. Identify the explanation and owner for each remaining item. A balanced journal entry can still carry an amount into the wrong department or leave a liability unresolved. Correct the mapping at its source and retain the reconciliation used to accept it.
For deductions and contributions, compare the payroll results with the receiving benefits or retirement process, or the garnishment payee. Confirm which party transmits funds or information and which party verifies acceptance. Avoid marking a deduction problem closed merely because its amount appears on the paystub. If the transition changed the handoff, verify that handoff directly.
Maintain employer access to federal tax-deposit evidence. The IRS recommends that employers monitor deposits when a third party makes them, including use of an EFTPS Inquiry PIN when the third party enrolls the employer. Distinguish a debit by the payroll provider from evidence of a tax deposit. Record who investigates a missing confirmation and when the issue must be escalated.
Continue heightened review until the new operation demonstrates stable inputs, repeatable approvals, usable outputs, and closure of migration exceptions. Choose the number of observed runs according to your pay frequency and remaining risks. A new quarterly bonus or benefit change may reveal behavior that two ordinary salary cycles never exercised.
Retire old access only after the handoff is complete
Keep the old provider's termination and access terms in the plan from the start. Confirm the dates for payroll processing, historical report access, tax services, and year-end forms separately. Removing every old account immediately after the first successful payment can destroy a useful route for resolving historical questions.
Export the records your organization must retain and test that they can be opened, understood, and traced to the corresponding periods. The IRS employment-tax recordkeeping guidance calls for at least four years of records after filing the fourth quarter for the year, with longer periods for certain credit-related records. That is not a universal retention period for every payroll, benefit, or state-law document; apply the requirements relevant to each record set.
End overlapping submission authority when the transition no longer needs it, while preserving approved read-only access where available. Remove obsolete integrations and credentials through the responsible system owners. Keep a record of what was disabled and what remains deliberately active for corrections or reporting.
Transfer the migration exceptions to a named ongoing owner with due dates and evidence requirements. Close the project when normal payroll and finance owners accept their procedures and retained records. A migration manager's departure should not be the event that decides whether the new payroll operation is ready for ordinary work.
For more operational checklists, use the Payroll Switching & Migration hub. The Decision Guides library also covers provider selection and the controls that remain after implementation.
Name the work your team will still own after go-live. Confirm any uncovered task with your selected provider before approving release. If a service gap requires a different provider, SelectSoftware Reviews offers free advisor-led matching. Describe the missing responsibility and ask prospective providers to document their implementation and ongoing scope.
Payroll migration questions
How many payrolls need heightened review?
Keep closer review for as many runs as needed to demonstrate reliable approvals, confirmed payments, and usable downstream reports. Set the review depth by pay frequency and unresolved exceptions. Include the first relevant bonus, deduction change, or other irregular transaction before assuming ordinary salary runs have exercised every important rule.
Can we skip the rehearsal for a small payroll?
Keep the validation proportionate to the payroll, but still prove the relevant pay settings and payment route. A small employee count does not remove a benefit, location, or tax-history issue. If a full parallel process is unavailable, agree an alternative proof process with the provider and document its limitations before release.
Does the new provider automatically cancel the old one?
Do not assume so. Confirm the cancellation responsibilities and effective service dates in writing with both providers. Historical access, tax filings, corrections, and payroll processing may require different end dates. Assign the employer's owner for obtaining and retaining those confirmations.
What if an employee change arrives after approval?
Log it, determine its required treatment, and reopen the affected preview and checks before submitting a changed payroll. Record a new approval against the revised version. If the change cannot be completed in the planned route, use the authorized exception process and verify the applicable payment requirements.
About the author
Ben Scott writes and maintains payroll decision guides for founders and operators. His work focuses on execution realities and how decisions hold up under growth, complexity, and controls and documentation pressure. He works hands-on in HR and leave-management roles that intersect with payroll-adjacent workflows such as benefits coordination, cutovers, and compliance-driven process controls.
