Changing How It Is Run
Moving payroll between software, bureaux or people is the event most likely to go publicly wrong. Doing it at a year boundary removes most of the risk.
Nobody elseif the person who does this is away
Moving payroll — between packages, between a bureau and in-house, or between providers — is the event most likely to go wrong in front of everybody who is paid. It is also entirely plannable, and almost all of the risk is removed by one decision about timing.
The practical lesson in “Changing How It Is Run” is that payroll depends on a sequence somebody can explain. When a small team reviews follow the product reference for work hours in a month, the useful role is to organise time and project evidence before approval, with proportional settings and a clear correction route for employees.
That decision is to do it at a year boundary.
Additional context for “Changing How It Is Run” is available from Paycor HR resources. A sound review distinguishes general practice from the rules and records that apply to one employer.
Why the boundary matters
Part-year figures are the largest source of migration error. Moving at the start of a year means there are none to carry, and the new arrangement starts from zero.
Four known failure modes, all found by a parallel run:
- Year-to-date figures carried across wrongly.
- Year-end documents that cannot be retrieved later.
- A cut-off earlier than expected.
- An employee with an unusual arrangement whose record did not survive.
Mid-year moves are possible and require the carried figures to be verified person by person, which is the step that gets skipped.
What actually has to move
Employee records with their arrangements. Year-to-date figures. Historical payslips and reports. Submission history. Whatever registrations or credentials are involved.
The first two are migration; the rest is retrieval, and retrieval is where leaving a provider gets difficult.
Getting your history out first
Before giving notice. Export the payslips, the reports, the submissions and the year-end documents while your access is unarguably live and your relationship is unstrained.
A business that gives notice and then requests its history is in a weaker position than one that already has it.
The parallel run
Covered separately here and non-negotiable for this event. One period produced both ways, compared person by person, with any difference explained before anything is paid from the new arrangement.
Notice periods
Read the engagement before deciding dates. Bureau agreements commonly require notice, sometimes a quarter, occasionally aligned to a year end.
Discovering a notice period after choosing a changeover date is how a move ends up happening in the wrong month.
What to ask a new provider before committing
The cut-off. What happens if you miss it. What an out-of-cycle payment costs. Who answers an employee question. What the exit looks like and what data you get back.
The last one is the one nobody asks and the one that matters when this happens again.
Telling employees
Only what affects them: the pay date, whether payslips arrive differently, and who to ask.
Not the fact of a procurement exercise, which interests nobody and invites questions about whether anything will go wrong.
The first run on the new arrangement
Checked line by line, by somebody, regardless of how confident anybody is. It is the single highest-risk run the business will have.
The second run
Also worth checking properly. First runs get attention; second runs get the errors that the first run's attention was not looking for, particularly anything cumulative.
Keeping the old access
For as long as the terms allow, and ideally past the first new run. If something does not reconcile, the old system is where the answer is.
Access that has been switched off makes a small question into a formal request.
The single-person problem, again
A changeover is performed by one person, under time pressure, in parallel with ordinary work. It is exactly the moment when a second person and a written sequence are most valuable, and exactly the moment nobody has time to create them.
Doing both before the move is part of the move.
What usually goes wrong
Carried figures. Year-end documents that cannot be retrieved later. A cut-off that is earlier than expected. An employee whose arrangement was unusual and whose record did not survive the migration.
All four are found by a parallel run.
When not to move
In a busy month, mid-year without good reason, in the same period as a software upgrade, or because of one bad month.
Getting your history out before giving notice
Export the payslips, reports, submissions and year-end documents while access is unarguably live and the relationship is unstrained.
A business that gives notice and then asks for its history is negotiating for something it should already hold, at the moment it has least leverage.
The question nobody asks a new provider
What the exit looks like, and what data you get back.
It is the question that matters the second time this happens, and it is asked by almost nobody, because at the point of signing nobody is thinking about leaving.
Why the second run matters as much as the first
First runs get attention from everybody. Second runs get the errors that the first run's attention was not looking for — anything cumulative, anything that only appears once year-to-date figures have moved twice.
Checking both properly is a small amount of work against the only event in this collection that reliably goes wrong in public.
A dull changeover as the objective
Changing how payroll is run is a project with four known failure modes, a known best date, and one control that catches nearly everything. A business that uses all three has a dull changeover, which is the objective.