HRMS guides
HRMS Implementation & Migration Checklist
Implementations rarely fail because the software was wrong. They fail because dirty data was carried across, nobody was trained, and go-live was scheduled in the same week as payroll. This is the sequence that avoids all three, and the checks to run before you commit to a date.
Who it is for
- HR managers running an HRMS rollout, usually alongside their normal job
- Founders implementing HR software for the first time
- Anyone migrating employee data out of spreadsheets
- Teams whose last implementation did not go well
What it helps with
- Sequence the work so nothing is discovered at the wrong moment
- Clean data before it is imported rather than afterwards
- Verify the system against the old records before trusting it
- Go live without putting a payroll run at risk
The thirteen steps
In order. The most common cause of a difficult implementation is doing step eight before step three.
Identify what you actually need
Write your requirements down before demos. The buying checklist is the long version of this step; the short version is knowing which five things must be true.Select the system
Score vendors on the same criteria, eliminate on must-haves, and take a reference call with a company of your size.Clean the data you already have
Before any import, and this is the step that gets skipped. Duplicate rows, leavers still listed, blank joining dates, three spellings of the same department. Fix it in the spreadsheet where it is quick.Prepare the employee records
Decide the fields you will actually maintain. Importing thirty columns you will never update makes a system that is wrong within a quarter.Configure the workflows
Leave types, accrual rules, approval routes, attendance rules, holiday calendars. Where two managers currently do it differently, this is where you decide which is right.Set permissions
Who sees salary, who sees documents, who sees other teams. Set it before the data lands, not after somebody sees something they should not have.Configure attendance and leave
Shifts, week-offs, holidays per location, and the opening leave balance for every employee. Balances are the thing employees check first, so they have to be right on day one.Import
In stages — employees first, then leave balances, then history if you are bringing any. Import a handful of records first and check them properly before doing all of it.Test against the old records
Run a past month in parallel. Compare attendance, leave balances and a payroll input file line by line with what your spreadsheet said. Differences are either a configuration error or a discovery about your old data; both matter.Train HR and the administrators
The people who will run it daily, on the real system with real data, doing the tasks they will actually do rather than watching a demonstration.Roll out to employees
Tell them what is changing, what they need to do, and who to ask. Keep it to one page. Most employees need three things: apply for leave, see their balance, find their payslip.Go live
On a fixed date, at a quiet point in the month — never in payroll week. Keep the old spreadsheets read-only for a full cycle.Review after the first cycle
One full month, including a payroll run, then sit down and list what did not work. Some of it will be configuration, some will be training, and some will be process you never had.
Pre-launch checklist
Every one of these should be true before you announce a go-live date. Tick them honestly — this is the list that decides whether the first month is calm.
Common migration mistakes
Importing dirty data
The most expensive mistake on this page. Duplicate records, people who left two years ago, missing joining dates, four spellings of one department. It takes an afternoon to fix in a spreadsheet and weeks to unpick inside a system, and until it is fixed nobody trusts a single report.
Going live in payroll week
A new system and a payroll deadline in the same week guarantees that any problem becomes an emergency. Go live at the start of a cycle, never at the end of one.
Nobody was trained, or only HR was
Managers approve things and employees apply for things. If they were not shown how, HR spends the first month being a help desk and everybody concludes the software is difficult.
Turning everything on at once
Attendance, leave, payroll inputs, recruitment and performance in one go means five things to learn and five things that can go wrong. Start with attendance and leave, which are daily and self-correcting, and add the rest once those are boring.
Deleting the spreadsheets too early
Keep them read-only for at least one full cycle. When a balance is disputed in month one, you will want the old record, and you will want it to be one nobody has edited since.
Configuring rules nobody has agreed
If your grace period is applied differently by two managers, the system will force you to pick one. That is a management decision, not a configuration option, and it should be made deliberately rather than by whoever fills in the form.
No named owner after go-live
Implementations have a project owner and then, on the day it goes live, nobody. Name the person who owns the system from day one onwards, before the project ends.
The first thirty days
Go-live is the start of the implementation, not the end of it.
| When | What to do | Done |
|---|---|---|
| Week 1 | Daily check that attendance is being captured for everybody, and chase gaps the same day | |
| Week 1 | Answer questions fast and in public — one visible answer prevents twenty private ones | |
| Week 1 | Keep a running list of everything that surprised somebody | |
| Week 2 | Check leave balances against the old spreadsheet for a sample of ten people | |
| Week 2 | Confirm approvals are actually being actioned, not accumulating | |
| Week 2 | Fix the top three items on the surprise list | |
| Week 3 | Produce a report you used to build by hand, and compare it with the old one | |
| Week 3 | Check employees are using self-service rather than still asking HR | |
| Week 4 | Run payroll inputs from the new system and reconcile them against the old method | |
| Week 4 | Sit down with managers: what is slower than before, and why? | |
| Week 4 | Decide what to switch on next — and what to leave alone for now | |
| Day 30 | Write down what you would do differently. You will implement something else eventually |
Expect the first cycle to be slower than the old way. That is not a sign the system is wrong; it is what learning looks like. If it is still slower after two full cycles, that is a signal worth acting on.
How to use it
- Put the thirteen steps into a plan with dates before you start. Steps 3 and 9 — cleaning and testing — take longer than anybody expects and are the two that get compressed.
- Do the data cleaning in your spreadsheet, where it is quick, and do not import until it is finished.
- Do not announce a go-live date until the pre-launch checklist is genuinely all ticked.
- Pick a go-live date at the start of a month, well away from payroll.
- Diarise the day-30 review at the same time as you diarise go-live, or it will not happen.
Questions people ask
Four to eight weeks of calendar time for attendance, leave and employee records, of which the actual work is perhaps two weeks spread out. The variable is almost always data cleaning, not configuration.
Bring current employee records and current leave balances. Historical attendance and old payroll are rarely worth the effort — keep the spreadsheets read-only as an archive and start the new system from a clean date.
For one cycle, deliberately, as a verification step — yes, and it is the single best check you can run. As an ongoing arrangement, no: two systems holding employee data diverge, and reconciling them costs more than either saves.
Where to go next
Flabido keeps the everyday HR work of a growing Indian company in one place — people records, leave, attendance, payroll inputs, hiring and letters. See what it does or ask for a free trial.