TL;DR
- The core decision: how much proof you want before the first run goes to real people.
- When doing nothing is right: when the date can move and the data is not ready.
- What has to be true: the data is right, and somebody has checked it against something.
- How the options split: by whether you prove the system before trusting it, or after.
- Decision rule: run in parallel until the differences are explained, not until they disappear.
- Outcome to expect: a dull first run, which is the only acceptable kind.
The Only Go-Live Everybody Notices
Most systems go live and a few people notice. Payroll goes live and every single employee finds out the same day, at the same moment, with the evidence in their own bank account.
That's what makes this different from any other implementation in HR. A reporting tool that launches badly is an annoyance. A payroll that launches badly means somebody's rent doesn't clear, and the damage isn't administrative, it's a person's confidence that their employer can be relied on to pay them. That confidence is easy to lose and slow to rebuild, and it isn't recovered by fixing the underlying problem quickly.
The good news is that the failure mode is narrow and predictable. Almost every bad first run traces to data rather than to the system: a value that didn't come across, a figure that came across in the wrong form, a population somebody forgot, an element configured against an assumption nobody checked. The calculation is rarely at fault. What it was given usually is.
Best tools for Payroll Software
So the useful way to think about standing up payroll is as a data exercise with a date attached. The configuration work is real but bounded; the data work is where the risk sits, it expands the closer you look, and it's the part that determines whether the first run is boring.
The second thing worth settling early is how you'll know it's right before you find out the expensive way. Running in parallel, producing the same period on both the old arrangement and the new and comparing them, is the only check that proves anything. Everything else is inspection, and inspection finds what you thought to look for.
What has to carry across, what has to be retained, and what has to be reported differ by jurisdiction and change. Opening balances, year-to-date positions and historic records all sit in that territory. Nothing here tells you what applies to you. Establish it with local advice, per place you pay people, before the data work starts, because it determines what you have to bring.
When You Genuinely Do Not Need to Act Yet
The date is fixed and the data is ready. If what needs to move has been checked and a parallel period has been compared, proceed. That's the state you're aiming for and it's worth recognising when you've reached it.
The date is fixed and the data is not ready. This is the common position and it feels like a scheduling problem. It's a decision: either move the date or accept a run that hasn't been proved, and pretending there's a third option is how bad first runs happen.
Differences in the parallel run are unexplained. Not large, just not understood. That's a stop condition rather than a tolerance question, because a difference you can't explain is one you can't rule out repeating.
The edge case that forces it. A population nobody included, or a category of payment nobody carried across, discovered late. Worth treating as a signal that the data scope was never properly established, rather than as one item to fix.
Five Questions This Reader Asks at 11pm
What actually has to be ready before the first run? People and their terms, everything that varies this period, the standing elements, the historic position that has to carry across, and the banking arrangements. Each needs somebody who confirms it, by name. The list is short; establishing each item properly is not.
What is a parallel run? Producing the same pay period twice, once on the existing arrangement and once on the new one, then comparing them line by line. It's the only test that exercises real data through the real configuration, and it's the difference between believing the system is right and knowing where it differs.
How many parallel periods do you need? As many as it takes for every difference to be explained. That framing is more useful than a number, because a single clean period proves more than several with unresolved differences, and the point is understanding rather than repetition.
Can you go live mid-period? It's possible and it's harder, because the period splits across two arrangements and somebody has to combine the halves correctly. Where a date has slipped, extending to the next period boundary is almost always the better answer.
What if the first run is wrong? Have the plan before you need it: how you correct, how quickly somebody can be paid properly, who tells them, and what they're told. The speed and honesty of that response matters more to people than the error itself.
What Has to Be Right Before the First Run
| Item | Who confirms it | What happens when it is wrong |
|---|---|---|
| Every person who should be paid | Whoever owns the employee record | Somebody is not paid at all |
| Nobody who should not be paid | Whoever owns the employee record | A payment to somebody who left |
| Rate and terms for each person | HR, against the source of record | Wrong amount, every cycle |
| Standing elements and deductions | Whoever set them up, item by item | Quiet, repeating, hard to spot |
| Variable input for this period | Whoever owns each input | A short or inflated first payment |
| The historic position carried across | You, with local advice | Wrong treatment, wrong reporting |
| Bank details for every person | Verified against a second source | Payment to the wrong account |
| The payment file format and route | Whoever will release it | Nothing arrives, on the day |
| Who approves, and who can act | Named before go-live | Nobody able to release it |
The fourth row is the one that hides. Standing elements are set up once, apply every period, and never draw attention afterwards, so an error configured at the start looks entirely normal forever. Check them individually rather than by sampling, because sampling finds the common cases and the error will be in an uncommon one.
The sixth row is where jurisdiction matters most and where assumptions are most dangerous. What has to carry across, in what form, and how it affects treatment for the rest of the period differ by place and change. Establish it properly with local advice rather than inferring it from how the previous arrangement behaved.
The seventh row deserves independent verification. Bank details that came across in a migration should be checked against something other than the file they came from, because an error here sends money to the wrong place and is the hardest of all these failures to unwind.
Five Diagnostic Questions You Can Self-Assess Against
Who is on your list, and where did the list come from? Most missing-population problems trace to a list drawn from one system that didn't include everybody. Check it against a second source, ideally one nobody thought of as a payroll source.
Can somebody explain every difference in the parallel run? Not tolerate, explain. An unexplained difference is an unknown, and unknowns in payroll are what reach people.
What is the plan if the first run is wrong? If there isn't one, that's the highest-value hour available before go-live, because the response is what people actually judge you on.
Who has authority to release the payment on the day? Name them and a substitute. Go-live dates have a way of coinciding with somebody's absence.
What happens if you are not ready? Decide the criteria and the decision point now, while it's abstract. Made under pressure a few days out, this decision goes the wrong way almost every time.
Work through these five with the people doing the data work rather than with whoever is reporting on the project. Status reports smooth over the items that are nearly done, and nearly done on a payroll data item means not done, because the first run does not accept an approximation.
Six Ways Payroll Gets Stood Up, Reviewed
A hard cutover at the start of a new period
The old arrangement produces its last period, the new one produces the next, with no overlap. It earns its place on simplicity and a clean boundary: one arrangement per period, no reconciliation between halves, no ambiguity about which produced what.
Where it falls short is that nothing has been proved. The first run on real data is also the first run that reaches people, so every configuration assumption is tested in production with an audience of everybody you employ.
Defensible only for a genuinely new payroll with few people and simple terms. Anywhere else, the absence of a parallel period is an unnecessary risk on the one go-live that's most visible.
Where you have no choice, spend the time you saved on manual verification instead. Check every person's terms against the source record by hand, examine each standing element individually, and calculate a handful of people's results yourself before the run produces them. That is slower than a parallel comparison and it is far better than nothing.
Also pick the smallest population you can go live with first if any split is possible at all, because containment is the only protection left once the proving step is gone.
A parallel run for one period before switching
The same period is produced on both arrangements and compared before the new one takes over. It earns its place as the highest-value single step available here, because it exercises real data through real configuration and produces a list of differences to explain.
Where it falls short is capacity and interpretation. Producing a period twice is genuine extra work at a time when the team is already stretched, and the output is a list of differences that somebody has to work through rather than a verdict.
The right default for most implementations. Budget properly for the comparison, because reading the differences is the work, not producing them.
Decide in advance who does the comparison, and make sure they know the population. Somebody unfamiliar with your people can tell you that two figures differ; only somebody who knows the organisation can tell you whether the new figure or the old one is the right answer.
The timing matters too. Schedule the parallel far enough before go-live that there is room to fix what it finds and run again. A parallel that completes a few days out produces findings nobody has time to act on, which is the same as not running one.
A parallel run for several periods
The parallel continues across more than one cycle before the switch. It earns its place where the payroll has real variety: populations that behave differently, elements that only appear in certain periods, patterns that a single period wouldn't exercise.
Where it falls short is fatigue and diminishing returns. Running double payroll for several cycles is exhausting, and after the differences are understood, further periods mostly confirm what's already known.
Worth it where meaningful variation exists between periods. Stop when differences are explained rather than when a planned count is reached.
The variation worth covering is structural rather than seasonal. Elements that appear only in certain periods, populations paid on a different pattern, anything that happens at a period boundary: these are what a single cycle will miss and what additional cycles are for.
Be realistic about what the team can sustain. Running double payroll is genuinely tiring, and a team pushed through several cycles of it will do the later comparisons less carefully than the first, which defeats the purpose of running them.
A phased rollout by population or entity
One group moves first, the rest follow later. It earns its place on containment: a problem affects one population rather than everybody, and the first group teaches you what the later ones need.
Where it falls short is duration and duplication. Two arrangements run simultaneously for an extended period, the team operates both, and reporting spans a boundary. The transition also stops feeling like a project and starts feeling like the permanent state.
Sensible where populations are genuinely separable. Choose a first group that's representative rather than easy, or it teaches you nothing.
The temptation is always to start with the simplest population, because it is most likely to go well. That produces a successful first phase that proves almost nothing, and the difficulties arrive later with less attention on them and less appetite to stop.
Set an end date for the phased period and treat it as real. Transitions that run long stop being projects and become the way things are done, with two arrangements maintained indefinitely because nobody owns finishing.
A mid-period cutover because a date slipped
The switch happens partway through a period, usually because something ran late. It earns its place only as a response to circumstance, and the honest framing is that nobody would choose it.
Where it falls short is everywhere. The period splits across two arrangements, somebody has to combine halves correctly, anything proportional has to be handled by hand, and the reconciliation is exactly the kind of one-off work that generates errors.
Avoid if at all possible. Extending to the next period boundary costs a delay; a mid-period split costs a reconciliation that nobody has done before and everybody is rushing.
If it genuinely cannot be avoided, write the reconciliation method down before the period starts and have somebody other than its author check the logic. The errors in this situation come from the combination step rather than from either arrangement, and that step is being designed under pressure.
Tell people what is happening as well. A period handled in two halves can produce a payslip that looks unfamiliar, and an explanation sent in advance prevents a large number of worried questions arriving at once.
Going live with the provider running the first cycle
An external party operates the first run, with your team observing. It earns its place on expertise at the highest-risk moment, since somebody who has done this before is running it rather than somebody doing it for the first time.
Where it falls short is learning. Watching somebody else run a cycle teaches far less than running it, so the team's first unassisted run is still a first run, just later and with less attention on it.
Reasonable for the first cycle. Make sure your team performs the second one with support available, rather than the fourth one alone.
Agree what observing actually means before the cycle starts. Watching a screen share teaches almost nothing; sitting with the person, asking why each step happens and what they are checking, teaches a great deal, and the difference has to be arranged in advance.
Also establish who is accountable for that first run being correct. An external party operating it does not necessarily carry responsibility for the outcome, and that is worth being clear about rather than assuming, ideally with local advice.
The Decision Table
| Situation | Scale | Setup | Primary Pain | Recommended Starting Point |
|---|---|---|---|---|
| Data checked, parallel period explained | Any | Any | None | Proceed |
| Date fixed, data not ready | Any | Any | A decision, not a schedule | Move the date |
| Differences small but unexplained | Any | Parallel | An unknown, not a tolerance | Stop until explained |
| New payroll, few people, simple terms | Small | New | Limited to compare against | Hard cutover, checked carefully |
| Real variety between periods | Any | Replacement | One period proves too little | Parallel across several |
| Populations genuinely separable | Any | Replacement | Blast radius | Phase, starting representative |
| A date has slipped | Any | Any | Pressure to split a period | Extend to the next boundary |
| First run on real data is go-live | Any | Hard cutover | Nothing proved | Add a parallel period |
| No plan if the first run is wrong | Any | Any | The response people judge | Write it before go-live |
The second row is the decision this whole exercise turns on and it's rarely framed as one. When the data isn't ready and the date is fixed, something gives, and the only question is whether it gives before the run or during it. Moving a date is embarrassing for a week. A bad first run is remembered.
The third row is worth holding firm on. Small differences are tempting to accept because they look immaterial, and a difference you can't explain is not small, it's unknown, and the same cause may produce a large difference next period on a different population.
The ninth row is the cheapest item on the entire list and the most frequently skipped. Writing down what happens if somebody is paid wrongly takes under an hour, needs no system access, and is the difference between a response that reassures people and one that leaves them chasing an answer while short of money.
What a Parallel Run Actually Proves
The point is the differences, not the match. A parallel run that matches exactly proves the new arrangement reproduces the old one, which is useful and slightly suspicious, because two independently configured payrolls rarely agree to the last figure. Differences are the normal outcome and they're the information.
Every difference has a cause, and the cause is what matters. Some are the new arrangement being right where the old one was wrong, which is a finding worth capturing. Some are configuration errors. Some are data. Until each one is attributed, none of them can be dismissed.
The comparison is the work. Producing the second run is mechanical; working through a list of differences person by person is not, and it's the part that gets squeezed when the date is close. Budget for it as the main task rather than as a check at the end.
Record what each difference turned out to be. The explanations accumulate into a description of how the two arrangements actually differ, which is useful long after go-live, particularly when somebody asks why a figure changed at the transition.
Compare at the level where errors live. Totals can match while individual figures are wrong in offsetting ways. The comparison has to reach individual people and individual elements, because that's where a configuration error shows up.
Unexplained differences are a stop condition. This is the hardest thing to hold to under schedule pressure, and it's the single rule that most reliably prevents a bad first run. An unexplained difference means you don't know why the two arrangements disagree, and going live is a decision to find out from your employees.
Include the awkward people deliberately. Anybody part way through a change, anybody with unusual terms, anybody who joined or left mid-period, anybody with an uncommon element. Standard cases pass everywhere; the errors are in the cases nobody built for.
A difference explained once still needs checking again. Where a cause is found and corrected, the next parallel period is what confirms the correction worked. Fixing something and assuming it is now right is how a known issue reaches the first live run in a slightly different form.
Where These Arrangements Go Wrong
| The failure | How it shows up | What would have to change |
|---|---|---|
| No parallel period | Configuration tested on real people | Run one, even under pressure |
| Comparing totals only | Offsetting errors, both wrong | Compare individuals and elements |
| Differences accepted, not explained | The same cause, larger, next period | Explain every one |
| Standing elements sampled | A quiet error repeating forever | Check each one individually |
| A population missing from the list | Somebody not paid at all | Draw the list from two sources |
| No plan for a wrong first run | A slow, defensive response | Write it before go-live |
The fifth row produces the worst individual outcome on this list. Somebody who simply isn't paid, because they were never on the list, experiences a complete failure rather than an error, and it's usually a group that sits outside the main employee record, which is exactly why nobody thought of them.
The sixth row is about what happens after something goes wrong, which is the part most within your control. People are considerably more forgiving of an error handled openly and quickly than of one handled slowly while somebody works out who to tell.
The second row catches teams who did run a parallel and still went live on an unknown. Matching totals feel like confirmation and they are compatible with individual figures being wrong in ways that cancel out, which is a real pattern rather than a theoretical one. The comparison has to go down to the person.
What to Put in Writing
| Artefact | Who owns it | When it is written | What it prevents |
|---|---|---|---|
| The population list, from two sources | Whoever owns the record | Before data work | Somebody not paid at all |
| What must carry across, per jurisdiction | You, with local advice | Before data work | Wrong treatment and reporting |
| Confirmation owner per data item | Project owner | Before data work | Items nobody verified |
| The parallel comparison, explained | Whoever runs payroll | Before go-live | Going live on an unknown |
| Go or no-go criteria, and who decides | Project owner | Early, while abstract | A pressured decision, made late |
| The plan for a wrong first run | Whoever runs payroll | Before go-live | A slow, defensive response |
The fifth row is worth writing while the date still feels far away. Criteria agreed in advance, with a named decision point, are the only thing that makes a delay possible, because a few days out the pressure runs entirely one way and nobody wants to be the person who stopped it.
The third row is what prevents the most common data failure, which is not an incorrect item but an unowned one. Anything without a named person who confirms it will be assumed correct by everybody, and assumptions are what survive right through to the first run.
Questions to Ask Before You Commit
On data. What has to carry across, and who says so? A bad answer is everything.
On the parallel. How will differences be worked through? A bad answer is that they should match.
On scope. Who is on the list, and from where? A bad answer is the HR system.
On the date. What happens if we are not ready? A bad answer is that we will be.
On the day. Who can release the payment? A bad answer is the team.
On failure. What if somebody is paid wrongly? A bad answer is that we will fix it.
What Getting This Wrong Costs
The first cost is trust, and it's the one that doesn't repair on the same timescale as the error. Somebody who isn't paid properly has an immediate practical problem, and afterwards a lasting doubt about whether it will happen again, which surfaces every subsequent pay day. No amount of technical explanation addresses that, because the concern isn't technical.
The second cost is the quiet error that persists. A standing element configured wrongly at setup applies correctly every period thereafter, produces no anomaly, and is found much later, at which point the correction reaches back across every period it affected and involves conversations with everybody it touched. Checking each element individually at setup is small work against that.
These errors are also the hardest to explain to the person affected, because nothing visibly changed at any point and the figure they have been receiving was wrong from the start. The conversation is harder than the correction.
The third cost is the mid-period cutover that nobody planned. A slipped date creates pressure to split a period across two arrangements, which means a reconciliation nobody has done before, performed in a hurry, on the payroll that people are about to receive. Extending to the next boundary is almost always cheaper than the alternative, and the decision is easier if the criteria were written down early.
The fourth cost lands on the team rather than on anybody's pay. A difficult go-live, followed by weeks of corrections and worried questions, is demoralising in a way that outlasts the project, and it makes the next change harder to propose because everybody remembers the last one. Getting the first run right buys credibility for everything that follows it.
So do three things before the date gets close. Draw the population list from two independent sources. Establish what has to carry across with local advice rather than inference. And agree, in writing, what would cause you to move the date, while that's still a calm conversation.
When You Are Ready to Go Further
Start with the data, because that's where the risk actually is. The population list from two sources, the terms checked against the record, every standing element examined individually rather than sampled, and the historic position established with local advice. This is unglamorous work and it's what determines whether the first run is dull.
Give each item a named person who confirms it rather than a team. A team owns nothing in practice, and the items that reach the first run uncorrected are almost always the ones everybody assumed somebody else had looked at.
Then run a parallel period and treat the comparison as the main task rather than the final check. Compare at the level of individual people and individual elements, include the awkward cases deliberately, and explain every difference rather than tolerating the small ones. Stop when they're explained, not when a count is reached.
Leave room after the comparison to fix what it finds and check again. A parallel scheduled so late that its findings arrive without time to act on them has confirmed something you can no longer do anything about, which is the most expensive way to discover a problem.
Finally, write the two things nobody wants to write: what would make you move the date, and what you'd do if the first run were wrong. Both are quick, both are much harder to produce under pressure, and each one prevents the specific failure that happens when a payroll go-live goes badly.
Agree who makes the go or no-go call as well, and make sure it is somebody senior enough that saying no is realistic. A decision that technically belongs to the project team will always go ahead, because nobody at that level is positioned to absorb the consequence of a delay.
HROpsLab publishes independent comparison work across HR tooling, payroll and workforce systems. We sell nothing, we take no vendor money, and we publish no paid placements. If the next step is understanding what a given system asks of you at setup, our comparison work is one place to start.
Frequently Asked Questions
What does setting up payroll actually involve?
Less configuration and more data work than people expect. The system needs to know who is paid, on what terms, with what standing elements, what varies this period, what historic position carries across, and where the money goes. Each of those has to be established and confirmed by somebody named, and the historic position in particular depends on requirements that differ by jurisdiction and change, so it needs local advice rather than inference from how a previous arrangement behaved. The configuration is bounded; the data work expands the closer you look at it.
What is a parallel payroll run?
Producing the same pay period twice, once on the existing arrangement and once on the new one, then comparing the two results line by line. It is the only test that puts real data through real configuration, which is why it proves things that inspection cannot. The output is a list of differences rather than a pass or fail, and working through that list, attributing every difference to a cause, is the actual value of the exercise and the part most often underestimated when planning the time for it.
How many parallel runs should you do?
Enough that every difference is explained, which is a more useful standard than any number. One period with all differences understood proves more than several with unresolved items, because the purpose is understanding rather than repetition. More periods help where your payroll varies meaningfully between cycles, with elements that only appear sometimes or populations that behave differently, since a single period will not exercise those. Stop when the differences are explained, not when a planned count is reached.
What data needs to migrate into a new payroll system?
Every person who should be paid and nobody who should not, their rate and terms, standing elements and deductions, the variable input for the period, bank details, and whatever historic position has to carry across. That last item is the one to establish with local advice, because what must carry across and in what form differs by jurisdiction and affects treatment for the rest of the period. Draw the population list from two independent sources rather than one, since a missing group is the failure that leaves somebody unpaid entirely.
What should you check before the first pay run?
The population list against a second source, every standing element individually rather than by sample, bank details verified against something other than the migration file, and the parallel comparison with every difference explained. Also check the mechanical things that fail on the day: the payment file format and route, and who has authority to release it, with a named substitute. Standing elements deserve particular attention because an error configured at setup looks normal in every subsequent period and can persist for a long time.
Should you go live with payroll mid-period?
Avoid it if there is any alternative. A mid-period switch splits the period across two arrangements, which means somebody has to combine the halves correctly and handle anything proportional by hand, and that reconciliation is one-off work being done under time pressure by people who have not done it before. When a date slips, extending to the next period boundary costs a delay, while splitting a period costs an unfamiliar manual exercise on the payroll people are about to receive.
What happens if the first payroll run is wrong?
Practically, everybody finds out the same day, because payroll is the one system where every employee checks the output immediately. What determines the damage is the response rather than the error: how quickly somebody affected can be paid properly, who tells them, and whether they hear it from you before they notice. Having that plan written before go-live matters more than it sounds, because producing it during an incident is slow, and the delay is what people remember rather than the mistake.
Who should sign off the first payroll run?
Somebody accountable who has actually looked at it, with a named substitute in case they are unavailable on the day. The sign-off is meaningful only if they were given something specific to examine, which means the parallel comparison, a list of what the checks flagged, and enough familiarity with the population to notice an implausible figure. An approval given without that is a record rather than a control, and the first run is the cycle where the difference matters most.
A dull first run is the only good one.
