Most companies put off changing payroll software until January because they are afraid of the first month. The fear is reasonable. Migrating payroll mid-year in the UAE means the first run on the new system has to produce the right net pay for every employee and a Salary Information File the bank accepts, with the 1st-of-month deadline sitting behind it. But waiting for January does not remove that risk. It only moves it to the busiest payroll month of the year.
This guide sets out how to switch payroll systems between two ordinary months without a late or rejected WPS file: what actually breaks WPS during a migration, a cut-over timeline you can copy, the data to move, a parallel run with a worked example, and how HRX360 payroll handles each step.
Can you migrate payroll mid-year without breaking WPS?
Yes. UAE payroll is monthly and the WPS file is built per pay period, so there is no year-end dependency in the wage file itself. A migration succeeds when the first month on the new system matches what the old system would have paid, employee by employee, and the SIF is generated and uploaded with days to spare before the 1st of the month. Everything in this guide serves those two conditions.
There is no tax year to protect in UAE payroll. The things that do carry across months are cumulative: leave balances, continuous service for gratuity, and the salary history your payslips and auditors rely on. Those have to be migrated carefully whichever month you choose, and January is no easier for any of them. January is, however, the month with annual bonuses, salary reviews and the highest volume of changes, which is the worst time to be learning a new system.
The practical rule: switch after a clean, locked month with no open disputes, in a period with no bonus or review cycle, and only once you have completed a parallel run.
What actually breaks WPS during a payroll migration?
Four things: a payment-details field that was retyped wrongly (IBAN, routing code or MOL personal number), a salary component that was not mapped so net pay changes, a calculation rule that differs between systems so deductions change, and a cut-over that runs too close to the 1st of the month so there is no time to correct a rejected file. None of these is caused by the month you choose.
Payment details. The SIF carries each employee's IBAN, the bank routing code and the MOL personal number. A migration that retypes these from a printout introduces errors the old system never had. Export, import and compare instead.
Unmapped components. The old system had a transport allowance under one name and the new one under another. If the import leaves it blank, the employee is underpaid and the salary on the SIF no longer matches the contract.
Calculation rules. Absent-day deductions divided by 30 in one system and by days in the month in the other produce different nets for the same absence. Set the new system to match the old one for the first month; improve it later.
No slack before the deadline. Under Ministerial Resolution No. 340 of 2026, wages are due by the 1st of the month. A first SIF generated on the 30th leaves no room for a rejection. Generate it by the 26th to the 28th.
If the bank does reject the first file, the fixes are the same as in any other month. See why SIF files get rejected and how to fix them, and the current rules in UAE WPS rules 2026.
What does a safe payroll cut-over timeline look like?
Allow four weeks before the first live month and treat the deadline as the 26th, not the 1st. Week one decides the month and freezes changes, week two loads master data, week three imports history and matches calculation rules, week four is the parallel run. The live month then runs in the new system only, locks by the 25th and uploads the SIF by the 28th.
Example: first live month is October, paid by 1 November.
| When | Step | What to do |
|---|---|---|
| Week 1 (early Sep) | Decide the cut-over month and freeze changes | Pick October as the first month on the new system. Lock the September run in the old system when it is paid. Agree that salary changes effective October are entered in the new system only. |
| Week 2 | Load master data | Import employees, salary structures and payment details. Check the three WPS fields for every employee: IBAN, routing code and MOL personal number. Enter leave balances as at 30 September. |
| Week 3 | Import history and configure rules | Bring in the past months you need for payslips and year-to-date reports. Set the absent-day method, pro rata rule and salary components to match the old system, not to improve on it. |
| Week 4 (late Sep) | Parallel run on September | Re-run September in the new system and compare it to the locked September run from the old system, employee by employee. Fix the data until they match. |
| 1 to 20 Oct | Capture October inputs in the new system | Attendance, overtime, joiners, leavers and one-off amounts go into the new system only. The old system is read-only. |
| 21 to 25 Oct | Process, reconcile, lock | Run October, compare it to September, resolve queries, then lock the run. |
| 26 to 28 Oct | Generate and upload the SIF | Generate the SIF from the locked run, upload it to the bank or exchange house, and keep two or three working days in hand for a rejection and re-upload. |
| 1 Nov | WPS deadline | October wages are due by the 1st of November under Ministerial Resolution No. 340 of 2026. Salaries are paid from the new system for the first time. |
The old system is not switched off on cut-over day. Keep it read-only until the first two months on the new system are paid and reconciled, then export its final records and archive them.
What data do you need to migrate payroll?
Seven sets: employee master data, salary structures with effective dates, payment details for the SIF, leave balances at the cut-over date, service dates for gratuity, the past payroll months you want to keep, and the leavers from earlier in the year. Only the payment details and salary structure are needed to pay the first month. The rest is what keeps payslips, balances and audits continuous.
| Data set | Fields | Why it matters |
|---|---|---|
| Employee master | Code, name, department, designation, date of joining, nationality, sponsorship, status | Employee codes should match the old system so payslips and reports line up across the cut-over. |
| Salary structure | Every component per employee: basic, allowances, fixed deductions, effective date | Component names and totals must match the last old-system payslip exactly. A dropped allowance is the most common migration error. |
| Payment details | Payment method, bank name, IBAN or account number, routing code, MOL personal number | These feed the SIF. One wrong digit means a rejected record. Export from the old system and compare, do not retype. |
| Leave balances | Opening balance per employee per leave type as at the cut-over date | Needed so annual leave accrual and encashment carry on correctly. Keep a signed export from the old system as evidence. |
| Service and gratuity | Date of joining, contract type, last basic salary | Gratuity accrues on continuous service, so the joining date must be the original one, not the migration date. |
| Payroll history | Past months: gross, each component, deductions, net and payment method per employee | Not needed for WPS. Needed for payslip history, year-to-date reports, salary reconciliation against last month and audits. |
| Leavers in the year | Employees who left before the cut-over, with their final months | Auditors and year-end reports need them. Include them in the historical import so headcount by month is correct. |
Two of these deserve a note. Leave balances should be loaded as opening balances dated the cut-over, with the old system's export kept as evidence, because employees will query them. And the joining date must be the real one, because end-of-service gratuity accrues on continuous service and a migration date in that field would understate every leaver's settlement. For how the accrual works, see EOSB accrual for finance teams.
Payroll history is the set most companies skip. It is not required for WPS, which only needs the current month. But without it, the first salary reconciliation has nothing to compare against, year-to-date reports start from zero, employees lose access to earlier payslips, and the payroll audit at year end needs two systems open. Importing the earlier months once is less work than keeping the old system alive for a year.
Worked example: the parallel run that catches the errors
Run the last paid month again in the new system and compare it to the locked run from the old system. In the example below, a 64-employee company re-runs September and finds a net difference of AED 2,550 made up of three errors, plus a transposed IBAN that carries no amount but would have been rejected by the bank. All four are fixed before October is processed.
Parallel run, September (illustrative figures, AED):
| Employee | Item | Old system | New system | Effect on net | Finding |
|---|---|---|---|---|---|
| All 64 employees | Total net pay | 486,300 | 483,750 | −2,550 | Three differences to explain. Nothing is paid until this is zero. |
| S-0417 | Transport allowance | 2,000 | 0 | −2,000 | Component not mapped in the salary import. Add it and reprocess. |
| S-0432 | Absent-day deduction (3 days) | 1,350 | 1,800 | −450 | Old system priced absent days on basic salary (13,500 ÷ 30 = 450 a day); new system used gross salary (18,000 ÷ 30 = 600). Set the absence base to basic and reprocess. |
| S-0455 | Medical insurance deduction | 312.50 | 412.50 | −100 | Premium share typed as 412.50 instead of 312.50. Correct the insurance enrolment. |
| S-0501 | Payment method | Bank A, IBAN ending 4471 | Bank A, IBAN ending 4417 | No amount | Transposed digits in the IBAN. Would have been rejected by the bank. Fix before the SIF. |
The three amounts (−2,000, −450 and −100) sum exactly to the −2,550 difference in total net, so once they are fixed the new system reproduces the old system's September to the dirham. The IBAN error is the one to notice: it changed nothing in the totals, and only a field-by-field comparison of payment details would have found it before the bank did.
After the fixes, reprocess September in the new system and confirm the total is 486,300 with zero differences. Only then does October go in.
How do you run a parallel payroll properly?
Use the last month the old system actually paid, because its figures are final and locked. Compare at three levels: total net, each employee's net, and each employee's components and payment details. Explain or fix every difference, reprocess, and repeat until the two runs match exactly. Keep the comparison file: it is the evidence that the migration did not change anyone's pay.
Compare components, not just net. Two errors can cancel out at net level. A missing allowance and an overstated deduction can leave the net correct and the payslip wrong.
Compare the SIF fields separately. IBAN, routing code and MOL personal number carry no amount. A totals comparison will never find a transposed digit.
Match rules before improving them. If the old system rounded or prorated differently, set the new system the same way for the parallel run. Change the rule in a later month, with the change explained to employees.
Sign it off. The person who approves payroll signs the zero-difference comparison. That signature is what an auditor asks for when they see a system change in the year.
The first live month then gets the same treatment against the parallel month, which is the ordinary salary reconciliation every month should have. A migration simply makes the first one more important.
How HRX360 handles a mid-year payroll migration
HRX360 imports employees, salary structures and payment details from Excel templates, brings past months in with Historical Payroll Import so payslips, salary history and gratuity stay continuous, processes the first run as a draft you can reprocess as often as needed, compares it to the previous month in the Salary Review workbook, and generates the SIF file from the locked run with your registration and routing details pre-filled.
Step by step:
Load master data from templates. Employee Profile, Employee Salary Setup and Employee Payroll Setup each have an Import button with a downloadable template. Payment details are validated on the way in: an IBAN must start with two letters and two digits and be 15 to 34 characters, and each employee carries a MOL personal number for the SIF.
Import the months already paid. Historical Payroll Import on the Payroll Run screen gives you a template with one column per salary component and one row per employee, including leavers. You fill it from the old system, upload it, check a preview of the totals, and confirm. The month is saved locked and marked as imported, so payslips, salary history and dashboards show the full year.
Imported months are protected. An imported month cannot be reprocessed, because its figures came from the old system, and its journal voucher export is disabled, because the old system already posted it to your accounts. HRX360 also refuses to import over a month that already has a run.
Match the calculation rules. The absent-day method (days in month, 30-day or yearly average) and the pro rata option are company settings, so the first run can be set to reproduce the old system before you change anything.
Process, review, reprocess. A processed run is a draft. Fix the source data and click Reprocess as many times as the parallel run needs. Employees see nothing until you publish payslips.
Reconcile with Salary Review. The Salary Review workbook puts this month and last month side by side for every employee and component, flags payment-method changes, and lists joiners and leavers by date. With the earlier months imported, the first live month has a real previous month to compare against.
Lock, then generate the SIF. The WPS generator reads from the locked run. Your registration number and routing code pre-fill from company settings, you preview the data on screen, then generate the SIF file for upload to your bank or exchange house.
Payroll, WPS and gratuity are on the Professional plan of HRX360 HR software for the UAE, from AED 14 per employee per month. For what to look for when choosing the system you are moving to, see how to choose HR and payroll software in the UAE.
Switch payroll without losing a month of history
Import your employees, salaries and bank details from templates, bring the months you have already paid in with Historical Payroll Import, run a parallel month, and generate your first SIF from a locked run. Full UAE payroll with WPS, Salary Review and gratuity is on the Professional plan, from AED 14 per employee per month, billed annually.
Frequently asked questions
Can you migrate payroll mid-year in the UAE?
Yes. UAE payroll is monthly and the WPS file is produced per pay period, so a system change can happen between any two months. What matters is that the first month on the new system produces the same net pay and the same SIF data as the old system would have, and that it is ready before the 1st-of-month deadline.
What is the best month to switch payroll systems?
The month after a clean, locked payroll with no open disputes, and ideally one with no annual bonus, no salary review cycle and no public holiday overtime. In practice the best month is simply the one for which you can complete a parallel run before the real payroll is due.
What data do you need to migrate payroll?
Employee master data, salary structures with effective dates, payment details (payment method, bank, IBAN, routing code and MOL personal number), leave balances as at the cut-over date, cumulative service data for gratuity, and the past payroll months you want to keep for payslips, salary history and audits.
What is a parallel payroll run?
Running the same month in both the old and the new system and comparing them employee by employee before paying from the new one. Differences are explained or fixed until the two runs match. It is the single control that prevents a wrong salary or a rejected SIF file in the first month after a migration.
Does switching payroll software affect the WPS deadline?
No. Under Ministerial Resolution No. 340 of 2026, wages for the previous month are due by the 1st of each month regardless of which system you use. Plan the cut-over so the first SIF from the new system is generated several days before payday, leaving time to correct and re-upload if the bank rejects it.
Do you need to bring old payroll months into the new system?
Not for WPS, which only needs the current month. You do need them for payslip history, salary history reports, year-to-date figures and gratuity continuity, and auditors will ask for a full year of records. Importing the earlier months is usually easier than keeping the old system alive for a year.
How does HRX360 handle a mid-year payroll migration?
Employees, salaries and bank details are imported from Excel templates, past months are brought in with Historical Payroll Import so payslips and salary history stay continuous, the first run is checked with the Salary Review workbook, and the SIF file is generated from the locked run. Payroll and WPS are on the Professional plan, from AED 14 per employee per month.