Implementation
Getting your data in is the whole project
Choosing an HR system is easy. Moving twenty years of staff records, expiry dates, leave balances and salary structures out of the workbook they currently live in is not — and it is where most HR rollouts stall. This page describes exactly how that goes, including the parts other vendors leave out of the sales deck.
We run it ourselves, remotely, wherever you are. Where we have a local partner in your market, some of the hands may be theirs — the plan and the accountability stay ours.
Four stages from contract to live
Each stage finishes when its conditions are met, not on a calendar.
See the data before promising anything about it
The first thing we ask for is your actual files — the staff workbook, the leave tracker, the salary sheet, whatever else has quietly become load-bearing. Not a specification of them. Almost every problem in an HR migration is already sitting in those sheets, and it is far cheaper to find it now than during the first payroll run. We read them, tell you what we found, and only then talk about sequence.
We do
- ✓Read every sheet, including the hidden ones and the ones everybody says are dead
- ✓Report back what is real data, what is a formula mirror of another sheet, and what is stale
- ✓Name the decisions only you can make — the ones where the sheet contradicts itself
You do
- ✓Send the files as they are. Do not tidy them first; the mess is diagnostic
- ✓Tell us which sheet the payroll officer actually trusts when two disagree
Done when
You have a written, sheet-by-sheet account of your own data, including the parts that are wrong.
Stand up the instance and load the organisation
The install itself is not the hard part — it is the same build whether it runs in our Singapore cloud or on your own servers. Then the first import phase goes in: companies, departments, designations, work sites and vessels, banks, contractors, reporting groups, leave types and public holidays. This is the scaffolding every later import resolves its references against, so it goes first and it goes in clean.
We do
- ✓Deploy the instance, configure companies, and turn on only the modules you bought
- ✓Load the reference data and normalise the inevitable spelling variants
- ✓Create the first admin accounts and set the role and permission map with you
You do
- ✓Confirm the org structure — this is the moment to fix a department list nobody has pruned in six years
- ✓Decide who administers the system, and who may see pay
Done when
Someone from your team can log in, and every department, site and designation they expect to see is there.
Employees and their documents
Phase two is the roster and the paperwork attached to it: profiles, staff numbers, joining dates, statuses, and every passport, visa, work permit, contract, insurance and medical record with its expiry date. The documents matter as much as the people. The day the expiry dashboard first lights up is usually the day the project justifies itself — in the migration we documented, it surfaced 439 already-expired documents among current staff that nobody had a list of.
We do
- ✓Import current staff, leavers and their full document set with expiry dates
- ✓Resolve the ugly cases rather than dropping them — reused staff numbers, duplicated roster blocks, people appearing on two sheets in two states
- ✓Reconcile the imported headcount against your own count and explain any difference
You do
- ✓Rule on the genuine ambiguities we surface — there are always a few, and they are yours to decide
- ✓Confirm the roster is the roster: leavers still sitting on an active sheet are the usual surprise
Done when
Headcount matches, and the expiry dashboard is showing you real, actionable gaps.
Salary structures, and a parallel run that has to match
Phase three is what repeats every month: basic pay and fixed allowances per currency, bank details, pension registrations, and standing deductions — loans, advances, court orders. Then the test that decides everything. We regenerate a month you have already paid and reconcile it line by line against your own sheet. Not a sample. Every payslip.
We do
- ✓Build salary structures, including split packages for staff paid partly in a second currency
- ✓Load pension registrations and every standing loan, advance and deduction
- ✓Run a completed month in parallel and reconcile it payslip by payslip against what you actually paid
- ✓Show you every disagreement and its cause, in writing
You do
- ✓Give us one closed month you consider correct, with its bank transfer list
- ✓Adjudicate the mismatches. In the migration we documented, every unexplained difference turned out to be an arithmetic error in the source sheet — but that is your call to make, not ours
Done when
A regenerated month reproduces your own figures to the cent, and every exception has a named cause and a decision against it.
Load the history, then go live
Phase four brings across what makes the system useful on day one rather than in a year: leave history, loan balances, salary advances, and applied increments. Then you stop maintaining the old sheets. That last part is a management decision, not a technical one — a system running alongside a spreadsheet nobody retired is the most common way an HR rollout quietly fails.
We do
- ✓Import leave history, loans, advances and increments with balances carried forward
- ✓Train the people who will actually use it, on your data rather than on a demo company
- ✓Stand close during the first live run — the first month is the one that matters
You do
- ✓Name the cut-over date and retire the old sheets on it
- ✓Send your team to the training. The system is only as good as the person entering the leave
Done when
The first live payroll run is finalized inside HumanR and the old workbook is read-only.
How data actually goes in
Not by anyone retyping it, and not by you reformatting your workbook into our template. We load your files ourselves, with tooling built for exactly this, and the whole method rests on one rule: nothing is saved until you have seen in full what saving it would do.
We work from the file you already have
Excel or CSV, as it comes out of your system. The sheet and the header row are detected rather than declared, so there is no preparation on your side. Across the four phases it covers 17 data sets, from departments and work sites through to loan balances and applied increments.
Your columns get mapped once
Headers are matched to our fields including the usual variants, so a column called “Staff No” needs no help. Anything genuinely ambiguous comes back to you as a question rather than a guess, and required fields are checked before a load runs — so a file that was always going to fail says so up front instead of half way through.
A dry run you get to read
The load runs in full without saving anything and reports exactly what it would do: how many rows are new, how many change an existing record, how many change nothing, and which rows failed with the reason. A row-level problem is a line in a list, not a crashed import.
Then the commit — and as many re-runs as it takes
Rows are matched on natural keys and loads are idempotent, so the same file twice changes nothing the second time. That is what makes a phased cut-over possible: we can keep reloading your live workbook while both systems run, and the last load before go-live is usually a no-op.
This is our tooling, not a screen you are asked to learn. You review what it found; we run the loads.
What we guarantee about a load
- Nothing is saved until the dry run has been read. The review and the commit are the same code with saving switched on, so the review cannot disagree with the result.
- A blank cell means “not filled in”, never “zero” — a blank salary cell will not wipe an existing package.
- A load never deletes. Anything not in the file you sent is left exactly as it was.
- Each load is a single transaction: it lands completely or not at all. There is no half-imported state to clean up.
- Every load is written to the audit trail as a named batch, so months later you can still see which rows a given file touched.
What we expect to find in your spreadsheet
None of this is a criticism — every long-lived HR workbook has these, because it was maintained by busy people under pressure for years. We list them because a vendor who has actually done this can name them in advance, and because knowing them changes how the migration is sequenced.
Your “view” sheets are stale and you cannot tell
Almost every workbook has tabs that are the main register filtered by hand — new joiners, temporary staff, headcount. They were correct the day they were made and wrong ever after. In one workbook we migrated, a 122-row temporary-staff tab was really 23 people: 120 of them had already left and nobody had removed them. In HumanR these stop being sheets and become live queries, which is why the count changes when you first see it.
Staff numbers get reused
Someone leaves, their number is handed to the next joiner, and now two different people share an identifier that half your other sheets use as a key. We keep the earlier holder as a distinct archive record rather than merging two people's careers into one row or silently dropping the older one.
The same person appears twice, in two states
Duplicated roster blocks, a person on both the active sheet and the terminated sheet, a leaver whose row was copied rather than moved. These are handled explicitly during the import and reported, not quietly de-duplicated by guesswork.
Excel has been silently editing your dates
Dates typed as dd/mm that Excel stored as mm/dd are extremely common — 2 December filed as 12 February. Where a column's pattern makes this unambiguous, the import corrects it on the way in and tells you it did.
Broken formulas hide real records
#REF! cells spread quietly through a long-lived workbook. One pension sheet we imported had 47 of them, and a religion column had 208 — meaning any calculation reading those cells had been wrong for a while. Rows that cannot be read are skipped and listed, never guessed at.
Two sheets will disagree about someone's pay
A pensionable wage on one sheet, a different deduction on another, a total that does not match its own components. We surface every one of these as a decision for you rather than picking a winner. In the migration we documented, this produced a short list of people who would have been underpaid by half if a category typo had gone through unchallenged.
One migration, in numbers
A group operating across islands and vessels moved off a 26-sheet staff workbook plus four satellite files and one printed form. Every sheet ended up either live in HumanR or established as derived or junk — nothing was left in the “we will deal with it later” pile.
- 3,038
- employee records migrated, current and historical
- 5,533
- employee documents with expiry dates now on one dashboard
- 1,990
- leave records reconstructed from a register, a tracker and legacy tabs
- 706
- payslips in a parallel run, reconciled line by line against the source sheet
- 780
- recruitment requests brought across from six pipeline tabs
- 1,492
- uniform and PPE issue records, replacing four separate tabs
What it exposed on day one is the part worth reading twice: hundreds of staff a year or more without annual leave, hundreds of documents already expired, and exactly two payslip totals that disagreed with their own components. None of that was new — it had simply never been visible in one place.
Want the longer version? Read the case studies.
What is already built when you arrive
A configuration project that starts from an empty screen is a second implementation nobody budgeted for. These exist before you do anything.
A 27-step onboarding checklist, already there
HumanR ships with a full onboarding template across five sections — pre-employment papers, HR and payroll setup, IT and access, workplace orientation, and confirmation — modelled on the printed checklist HR already uses. It is yours to edit and retire steps from, not a fixed workflow you have to adopt.
Reports instead of hand-filtered tabs
New joiners, temporary staff, headcount, leavers, document gaps and leave due are queries with filter bars and CSV export. They are correct the moment you open them, which the sheets they replace never were.
The expiry dashboard, populated
Passports, visas, work permits, contracts, probation ends and certifications land on one countdown board as soon as the documents are imported. This is normally the first thing that pays for the project.
Your data, exportable from day one
Every list exports to a file you own. There is no lock-in mechanism and no export fee — the migration works in both directions, which is the only honest way to ask someone to move.
How the service is run once you are live
Going live is one thing; staying up is another. These are the parts that decide whether it keeps running — open what you need.
HostingAWS Singapore or your own servers — one app, one database
- Where it runs
- Our cloud runs on AWS in the Asia Pacific (Singapore) region, close to the operations we serve. Or it runs on your own servers — the same build, no cut-down on-premise edition. On a self-hosted install your availability is genuinely yours: nothing about your instance depends on us being online.
- One app, one database
- A HumanR instance is a web application and a PostgreSQL database. That is the whole hard dependency. Everything else — the mail server, the search cache, the document store — is optional and degrades rather than fails, which is the single biggest reason an instance stays up.
- Instances are independent
- Every customer gets their own instance and their own database rather than a shared multi-tenant pool. One customer's heavy month-end payroll run cannot slow down another's, and a problem with one install is a problem with one install.
Releases & rollbackA file copy and a restart, with the previous build kept aside
- A release is a file copy and a restart
- Not a maintenance window. The new build replaces the old one and the application restarts, which takes seconds. The database updates its own schema on startup, so there is no separate migration step to go wrong — and a large schema change is the only thing that meaningfully extends a restart.
- Every release snapshots what it replaces
- The files being replaced are copied aside, timestamped, before the new build lands. That is what turns a bad release into a rollback rather than an incident: the previous version is already sitting there.
- Buying a module is not a deployment
- Every instance already contains every module, switched off. Turning one on for a customer who has bought it is a configuration flag and a restart — no new build, no data migration, no risk to anything already running. Features ship dark and get switched on deliberately.
- We deploy when it is quiet where you are
- Releases go out outside working hours for the operations they affect. If a release needs a longer window than a restart, you hear about it beforehand rather than discovering it.
What degrades instead of failingMail, webhooks, search, document storage and devices all fail soft
- A broken mail server does not stop work
- Notifications and expiry alerts are queued and sent by a background worker. If SMTP is down or slow, the queue waits and the application carries on — nobody is blocked from running payroll because an email could not go out.
- A dead webhook consumer does not stop work
- Deliveries are queued and retried on a backoff ladder, and an endpoint that keeps failing disables itself rather than dragging on the system. Your Slack channel being down is not your HR system being down.
- Search degrades instead of breaking
- Global search is faster with a Redis cache in front of it, and works without one through an in-application fallback. Losing the cache costs speed, not function.
- Document storage has a local fallback
- Employee document files live in S3 when a bucket is configured and on the server's own disk when it is not. Neither arrangement is a special edition of the product.
- Biometric devices keep their own record
- Punches push from your devices into your instance. The devices hold their own log, so a network interruption delays the rollup rather than losing the day's attendance.
BackupsNightly off-machine dump, pre-release snapshots, your own copy on request
- Nightly database dump, kept off the application server
- Losing the server does not mean losing the data. The copy lives somewhere the application server cannot take down with it.
- Pre-release file snapshots
- Taken automatically on every deploy, timestamped, so the previous version can be put back without waiting for a rebuild.
- Encrypted at rest
- The volume the database sits on is encrypted, and so are the connections into it.
- Your own copy, whenever you want one
- Every list in the product exports to a file you own, and we will provide a full database dump of your instance on request. The best protection against a vendor's bad day is not needing to ask them for your data.
Retention specifics for your own instance sit in your agreement rather than on this page. See status page.
What runs when nobody is logged in
All inside the application, so there is no cron job on some other machine to silently stop working. Administrators see the same list in-app and can trigger several by hand.
- Expiry scan — documents, contracts, probations, permits
- Nightly, plus on demand
- Email sender
- Continuous
- Attendance rollup from raw punches
- Every 15 minutes
- Webhook delivery and retries
- Continuous, when enabled
- Approval reminders
- Continuous
- Search index refresh
- Nightly, plus on demand
- Audit trail writer
- Continuous
When something does go wrong
We are a small team, which cuts both ways: there is no 24/7 network operations centre, and there is also no support tier to escalate through before you reach someone who can actually fix it.
- How would we find out?
- We contact your named administrators directly — email, and the messaging channel your team actually reads. We would rather tell you about a problem you had not noticed than have you discover it during payroll.
- How do we report a problem?
- Email support, or raise it from the in-app support screen if your instance has it enabled. Tell us what you were doing and roughly when; the audit trail usually lets us reconstruct the rest without a long back-and-forth.
- Do you publish an uptime figure or an SLA?
- Not as a public number. Our Terms do not warrant uptime, and quoting a percentage here that the contract does not back would be marketing rather than a commitment. If your procurement needs availability terms in writing, ask — that is a conversation about your agreement, not a badge on a web page.
- What if we host it ourselves?
- Then availability is in your hands and we are not a dependency. We will tell you what the instance needs and help you get it right, but your IT team's monitoring is the monitoring that counts.
Something wrong? Email support@humanr.online. For anything security-related, see security & trust. Live component status is on the status page.
Implementation questions
How long does it take?
We will not quote you a week count before seeing your files, because the software install is the fast part and your data condition decides the rest. A clean roster with one salary sheet is a different exercise from a 26-sheet workbook with reused staff numbers and three sheets that disagree about pay. Send us the files and we will tell you what we found and what sequence it implies — that answer will be worth more than a number we made up to win a meeting.
Do we have to clean the data first?
No, and please do not. The mess is diagnostic — it tells us how the workbook was really used, which columns are trusted and which are abandoned. Cleaning it first usually destroys exactly the evidence that stops a bad assumption reaching payroll. Send it as it is.
Can we run HumanR alongside our spreadsheets for a while?
Yes, and it is a normal way to cut over. Loads are idempotent, so we can reload the live workbook weekly during the transition without creating duplicates. What we will push back on is running both indefinitely — a rollout that never retires the old sheet is a rollout that has not happened.
What if the parallel payroll run does not match?
Then we do not go live until every difference has a named cause and a decision against it. In practice most differences turn out to be errors in the source sheet rather than in the system, but which one is right is your ruling to make. The point of the parallel run is to have that argument before real money moves, not after.
Who does the work — us or you?
We do the migration and the reconciliation; you make the decisions only you can make and you retire the old process. Each stage above lists both sides explicitly, because the usual reason an implementation stalls is that a decision was quietly waiting on someone who did not know it was theirs.
What happens to our historical payroll?
A month you have already paid can be brought in as a finalized run so the history exists and stays read-only — later salary changes never rewrite a paid month. From the cut-over onwards every run is generated inside HumanR.
Do we need our own servers?
No, but you can use them. The same build runs in our Singapore cloud or on your infrastructure — there is no reduced on-premise edition kept a version behind. Groups with a hard data-residency rule take that route and lose nothing by it.
What does training look like?
On your own data, not a demo company, with the people who will actually do the work rather than a room of managers. The person entering leave and the person running payroll are the two who decide whether this succeeds.
Send us the workbook and we will tell you what is in it
No obligation and no reformatting required. You get a written, sheet-by-sheet account of your own data — useful whether or not you end up choosing us.
No credit card. No sales call required. A real login, emailed to you.