HRIS implementation, step by step

Most HRIS implementations at small companies do not fail. They stall, and then they half-land: the directory is in the new system, leave balances are still argued about in a spreadsheet, and six months later two sources of truth are both wrong in different ways. That outcome has almost nothing to do with the software and almost everything to do with the order the work was done in.

This is a working plan for a company of roughly ten to two hundred people moving to an HRIS, whether from spreadsheets or from another product. It assumes you have already chosen. If you have not, how to choose HR software and twelve questions to ask a vendor come first, and if you are leaving an incumbent, how to switch HR software without losing data covers the export side that this guide assumes is done.

Phase 0: decide four things before you touch the software

These are policy decisions, not configuration, and every one of them will otherwise stop you mid-import.

Who owns this. One named person with the authority to settle policy questions. Not a committee, and not “HR and the founder jointly”, which in practice means nobody decides the carry-over rule for three weeks.

What the go-live date is, and why that date. Pick a period boundary. The start of a month, a quarter, or a leave year. A mid-period cutover means splitting balances and payroll inputs across two systems for one cycle, which is the single most reliable way to produce numbers nobody trusts.

What the leave year and the balance position actually are. Almost every small company discovers during implementation that its leave policy is partly written down, partly custom, and partly whatever the last argument concluded. Settle it now and write it down. The leave policy guide covers the decisions, and the leave policy generator will produce a draft you can edit.

What you will not do in phase one. Performance reviews, recruiting, expenses and analytics are all things you can add later. Trying to land them all at once is how a two-week project becomes a two-quarter one. Get the record right first, because everything else depends on it.

Phase 1: clean the data, before you import anything

Budget more time here than feels reasonable. This is the phase that determines whether the new system is trusted.

Export what you have. Every employee row, every contractor, every leave record, every document, every compensation change you can find. Put it in one place and read it.

Then work through, in this order:

Deduplicate people. Nicknames, married names, two rows for the same person because they changed employment type. Decide the canonical identity for each human.

Fix the dates. Start dates, confirmation dates, and the effective dates of every change. Dates are the spine of an HR record. A promotion with no effective date is a fact you can never place in time again, and it is the reason you cannot answer what someone earned in March 2025 when an auditor asks in 2027.

Reconcile leave balances person by person. Not in aggregate. Send each person their balance as you have it and ask them to confirm. You will find disagreements, and it is far cheaper to find them now than after the system has been declared the source of truth.

Triage documents. Split into live and archive. Live documents are current contracts, identity and right to work documents, visas, and certifications with expiry dates. Those come into the new system with their expiry dates attached. Everything else can stay in an archived export.

Decide what does not travel. Old drafts, superseded policies, spreadsheets whose owner has left. Archive the file; do not import the mess.

Phase 2: configure in a fixed order

Configuration has dependencies, and doing it out of order means redoing it.

1. Legal entities and locations. Everything else hangs off these. If you employ people through more than one entity, model that now rather than retrofitting it. Running HR across multiple legal entities covers what changes.
2. The people import. Employees and contractors together, in one directory, so you do not create the parallel spreadsheet you are trying to escape.
3. Org structure and reporting lines. Generated from the records rather than drawn separately, so it cannot drift.
4. Leave policies and holiday calendars. Policy per entity, region or grade as needed, and a holiday calendar per work location rather than one national list applied to everyone.
5. Opening leave balances. Loaded after the policies exist, so accruals compute from a known starting point.
6. Approval workflows. Who approves leave, expenses, data changes. Include delegation for when the approver is away, because that is the failure everyone discovers in the first week of holidays.
7. Documents and letter templates. Offer, appointment, address, experience. Built from record fields rather than retyped. Getting these in early pays back immediately, because letters are the most requested thing HR produces.
8. Onboarding and exit checklists. Templates per role or entity, with owners and due dates tied to the start or exit date.
9. Permissions. Who can see compensation. Who can see documents. Who can see other entities. Do this deliberately rather than by leaving everyone an admin.

Phase 3: run it in parallel

Do not switch off the old process on go-live day. Run one full cycle both ways.

For leave, that means a month where requests go through the new system and the old spreadsheet is still updated, then a comparison. Differences are configuration bugs and you want them now.

For attendance and payroll inputs, run one period in parallel with whatever you send your payroll partner today and reconcile line by line. If you are using a Payroll module that compiles inputs into an export, this is where you agree the format with your partner and confirm the day counts, prorations and one-off payments all arrive as expected. Expect to find one thing that does not match. That is what the parallel run is for.

For self-service, pick five employees across different teams and have them find their own balance, their own documents and their own profile. If they cannot, the rollout email will not save you.

Phase 4: go live

Go-live is mostly communication.

Tell everyone a week ahead what changes, what they need to do, and what happens to the old thing. Name a person to ask. Publish the two or three tasks each employee actually has, which is usually: log in, check your profile, check your leave balance, tell us if either is wrong.

On the day, load any final data, confirm access levels, and turn off write access to the old system rather than deleting it. Keep the old export as a file. Start your shortlist with the export makes the wider argument that your ability to leave is a property you should test rather than assume, and the same logic applies to the system you are leaving today.

Then hold a support window. For the first two weeks, someone answers questions fast. Most of them will be one of five questions, and after a fortnight you can write them down and stop answering them individually.

Phase 5: the first 90 days

At 30 days, check that the things you configured are actually being used. Are leave requests going through the workflow or arriving in chat. Are onboarding checklists being completed or ignored. Usage tells you where the configuration is wrong.

At 60 days, test the exit. Run your first offboarding through the system end to end, including access removal, asset return and document issue. The offboarding checklist is the sequence. Exits are where record quality is proven, and where a rushed implementation shows.

At 90 days, test your own export. Pull a full export from the new system and open it. You are checking two things: that you can leave whenever you want, and that the data you migrated is all actually there. If the export is a curated selection rather than everything you put in, that is a finding worth having early. On this site, the real cost of switching HR systems sets out what a migration actually costs, and the reason to check your exit on day 90 is that you do not want to discover it on day 900.

Then add the second thing. Attendance rules, expenses, performance, recruiting, analytics, whichever the business actually needs, one at a time, each with its own small version of this plan. The module catalogue publishes what each one does and, more usefully, what it does not, and every price is on the pricing page.

The one shortcut worth taking

If you are under about twenty people and the record is currently a spreadsheet, you do not need a phased programme. You need an afternoon, a clean import, and a decision about the leave policy. The phases above compress; the order does not change. Get entities, then people, then leave, then approvals, then letters, then checklists, and run the first month with the spreadsheet still open beside it.

What you should not skip at any size is the balance reconciliation and the parallel run. Everything else can be fixed later. Those two are what determine whether anyone believes the new system.