Switching Payroll Software

The first sign that switching payroll software has gone wrong is usually an email from an employee.

Their tax code looks odd on this month’s payslip, or a February starter is suddenly on week-one emergency tax in July.

By the time you investigate, the old provider has filed an FPS you thought was stopped. The new one has filed its own.

HMRC shows two sets of YTD figures for one PAYE reference, your payroll team is staying late, and finance wants to know why the PAYE bill doubled.

A clean switch is not hard, but it is unforgiving of shortcuts.

We walk through cutover timing, exports, the RTI duplication trap, and what a realistic 6-week migration looks like for a UK business at 20-500 headcount.

When should you actually switch UK payroll software?

The honest answer: almost always at 6 April. Switching on day one of a new tax year is the only approach that gives you a clean zero-state.

You do not import year-to-date figures, you do not reconcile half a year of statutory recoveries, and HMRC sees a single unbroken FPS sequence against your PAYE reference.

Everything else is a compromise. Two exceptions are defensible. First, if your current provider is failing operationally, for example support response times past 72 hours at month-end.

Second, if you are on a legacy desktop system no longer receiving HMRC compliance updates.

For everyone else, scope in October for a 6 April cutover. That is six months to audit, shortlist, parallel-run, and train. If the vendor sales cycle is compressing you into a December go-live, push back.

The introductory discount will still be there in the spring.

Rule: if the cutover cannot land on 6 April, document why in writing before you sign. That document protects you in month four.

What goes wrong when you cut over mid-year?

The risk surface expands.

• You are importing every employee’s YTD taxable pay
• NI contribution history by category (A, B, C, H, M, V)
• any week-one/month-one flag
• student loan deductions
• and statutory recoveries already claimed on EPS submissions

For 250 employees, that is 2 to 4 minutes of verification each before the first live run. Call it 8 to 16 hours of reconciliation compressed into one week.

Second risk: your PAYE scheme reference can only hold one employer record at a time. If the old provider files an FPS after cutover, because of an auto-scheduled submission or corrected pay run, HMRC gets two sets of YTD figures.

GOV.UK’s payroll errors guidance confirms this generates an incorrect PAYE bill and duplicate records.

Third risk: P60 timing. Only one provider issues a P60 per employee per tax year, covering the full year.

Cut over in July and a P60 showing only 9 months is a regulatory error requiring reissue, chased by every affected employee.

Scenario rule: if you switch mid-year, lock the cutover date with the old provider in writing, matched to your FPS schedule, and disable auto-scheduled submissions 48 hours before.

How do you export your payroll data from Xero, Sage, BrightPay, or IRIS?

Each provider handles export differently, and the gap between marketing language and reality is where migrations go wrong. The file formats below are current as of April 2026.

Xero Payroll exports CSV under Payroll Settings > Data Export. Covers records, tax codes, YTD, pay history. Historical payslip PDFs do not come through.

See our Xero Payroll review.

Sage 50 Payroll produces.SDB proprietary backup files that only restore into another Sage 50 instance.

Moving off Sage means rebuilding the employee master file by hand, or paying Sage £400 to £900 for a one-off CSV export depending on headcount.

BrightPay exports YTD as CSV through Backup & Restore. Pension opt-in history does not come through.

If NEST or The People’s Pension is your scheme, re-establish the opt-in flag before the first contribution file submits, or risk re-enrolling employees who had previously opted out.

IRIS Payroll exports structured CSV including YTD, tax codes, and statutory history.

IRIS is the most migration-friendly legacy vendor on the export side; the trade-off is a legacy UI that new hires take longer to learn.

Moorepay and other managed bureaux require a data request, not self-serve export. Budget two weeks and specify NI category history in writing, because bureau defaults exclude fields a self-managed system will need.

Payoff: before you sign with the new vendor, every legacy export file should be open in a spreadsheet. If you cannot read it, you cannot import it.

What does the RTI continuity problem look like in practice?

Your FPS schedule is the spine. RTI requires an FPS on or before every payday, and HMRC matches by PAYE scheme reference, not by which software sent it. See our RTI guide for the mechanics.

Three cutover patterns exist. First, and what we recommend: a strict handover at the tax month boundary.

The old provider files its final FPS for the period ending before 6 April. The new provider takes over from the first pay date on or after 6 April. No overlap.

Second: mid-month switching. Either both providers file for the same pay date (the duplicate-record scenario), or you delay that pay date to create a clean boundary (a cashflow problem for employees).

Third: the parallel run. Both systems calculate the same period; only one files. This is what you do during testing in week 3.

Reconcile line by line before scheduling the live cutover.

The EPS is a second deadline, due by the 19th of the following tax month. If you switched mid-month and both providers believe they are responsible, you get duplicate EPS submissions or none at all.

Pin down in the contract which provider files the final EPS.

Rule: one provider, one FPS, one EPS per pay period. Anything else is a future reconciliation problem.

How do you avoid mistimed P60s and auto-enrolment breaks?

P60 responsibility is simple in principle: whichever provider runs the final pay period of the tax year issues it. In practice the question is when. Deadline is 31 May.

