The implementation plan says twelve weeks. The plan is describing configuration. The switch is governed by the tax year, the parallel runs and the data you cannot leave behind — and it is the one HR system that cannot go live half-finished.
Payroll decisions cluster in the final quarter of the year, for an obvious reason and a bad one. The obvious reason is that budget exists. The bad one is that a January or April go-live looks achievable from September, and the implementation timeline the vendor put in the proposal appears to agree.
It usually does agree, because it is answering a narrower question than the one being asked. Twelve to sixteen weeks is a reasonable estimate of how long it takes to configure a payroll system. It is not an estimate of how long it takes an organisation to stop running payroll one way and start running it another, which is a different project with different gates and a much less forgiving failure mode.
Why payroll is not like the rest of the stack
Every other HR system tolerates a partial migration. An HRIS can go live with two modules and add the third in June. A learning platform can run alongside its predecessor indefinitely. Recruitment can move one region at a time and nobody outside the function notices.
Payroll has three properties that remove those options. It has a binary failure mode — people are paid correctly and on time, or the organisation has an incident that reaches the chief executive by lunchtime. It carries statutory obligations to third parties on fixed dates, which do not pause for a migration. And it holds year-to-date balances that determine the correctness of every subsequent calculation, which means the system cannot be adopted fresh without either a clean year boundary or a full, reconciled balance migration.
You can go live with a half-configured HRIS. There is no such thing as a half-configured payroll, because the first thing it produces is a payment to a person.
The realistic shape of it
Figure 1
Phase | Typical elapsed time | What actually gates it |
|---|---|---|
Selection and contracting | 6–12 weeks | Security review and data processing terms, not the demo |
Discovery and data extraction | 4–8 weeks | Getting a complete, structured extract out of the incumbent — including balances and historic elements |
Build and configuration | 8–16 weeks | Pay elements, and the local variants nobody documented |
Integrations and statutory outputs | Overlaps build; 6–10 weeks | Pension files, general ledger mapping, bank payment approval, third-party deductions |
Parallel running | 2–3 cycles minimum | A defined pass standard, and someone empowered to say it has not been met |
Cutover and first live run | 1 cycle, plus the following one | The second live run, which is where deferred problems surface |
Stabilisation | 2–3 cycles | Year-end processing, if it falls inside this window |
Six to twelve months from decision to a settled payroll, for a single-country organisation of moderate complexity. These are typical observed ranges based on published implementation guidance and practitioner accounts, not survey data. Multi-country programmes run longer and are usually sequenced country by country.
The tax year is the real project manager
The cleanest possible switch starts a new payroll at the start of a tax year with zero year-to-date balances to carry. Everything else is a compromise, and the compromise has a name: balance migration, in which the new system is loaded with cumulative figures it did not calculate and must now be trusted to continue correctly.
That is entirely doable. It is also where most of the post-go-live reconciliation effort is spent, because an error in a migrated balance does not present as an error. It presents as a slightly wrong tax deduction eleven weeks later, discovered by an employee.
The practical consequence is that the viable go-live windows in any year can be counted on one hand, and working backwards from one of them is the only planning method that survives contact. A programme that slips past its window does not slip by four weeks. It slips to the next window, or it accepts balance migration and a longer tail.
What consumes time that is not on the plan
Four things, reliably.
Pay elements nobody can explain. Every established payroll contains elements created for a reason that is no longer in anyone's memory — a legacy allowance for a site closed in 2014, a rounding behaviour inherited from a system before the last one. They cannot be dropped without confirming who receives them, and they cannot be replicated without understanding what they do. This is the single most underestimated task in payroll migration.
Third-party outputs. Pension contribution files, attachment and court-ordered deductions, benefits providers, share schemes, the general ledger. Each has its own format, its own recipient and its own tolerance for error, and each must be tested with the recipient rather than against a specification.
Banking approval. Changing the origin of a payment file is a treasury and fraud-control change, not a payroll one. The approval chain sits outside HR and does not know it is on your critical path.
Historic data. Records must remain accessible for statutory retention periods and for the ordinary business of answering questions about past pay. Decide early whether history is migrated, held in an archive, or retained by keeping the incumbent system in read-only mode — the last option is common, sensible, and carries a licence cost that rarely appears in the business case.
What must exist before parallel run one
A written pass standard.Net pay variance of zero, with every gross-level variance explained and signed off. Agree it before the first run, because agreeing it afterwards becomes a negotiation.
A named person who can fail the run.If the only people reviewing the parallel output are also accountable for the go-live date, the run will pass.
A complete element inventory with an owner per element.Not a list of what exists — a list of what each one is for and who still receives it.
Third-party files tested end to end with the recipient.A file that validates locally is not a file that has been accepted.
A documented fallback.Under what conditions do you run the old system for one more cycle, who decides, and by when? A fallback decided in advance is a controlled option; decided in the week of go-live it is an incident.
The honest answer to the question
For a single-country organisation of moderate complexity, six to twelve months from decision to a settled payroll, with the go-live pinned to a tax-year boundary and two to three parallel cycles before it. Faster is possible where the population is simple, the incumbent data is clean and the organisation has done it before. Faster is also where most of the published cautionary tales come from.
The reason this matters in September is arithmetical rather than cultural. A decision taken in October, contracted in November and started in earnest in January is not a switch that goes live cleanly at the start of the next tax year. It is a switch that either accepts balance migration, or waits — and the organisations that handle it best are the ones that work that out before signing, rather than four parallel runs later.
Sources and notes. This is an explainer, not a report. The phase ranges in Figure 1 are typical observed durations compiled from vendor implementation guidance and practitioner accounts, and are not survey data; they describe a single-country implementation of moderate complexity and should not be read as a benchmark. Statutory retention periods, reporting obligations and tax-year boundaries differ by jurisdiction — the structural argument holds across them, the dates do not. Journalism, not procurement, payroll or legal advice. Corrections welcome.
