TL;DR
- The core decision: choose the cutover date and the cutover shape, not the provider. The provider is settled. What matters is where in the year you land the new system and how you handle the moment the first number disagrees with the last one you were comfortable paying.
- When doing nothing is right: when the contract renewal is more than nine months away and the cost of moving exceeds the cost of staying, doing nothing is a rational plan, not an avoided one.
- What has to be true for this to work: a named owner of year-to-date balances, a written reconciliation approach, and a parallel run long enough to catch two full cycles, including a month with an off-cycle event.
- How the options split: parallel, clean break, and phased by entity or geography. Each splits further by how much history migrates with the population.
- Decision rule: the question isn't "can we move?" The question is "what do we do on the morning of the first live run when the new system produces a number the old one wouldn't have?"
- The outcome to expect: a clean first cycle in the new system, defensible year-to-date balances, a written record of every reconciliation decision, and a recovery plan that has been tested before it's needed.
The 6:47 a.m. Phone Call
The payroll lead at a 1,400-person retailer is standing in a service alley behind the distribution centre when the first message lands. It's the second Friday of the month, the day the new provider's first live run is meant to clear. Her phone shows three things at once: a variance report from the old system, a stalled batch from the new one, and a finance director who wants the numbers in twenty minutes. She has been awake since four. The driver who would normally take the load out at seven has just messaged to say his pay slip from last month, the one already paid under the old system, was wrong by an amount he can describe exactly, and he wants to talk about it before he moves the trailer.
But this isn't, in the end, a story about that morning. That morning is the predictable surface of a decision that was finished six weeks earlier, on a Wednesday afternoon, when somebody chose a cutover date without first choosing what would happen on a morning exactly like this one. The cutover date was set. The parallel run was scoped. The reconciliation owner was identified in a meeting and then, because no one wrote it down, drifted. The real issue isn't how quickly the team can move the data. The real issue is what they have already decided to do when the first number in the new system disagrees with the last number they were comfortable paying.
When You Do Not Need to Act Yet
A payroll migration is sometimes a bad idea, and the rest of this piece only earns its keep if it earns that concession first. Four stages, in plain English.
Best tools for Payroll & Compensation
Your current setup is genuinely fine. Picture a 60-person marketing agency in a single city, on a supported platform that releases updates on a known cadence, with a payroll generalist who has been in the role for nine years and knows where every edge case lives. The team closes the books in three days, the variance report is trusted, and no one outside finance has a complaint. A salesperson walks in with a demo. The agency watches the demo. Nothing about what they saw changes a number they will pay next month. The right answer here is to do nothing, or to wait until a renewal forces the question. A migration driven by a sales cycle produces the same cost, the same risk, and a platform that does the same job a little differently.
Friction you can live with. Picture a 380-person professional services firm whose payroll platform works, but the year-end process takes eleven days instead of four, the manager self-service is broken in ways that create tickets, and the finance team has stopped trusting the variance report. Nothing has gone wrong in a legal sense. The team has simply stopped trusting the tool. A move is reasonable here, but it is a quality-of-life decision, not a compliance one, and it should be justified as such. The honest move is to attach a price tag to the friction. How much manager time does the broken self-service burn per quarter. How many finance days does the eleven-day year-end consume, and what is a day of finance time worth. Once that number exists, the cost of moving has something to be compared against. Without it, the conversation is vibes.
Real risk, and a deadline that won't move. Picture a 2,200-person organisation in a regulated industry about to double in size through an acquisition, where the current platform doesn't handle the acquired entity's pay structures cleanly, and where the first post-acquisition payroll has a fixed date that no one can move because it is dictated by the deal. The deadline is real, the population is changing, and the consequences of an error aren't abstract. This is the genuine migration, and the rest of this article assumes the reader is here. The trade-off is that real risk also forces real cost. The team has to accept that the parallel run, the reconciliation work, and the slower first cycle are not optional. Cutting any of them to save budget simply moves the cost from the implementation line to the error line.
The edge case that looks like action but isn't. Picture a board that has decided, for reasons that turn out to be about a relationship at a parent company, that the platform must change. The deadline is arbitrary. The population is flat. The current setup is supported. The right answer is often to push back, in writing, on the timeline and on the premise. A migration done because someone senior wants to leave a mark is a migration that runs late, costs more than it was quoted, and produces nothing the business didn't already have. The document that pushes back should name the cost of the move, the cost of the disruption, and what the business gets for the spend. Most of the time, the document is enough.
The Five Questions You Ask Yourself at 11 p.m.
Can we run two systems at once for two full cycles? A clean parallel is the cleanest test, because it produces real numbers from both systems for the same people in the same month. It's also expensive and most teams can't absorb it. If the answer is no, the parallel run has to be narrower in scope, and that decision has to be made before the cutover date, not during the first live run. The reason is that a narrowed parallel decided under pressure becomes a parallel that proves nothing. The reasoning behind the question is that the parallel is the only place to catch year-to-date disagreements before they get paid. Without it, the team is choosing to discover errors on the morning the money moves. If the answer is wrong, the team pays for an undetected error in the first cycle, spends the second cycle reconciling after the fact, and rebuilds trust for two more.
Who owns the reconciliation? Most cutovers fail this test, and the failure is invisible until the first run. The new provider will reconcile the data they converted against itself. The old provider will reconcile their last run against itself. Someone on the payroll team has to reconcile against both, and that role has to be named in writing with hours allocated in the week. If no one can answer who that is, the cutover isn't ready, and the date should move. The reasoning is that reconciliation is not a side task. It's the deliverable. If the answer is wrong, two systems disagree about year-to-date on the morning of the first run, and the team has no one with the authority to decide which number wins.
What happens to a year-to-date number the two systems disagree on? Year-to-date is the spine of the cutover. It feeds tax, it feeds contributions, it feeds caps. A difference of a small amount in one month becomes a real number in nine, and the real number becomes a filing correction. The team needs a written rule for which system wins, and when, and why, decided before the parallel run starts. The reasoning is that the rule written under pressure is the rule written to defend a position, not to be correct. If the answer is wrong, the team argues about the difference in the second cycle, picks a side without a basis, and carries a known error into the filing window.
What do we tell people if the first run is late? Not what do we do, what do we tell them. The answer has to be written, in plain language, before the cutover date, because the first run will be late in some way that no one predicted. The reasoning is that an unexplained late payslip is read as a missed payslip, and a missed payslip is the most expensive complaint a payroll team can receive. The answer needs to name when the money will land, what to do if it doesn't land, and who to call. If the answer is wrong, the people team fields ten times the normal ticket volume, the payroll lead spends the day on the phone instead of in the run, and the cycle slips further.
What is the rollback, and who decides to use it? The question sounds defeatist. It isn't. A rollback that has been written down and approved before the cutover date is the thing that lets everyone sleep, because the team knows the exit exists. A rollback invented at midnight is the thing that costs a run, because the people who have to approve it haven't been briefed. The reasoning is that the rollback decision will be made under time pressure by someone who isn't the payroll lead, and that person needs the criteria in their hand before the pressure arrives. If the answer is wrong, the team either rolls back too early because no one could defend staying, or stays the course too long because rolling back felt like admitting failure.
Three Honest Categories the Approaches Split Into
Parallel run for two full cycles. Both systems produce payroll for the same population for two months, a real run and a shadow run. The shadow run is compared against the live run, variances are investigated, and the cutover happens at the start of the third cycle. This is the cleanest test and the most expensive. It works when the population is stable, the headcount is moderate, and the budget can absorb the duplicate processing time. It fails when the team is small and the cycle is short, because the operational load of running two systems simultaneously is itself a source of error, and the shadow run becomes the thing nobody finishes. The trade-off the team is making is budget against certainty, and the certainty only exists if the parallel is genuinely two full cycles with at least one off-cycle event covered. One cycle proves the regular run. Two cycles with an off-cycle event prove the system. Anything less is a parallel in name only.
A regional retailer with ninety stores and a single payroll specialist runs a two-cycle parallel for a population of 520. The specialist works eighteen-hour days, misses two deadlines in the live system because of effort spent on the shadow, and the variances that surface in week three are real but come too late to act on. The cutover happens anyway because the contract has been signed, and the first live run in the new system carries forward a variance the team identified in week three and then forgot about in week four.
Clean break, no parallel. The new system goes live at the start of a cycle. The old system is closed after the last run it ever does. This is the cheapest and the riskiest. It works when the new provider has a documented, transferable onboarding process, when the data conversion is verified before go-live against an independent source, and when the team's tolerance for an error in the first cycle is non-zero. It fails when the team treats "no parallel" as a substitute for verification, and discovers on the morning of the first live run that year-to-date balances didn't migrate cleanly. The trade-off the team is making is speed against confirmation, and confirmation has to come from somewhere other than a parallel run. Pre-conversion reconciliation, dry-run conversions on a sample of records, and an independent count of migrated balances against the source of truth all serve the role a parallel would otherwise serve.
A 320-person SaaS company moves on a clean break in February, with no parallel. The provider has been told the population is straightforward. Three of the three founders have carried over equity compensation that doesn't map to the new system's tax treatment. The first run produces three numbers that are wrong by amounts that matter to the people they belong to. The fix takes four days. The trust takes longer.
Phased by entity or geography. The new system goes live for one business unit, one country, or one payroll group first, and rolls out from there. This is the most common shape for organisations above a certain size, and the most operationally honest. It works when the entities are genuinely independent, the pay calendars don't interact, and the year-to-date balances aren't shared across the cutover line. It fails when the entities share a chart of accounts, when cost allocations cross the cutover line, and when finance expects a consolidated report on day one that the phased cutover can't produce. The trade-off the team is making is risk concentration against consolidation speed, and the consolidation piece is the one that's almost always under-specified. A phased approach without a written consolidation plan is a phased approach that will surprise finance on the day the first cross-entity report is due.
A 4,800-person group with operations in three countries cuts over the smallest entity first, then the second, then the holding company. The first two go clean. The third fails on a cost allocation that crosses the cutover line, and finance spends nine days rebuilding a consolidated report by hand. The phased approach is right. The assumptions about consolidation are not.
Five Questions You Can Self-Assess Against
Do you've a written reconciliation owner? Not "someone is on it." A named person, with time allocated in their week, with a written brief that says what they're reconciling, against what, and to what tolerance. To answer it for your own organisation, look at the project plan. If the reconciliation owner isn't named with hours, or if the named person already has a full role, the answer is no.
Have you verified that the two systems agree on a full off-cycle event? Off-cycle means bonuses, terminations, retroactive adjustments, and any item that doesn't fit the regular calendar. A parallel run that only covers the regular cycle proves the regular cycle. The off-cycle test is the one that catches year-to-date errors. To answer it, look at the parallel scope document. If "off-cycle" is mentioned but no specific event is named, or if the named event is a small bonus and not a termination with a final pay, the answer is no.
Do you've a written rollback plan that has been approved in advance? The plan should say who decides, what triggers the decision, how long the rollback takes, and what is done about the payroll that may have already been paid under the new system. To answer it, ask whether finance, legal, and the leadership of the business have signed something. A plan that exists only in someone's head isn't a plan, even if the someone is the payroll lead.
Can your finance team tolerate a delay in the first consolidated report? If the answer is no, the cutover has to be timed so that the first report is produced under the old system, or finance has to be told in advance that the first consolidated report will arrive late. To answer it, ask finance directly, in writing, what they expect on day one of the new system. If their answer assumes the new system produces a clean consolidated report on day one and a phased cutover is the plan, the answer is no.
Has the people team written the message to employees? The first payslip in a new system looks different. The deduction lines are different. The net is sometimes different in ways that the employee can't parse. To answer it, look for a draft message and a sample payslip. If the message is generic ("there will be a new payroll system") rather than specific, or if the sample payslip hasn't been produced, the answer is no.
Six Decisions That Shape the Whole Cutover
The cutover date within the tax year
The date is the spine of the project. It determines what year-to-date balances have to be carried, what filings have to be sequenced, and how much history migrates with the first cycle. A cutover at the start of a tax year is the cleanest. A cutover mid-year means the new system has to pick up balances from the old one, and that transfer is the operationally honest description of the risk.
The weakness is that the cleanest date is rarely the available date. Acquisitions, contract renewals, and board-level decisions impose their own calendars, and the payroll team ends up working back from a date that was set for reasons that had nothing to do with payroll. The honest move is to surface the cost of an off-cycle cutover in writing, before the date is fixed, and to let the decision-makers decide with the cost in front of them.
Running parallel versus a clean break
The decision is between two forms of test. A parallel run tests the new system against reality. A clean break trusts the new system without a real-world comparison. The first is expensive, slow, and catches errors before they're paid. The second is cheap, fast, and pays the errors before they're caught.
The weakness is that a parallel run, badly scoped, proves nothing. A parallel that runs for one cycle, on a stable population, with no off-cycle event, and with variances reviewed only at the end, is a parallel in name only. The team has spent the budget and still doesn't know whether the new system is right. The honest move is to scope the parallel against the off-cycle events, not the regular cycle, because that's where the year-to-date errors hide.
How much history to migrate
The data that has to move is the data the new system needs to produce correct output from day one. For most populations, that's current employee record, current pay structure, and current year-to-date balances. For some populations, it's more. For terminated employees with open garnishments, it's the full garnishment history. For equity holders, it's the grant history.
The weakness is that more history means longer conversion, more variance to reconcile, and a higher chance of an old error being carried forward. Less history means a cleaner cutover and a higher chance of an error being introduced because the new system had to reconstruct something it didn't have. The honest move is to decide per population, not per company, and to write down what each population needs.
Who owns the balance reconciliation
The role isn't the new provider's. The new provider will reconcile the data they converted. They won't reconcile against the old system. The role isn't the old provider's, for the same reason. The role belongs to the payroll team, and the person in it needs to be senior enough to push back on both providers when the numbers disagree.
The weakness is that this role is rarely resourced. It's given to someone who already has a job, and the reconciliation is done in the gaps. The honest move is to name the role in the project plan, allocate time against it weekly, and treat the output as a deliverable with a sign-off.
What happens to in-flight items such as loans and garnishments
Loans and garnishments cross cutover lines in ways that are easy to miss and expensive to discover. A loan that started under the old system has a balance, a schedule, and a deduction amount that the new system has to honour. A garnishment that was active at cutover has a court order that the new system has to continue to apply. The handling has to be written down per item, or the new system will apply the default, and the default is usually wrong.
The weakness is that this work is invisible until it isn't. The team that handles loans and garnishments is rarely the team that runs the cutover project, and the items only surface when the first deduction is missed or the first court order is unpaid. The honest move is a separate workstream, with its own owner, that runs in parallel with the main cutover plan and reconciles per item before the cutover date.
The rollback plan nobody wants to write
A rollback is the path back to the old system if the first run in the new system fails in a way that can't be fixed within the cycle. The plan has to say who decides, what triggers the decision, and how long the rollback takes. It has to be approved in advance by finance, by legal, and by the leadership of the business, because the decision to roll back won't be made by the payroll team alone.
The weakness is that a rollback plan, once written, becomes the thing the leadership remembers. The cutover can succeed and the rollback can still be cited as evidence that the project was risky. The honest move is to write the rollback plan, file it with the right people, and not let it become the artefact that defines the project. The plan exists to make the cutover safer, not to memorialise the fear.
The Decision Table
| Situation | Scale | Setup | Primary Pain | Recommended Starting Point |
|---|---|---|---|---|
| Stable population, low regulatory pressure | Under 200 | Single entity, single country, single currency | Year-end takes too long | Wait. The cost of moving exceeds the cost of staying. |
| Stable population, mid-tier pain | 200 to 800 | Single entity, single country, multi-cycle | Self-service is broken, variance reports are unreliable | Phased parallel for two cycles on a single entity |
| Acquisition-driven, fixed deadline | 800 to 2,500 | Multi-entity, single country or single region | Acquired population does not map to current pay engine | Parallel for one cycle on the acquired entity, clean break on day one for the existing population |
| Multi-country, multi-currency | 2,500 to 5,000 | Multi-entity, multi-region | Consolidation across cutover line | Phased by country, with the smallest first and the holding company last |
| Regulated industry, fixed filing calendar | Any | Single or multi-entity | Filing window cannot slip | Parallel for two cycles, including one off-cycle, with the cutover at the start of a tax year |
| Mid-year, post-acquisition, year-to-date already complex | 1,000 to 4,000 | Multi-entity | Year-to-date balances must be carried mid-year | Parallel for two cycles, full reconciliation of year-to-date per employee, with a written rule for which system is authoritative on disagreement |
| Equity-heavy population | Any | Single entity | Equity treatment does not map cleanly | Parallel for two cycles, separate workstream on equity, with a tax adviser on the reconciliation |
| Outsourced payroll with stable provider | Any | Single provider, multi-entity | Service quality, not function | Re-procurement, not migration. The answer is a conversation with the incumbent, not a new system |
The Parallel Run, and How to Read It
A parallel run is a controlled experiment. The new system produces payroll for a population the old system is also paying. The output is compared. Variances are investigated. The cutover happens when the variances are within an agreed tolerance and the team can describe what each residual variance is and why.
A variance isn't automatically an error. A variance is a difference that needs an explanation, and the explanation is one of three things. The new system is right and the old system was wrong. The old system is right and the new system is wrong. Both are right and the difference is a timing artefact, a rounding rule, or a tax treatment that the systems have implemented differently.
The decision is whether to investigate the variance before cutover or to accept it as a known difference. The rule is that variances above a tolerance that affects an employee's net pay must be investigated. Variances below that tolerance can be documented as known differences and accepted. The tolerance has to be written, with a number attached, and the number has to be one that the leadership has agreed to in advance.
| Variance Type | What It Means | Action |
|---|---|---|
| Rounding only | The gross and net are correct, the line items differ by a small amount | Document as timing artefact, accept |
| Tax treatment differs | The new and old systems apply different rules for the same input | Investigate with tax adviser, decide which is correct, document |
| Year-to-date mismatch | The cumulative figures differ, but the current month is correct | Investigate balance migration, decide which system is authoritative, document |
| Off-cycle item missing | A bonus, termination, or retroactive adjustment does not appear in the new system | Fix the conversion, do not cut over until verified |
| Net pay wrong | The employee is paid a different amount than expected | Block cutover until resolved |
The First Live Run: A Sequence for the Day
The first live run in the new system has a sequence, and the sequence has to be rehearsed. The rehearsal is a tabletop exercise, run a week before the cutover, with the actual people who will own each step. The output is a written runbook that names the owner of each step, the time the step should complete, and what stops the run if the step doesn't complete.
The sequence below is a starting point, not a prescription. The actual steps depend on the provider, the payroll engine, and the team's structure.
| Step | Owner | What Stops the Run |
|---|---|---|
| Pre-run data validation | Payroll specialist | A mismatch between the new system and the source of truth on headcount, pay rates, or tax codes |
| Pre-run reconciliation of in-flight items | Loans and garnishments owner | An open item that has not been migrated to the new system |
| Batch initiation | Payroll lead | A failed batch with no recoverable cause |
| Variance review | Payroll lead | A variance above tolerance with no explanation |
| Approval to release | Finance director | A variance above tolerance that the payroll lead cannot explain |
| Bank file release | Treasury or provider | A bank file that fails the bank's pre-submission validation |
| Employee notification | People team | A payslip that does not match what the employee was told to expect |
| Tax and contribution filing preparation | Payroll specialist | A filing that cannot be produced from the new system in the required format |
What to Put in Writing
| Artefact | Who Owns It | When It Is Written | What It Prevents |
|---|---|---|---|
| Cutover plan with named owners | Project lead | Before the cutover date | Drift in ownership between signing and go-live |
| Reconciliation approach with rules | Reconciliation owner | Before the parallel run starts | Ad-hoc decisions on year-to-date disagreements |
| Variance tolerance with a number | Payroll lead, agreed by finance | Before the parallel run starts | A first-run variance that becomes a second-run argument |
| Rollback plan, approved | Project lead, signed off by finance and leadership | Before the cutover date | A rollback invented under time pressure |
| Employee communication, in plain language | People team | At least one cycle before cutover | A flood of employee questions on the first payslip |
| Off-cycle reconciliation, per item | Loans and garnishments owner | Before the cutover date | A missed deduction or a missed court order |
| Year-to-date balance map | Reconciliation owner | Before the cutover date | A balance disagreement that becomes a tax filing error |
| First run runbook, rehearsed | Payroll lead | A week before the cutover date | A first run that stalls because no one knew who did what |
| Provider responsibilities, written | Project lead | Before the cutover date | A responsibility that both providers assumed the other owned |
| Post-cutover review | Project lead | Within a week of the second live run | A repeat of the same error in the second cycle |
Questions to Ask Before You Commit
Ownership of year-to-date. "Who reconciles year-to-date balances against the old system, and how is that work resourced?" A bad answer is "the provider will handle it." A good answer names a person, a process, and a tolerance.
Scope of the parallel run. "What does the parallel run cover, and what does it not?" A bad answer is "everything." A good answer names the populations, the cycles, and the off-cycle events that are in scope, and what is explicitly out.
Tolerance for variance. "What variance between the two systems is acceptable, and who decided that?" A bad answer is "small amounts." A good answer is a number with a sign-off.
Rollback path. "If the first live run fails, what is the path back, and how long does it take?" A bad answer is "we would figure it out." A good answer is a written plan with a named decision-maker.
In-flight items. "How are loans, garnishments, and other in-flight items handled across the cutover line?" A bad answer is "they will migrate with the employee record." A good answer is a per-item reconciliation.
Off-cycle events. "What off-cycle events does the parallel run cover, and what does it not?" A bad answer is "the regular cycle." A good answer names bonuses, terminations, and retroactive adjustments.
Filing calendar. "How does the cutover interact with the filing calendar?" A bad answer is "the provider will handle it." A good answer is a sequence that names the filings before, during, and after the cutover.
Employee experience. "What will the first payslip in the new system look like, and what will be different?" A bad answer is "the same as before." A good answer is a sample payslip, side by side with the old one, with the differences explained.
Post-cutover support. "What support is in place for the first two cycles, and what does it cost?" A bad answer is "standard support." A good answer names the people, the response time, and the duration.
Reference. "Can you speak to a customer who has done a similar cutover?" A bad answer is "we've many customers." A good answer is a name, a number, and a permission to call.
The Cost of Getting This Wrong
The cost of getting a payroll cutover wrong isn't on the invoice. The invoice carries the implementation fee, the parallel run cost, and the provider's premium for a mid-year cutover. The real cost is the second-order kind, and it arrives in three forms.
The first is the trust cost. A first run that's wrong, even by a small amount, and even for a small number of employees, sets the tone for the next two years. The people team will spend the next cycle explaining what happened, the finance team will spend the next cycle reconciling, and the leadership will spend the next cycle wondering whether the right decision was made. The cost isn't the fix. The cost is the attention.
The second is the filing cost. A first run that produces a year-to-date error becomes a filing error at the next filing window. The filing error becomes a correction, and the correction becomes an audit trail that the team has to defend for the next two years. So the question isn't "what does the implementation cost?" The question is "what does a correction cost across two filing cycles?"
So the right frame isn't the cost of the cutover at all. The right frame is the cost of the cutover plus the expected cost of the errors you've not yet planned for, discounted by the probability that the parallel run actually catches them. Most teams price the first and ignore the second. The teams that price both are the teams whose first live run is uneventful.
When You Are Ready to Go Further
If the cutover plan is settled and the team is past the decision-making stage, the next move is comparison. HROpsLab publishes independent, side-by-side comparisons of payroll platforms, written for the person who has already chosen to move and now needs to choose well. The comparisons cover data conversion, off-cycle handling, year-to-date migration, and the parts of the contract that decide what happens when something goes wrong.
We don't sell software. We don't provide payroll services. We don't give legal or tax advice. We write the comparison the team would write if it had the time, and we update it when the market changes.
Frequently Asked Questions
When in the year should I cut over?
The cleanest cutover is at the start of a tax year, because year-to-date balances reset and the new system starts fresh. A mid-year cutover means migrating balances from the old system, which is the operationally honest description of the risk. If the date is fixed for reasons outside payroll, the right move is to surface the cost of an off-cycle cutover in writing before the date is locked, and to ask the decision-makers to confirm with the cost in front of them.
Should I run parallel, and for how long?
A parallel run is a controlled test, and it's worth the cost when the population is non-trivial or the off-cycle events are real. Two cycles is the minimum, because one cycle catches the regular run and the second catches an off-cycle event. A parallel run that covers only the regular cycle proves the regular cycle and nothing else, and the team will pay for what it didn't test in the first live run.
How much history should I migrate?
The data the new system needs to produce correct output from day one. For most populations, that's current employee record, current pay structure, and current year-to-date balances. More history means longer conversion and more variance to reconcile. Less history means a cleaner cutover and a higher chance of an error being introduced because the new system had to reconstruct something it didn't have, so the decision should be written per population.
What happens to year-to-date balances at cutover?
Year-to-date is the spine of the cutover. It feeds tax, it feeds contributions, it feeds caps. A difference of a small amount in one month becomes a real number in nine. The team needs a written rule for which system wins, and when, and why. The rule is written before the parallel run starts, not after the first disagreement, because a rule written under pressure is a rule written to defend a position.
Who is liable if the first run is wrong?
Liability depends on the contract and on local law, and the answer is the kind of answer that has to come from a lawyer and a tax adviser, not from a blog. What the team can do is document who made which decision, and on what basis, and leave the documentation in a place where the adviser can find it. The documentation is what makes the conversation with the adviser short instead of long.
Should I keep the old system open after cutover?
Yes, for at least one full cycle after the cutover. The old system is the reference point for any disagreement about what the new system produced. Closing the old system on the cutover date removes the ability to reconcile, and the reconciliation is the only evidence the team has that the cutover was correct. The cost of keeping the old system live for one more cycle is small compared to the cost of being unable to answer a question about the first cycle.
What do I do if the first run fails?
The answer is in the rollback plan that was written and approved before the cutover date. The plan names who decides, what triggers the decision, and how long the rollback takes. A plan that exists only in someone's head isn't a plan, and the first run isn't the time to invent one, because the people who have to approve the decision haven't been briefed and will reach for the safest option, which is rarely the right one.
How do I tell employees what to expect?
In plain language, in advance, with a sample payslip that shows what will be different. The first payslip in a new system looks different. The deduction lines are different. The net is sometimes different in ways that the employee can't parse. A written message, sent at least one cycle before cutover, prevents most of the questions that would otherwise arrive on the morning of the first run, and lets the people team spend the day on real issues instead of reassurance.
HROpsLab is the review publication payroll and people operations leaders use to compare platforms, contracts, and providers without the sales pitch.