A well-run provider sends P60s in the first week of May; some bureau providers push to the deadline, which matters if employees are filing self-assessment.

If you switched mid-year, the P60 must show the cumulative annual total, so your new provider needs the YTD figures imported correctly.

A P60 covering only 9 months is a regulatory error requiring reissue with supplementary paperwork per employee.

Auto-enrolment is the second handover risk.

Three dominant UK scheme providers, three file formats:

• NEST takes a fixed-width CSV through its employer portal
• The People’s Pension takes CSV through Simply Comply
• Aviva Workplace Pension uses its own template

If your new software lacks a native integration with your scheme, a 10-minute monthly task becomes a 60-minute one. You also transfer the re-enrolment triennial date, because The Pensions Regulator ties that to your original staging date, not your software.

Our payroll software buying guide covers pension integration per provider.

Payoff: if cutover cannot guarantee a clean P60 and an unbroken pension file, you have not solved the switching problem, you have postponed it.

What does a 6-week UK payroll migration actually look like?

Six weeks is the realistic minimum for 50-500 headcount moving between two well-supported providers. Under 50, you might compress to four. Over 500, or with international components, plan for 10 to 12.

Week 1: data audit. Pull every employee record out of the current system. Verify tax codes against HMRC’s latest notifications.

List every open statutory claim. Flag every non-standard NI category. You end the week with one spreadsheet that represents the current truth of your payroll, independent of either software.

Week 2: export and reconcile. Run the export from the current provider. Import into the new one in test mode.

Reconcile line by line. Every difference is either a data issue or an import mapping problem, and you want to find both before cutover.

Week 3: parallel test run. Process a full pay cycle through both systems. Do not file either FPS.

Compare gross-to-net output employee by employee. Any variance over £1 needs a written explanation before you proceed.

Week 4: employee comms and pension handover. Notify employees that payslip access is moving, with the URL and login flow. Submit the pension scheme change notification.

Re-verify the re-enrolment date with The Pensions Regulator.

Week 5: live cutover. Disable any auto-scheduled submissions in the old system. Process the first live pay run in the new system.

File the FPS. Log into your HMRC online account within 48 hours and verify only one submission appears against your PAYE reference.

Week 6: verification and close-out. Reconcile against the first month’s PAYE bill. Confirm the pension contribution file landed with the scheme provider.

Archive the old system’s data in a format you can read without the old software. Cancel the old contract only after these checks pass.

Rule: do not cancel the old contract until week 6 is closed. You may need to pull a historical payslip, and access is cheaper than reconstruction.

Which UK payroll providers actually make switching easier?

Cloud-native providers score higher on migration experience.

• Xero, Employment Hero, Pento, and Payfit all have onboarding teams that have run the pattern hundreds of times, structured import templates, and API access for future data extraction

Our reviews:

• Xero
• Employment Hero
• Pento
• Payfit

BrightPay sits in the middle.

It exports cleanly, but as a desktop-rooted product with BrightPay Connect adding cloud access, its migration pattern assumes you are going to another accountant or employer, not a cloud-native cohort.

Sage 50 Payroll, IRIS Payroll Professional, and Moorepay present more friction. Sage and IRIS because their export formats are legacy-oriented, Moorepay because data lives in bureau systems by default.

Employment Hero, Pento, and Payfit are the three we have watched consistently absorb mid-year switches without drama. Their import tooling is newer and their customer success teams are staffed for migration work, not treating it as a one-off.

Xero handles cutover well; the friction appears at month-end support response time.

Payoff: a provider’s migration experience is a line item, not a marketing claim. Ask for two customer references who switched in the last 12 months and call both before you sign.

What do UK payroll migrations actually cost?

The subscription fee is usually the least important number. A 100-employee business moving from Sage 50 to Xero Payroll pays around £5 per employee per month (£500 per month) against Sage’s annual licence plus support.

Over three years the software cost is comparable.

The real cost is the switching work. At 100 employees with an internal payroll manager, a 6-week switch consumes 80 to 120 hours of their time, plus 20 to 40 hours of finance and HR review.

At £50 to £80 fully loaded, that is £5,000 to £12,800 in internal labour.

Add any bureau export fee (£400 to £900) and professional services from the new provider (often £1,500 to £5,000 for a managed migration).

A realistic switching budget is £7,000 to £18,000 before the first live pay run.

The introductory discount matters less than you think. A 50 to 80 per cent discount over the first six months saves roughly £1,500.

What moves the break-even is whether the new system saves 10 hours a month of payroll time, which is £6,000 to £9,600 a year in recovered capacity.

Rule: if you cannot name the specific monthly hours saved and the specific month the saving appears, the switching business case is not yet built.

Switching payroll software: your questions answered

Switching payroll software rewards patience. The migration that takes six weeks and ships clean is cheaper and more defensible than the one that goes live in three and consumes the next six months in reconciliation.

If you are scoping a move now, pick your cutover date first, work backwards from there, and do not let a vendor sales cycle compress the plan.

For shortlisting the providers that fit your size and complexity, start with the UK payroll software buying guide.