HR Software Migration in Nepal: How to Switch from your Old HR System Or Spreadsheets

Where You Are Migrating From

Almost every company we talk to sits in one of three places. The starting point changes the first week of work, and very little after that.

Profile 1 — Spreadsheets and chat

Employee data in Excel, leave requests over WhatsApp, payroll calculated by hand each month. Nothing to disconnect and no vendor to notify. Technically the simplest migration, though usually the one with the messiest data.

Profile 2 — An attendance machine with desktop software

You bought a biometric device, it came with software that runs on one PC in the accounts room, and someone exports to Excel every month to run payroll. This is the most common position for established Nepali SMEs, and the one with the biggest misconception attached: that switching means replacing the hardware. It usually does not.

Profile 3 — An existing HR system

You already pay for software. It might be on-premise, outgrown, poorly supported, or simply not connected to payroll. The technical migration here is the easiest of the three, because the data is already structured. The complications are commercial and contractual, not technical.

Many companies are a hybrid — a device for attendance, spreadsheets for leave, and a separate payroll file. That is normal, and it is an argument for consolidating rather than a complication.

What HR Software Migration Actually Involves

HR software migration is the process of configuring a new system to match your company's actual policies, moving your existing employee and payroll data into it, connecting any hardware you are keeping, training the people who will use it, and running it alongside your old process until you trust it.

Notice how little of that is technical. With a cloud platform there is no server to install and no IT project to manage. The work is almost entirely decisions and data:

• Decisions — what your leave policy actually says, how overtime is really calculated, who approves what, which of your four historical salary structures you are keeping.
• Data — what exists, where it lives, how much of it is accurate, and who is willing to sign off that it is.

This is why timelines vary so much between two companies buying the identical product. The one with a documented policy and a clean employee list is live in two weeks. The one that discovers mid-project that three departments calculate overtime differently takes two months — and the extra six weeks went on making decisions, not configuring software.

The useful reframe: migration is not something a vendor does to you. It is a short, structured conversation about how your company actually works. Anyone who tells you it is entirely hands-off is describing a project that will produce a system nobody uses.

Why Most HR Software Projects Stall

The failure pattern is well documented and remarkably consistent. Commonly cited industry figures suggest a substantial share of HR technology implementations fall short of their original goals — SHRM is frequently quoted at roughly one in four, while Gartner's estimates for enterprise software more broadly run considerably higher. Research cited by HRIS advisory firm OutSail indicates that up to 60% of data migration projects experience meaningful delays or budget overruns.

Treat these as directional rather than precise — they come from different methodologies and different definitions of "failure," and secondary sources routinely disagree on the exact numbers.

The direction, however, is not in dispute. The recurring causes:

• Poor data quality carried across. Migration is treated as copy-and-paste. Inconsistent, duplicated, or outdated records get imported faithfully, and the new system automates the old errors at higher speed. A new platform does not clean your data — it inherits it.
• No agreed data owner. Three people maintain three versions of the employee list, and nobody has the authority to declare one of them correct.
• Undocumented policy. The leave rule "exists" in the HR manager's head. It cannot be configured until it is written down, and writing it down surfaces disagreements that were previously invisible.
• Hardware treated as disposable. Companies assume a new system means new devices, price the project accordingly, and abandon it. Often the device was never the problem.
• A go-live date chosen badly. Mid-month, mid-payroll, or during audit season. The team has no capacity to validate anything.
• No parallel run. The old process is switched off on day one. The first error is discovered on payday, in front of every employee.
• Managers were never involved. HR adopts the system; managers keep approving leave over WhatsApp; the shadow spreadsheet survives. Low adoption is the most common quiet failure.
• Nobody defined "done." Without a validation checklist, the project drifts and no one can say whether it succeeded.

Every one of these is a process problem with a process fix. None is solved by buying a different product.

What You Are Actually Migrating

"Migrating our HR data" sounds like one task. It is five, and they are not equally difficult. Separating them is the fastest way to make the project feel manageable.

1. Employee master data — straightforward. Names, employee codes, join dates, departments, designations, reporting lines, contact details, bank account and PAN details, emergency contacts, SSF or PF registration numbers. Already in a spreadsheet, a device export, or a system export. The work is deduplication and filling gaps, not transformation.
2. Opening leave balances — the trust test. Per employee, per leave type, as of your go-live date. Small in volume, disproportionate in consequence. Get this wrong and you have spent money to create a new venue for the same old argument.
3. Payroll structure — the part that requires actual thought. Not last year's payslips — the structure. Salary components, allowances, deductions, SSF and PF contribution rules, TDS treatment, overtime multipliers, and every exception that has quietly accumulated. This is where undocumented practice surfaces, and where your time is best spent.
4. Documents — steady, low-risk background work. Contracts, appointment letters, certifications, ID copies. Runs in parallel with everything else and never blocks go-live. Current employees and current contracts first; historical files can follow.
5. Historical attendance logs — usually skip. Whether they sit on a device, in desktop software, or in an old HRIS, years of punch records add bulk and risk for almost no operational value. Keep the old records archived for compliance and start attendance fresh from go-live. This single decision removes the messiest part of most migrations at almost no real cost.

The practical sequencing: master data first, payroll structure second, leave balances third, documents in the background, attendance history usually not at all.

Migrating from Spreadsheets and WhatsApp

The simplest starting point technically, and the one where cleanup matters most. There is no vendor to notify and no contract to unwind — but there is also no system that has been enforcing consistency, so expect the data to need work.

What to watch for specifically:

• Multiple versions of the truth. The HR list, the finance list, and the attendance register rarely agree. Pick one as authoritative before you start, and reconcile the others against it.
• Ghost employees. People who left months ago are still on the sheet, still counted in headcount, sometimes still in the payroll formula.
• Formula rot. Payroll spreadsheets that have been copied forward for years accumulate broken references and hardcoded overrides. Do not port the formulas — document the rules they were meant to express and configure those instead.
• Undocumented exceptions. The two employees on a legacy salary structure, the one branch with a different holiday list. In a spreadsheet these are invisible. In a configured system they must be explicit.
• Continuity risk. The whole thing lives on one laptop. This is usually the real reason leadership approves the project, and it is worth naming.

The upside: there is no data export to negotiate, no lock-in to escape, and no notice period to time. You can go live as soon as your data is clean.

Migrating from an Attendance Machine

This is the most common position for established SMEs in Nepal, and the one surrounded by the most unnecessary anxiety.

The typical setup: a biometric or card-based device on the wall, bundled desktop software running on a single PC, and a monthly ritual where someone exports attendance to Excel and hands it to whoever runs payroll. It works, in a limited way. Its limits are well known to everyone who uses it — data trapped on one machine, no backup if that machine dies, no remote access, no payroll link, no visibility for managers, and no ability to cover field staff who never walk past the device.

The good news first: you almost certainly keep the hardware.

Option A: Keep the device and connect it

For most companies this is the right answer. Pedal1 integrates with biometric attendance devices and syncs the data automatically. Practically, that means:

• No re-enrolment. Employees keep using the same machine the same way. Nobody queues up to register fingerprints again.
• No hardware spend. The device you already own becomes an input to a cloud platform instead of a dead end.
• The desktop PC stops being a single point of failure. Attendance flows to the cloud, where it is backed up, accessible remotely, and visible to managers.
• The monthly Excel export disappears. Attendance feeds leave and payroll directly, which is the whole point.

The change your team feels is not at the device. It is everything downstream of it.

Option B: Retire the device and go mobile

Worth considering if the machine is failing, if it sits in the wrong place, or — most commonly — if a growing share of your team is field-based or works across multiple sites. Geofence clock-in handles those cases properly, and a device on one wall never will. Re-enrolment is a one-time cost of roughly twenty seconds per employee.

Many companies end up running both: the device for office staff who are used to it, geofence and mobile for field and branch teams. That is a supported configuration, not a compromise.

The one thing to get right: User ID mapping

Every device stores employees as a numeric User ID — often just 1, 2, 3, in the order they were enrolled. Your payroll knows people by employee code or name. The mapping between those two is the join between your attendance machine and your payslips. Get it wrong and one person's attendance lands on another person's pay.

Build the mapping table explicitly during migration, and check these while you are in there:

• Leftover IDs. Enrolments belonging to people who left, sometimes reassigned to new joiners, sometimes not.
• Duplicate enrolments. The same person registered twice, usually after a failed fingerprint read.
• Unlabelled entries. IDs stored as "User 7" with no name attached, because nobody filled in the field at enrolment.
• Device clock drift. A machine running several minutes fast or slow has been quietly generating incorrect late marks — possibly for years. Verify the device time against actual time before go-live, or you will import a bias and then get blamed for it.

What to do with the historical attendance data

Export it, archive it, and do not migrate it. The desktop software can usually produce a full log dump — take one, store it somewhere safe with a note on the retention period, and start clean. Occasionally it is worth importing the current month so payroll has a full cycle, but even that is often unnecessary if you time go-live to a month boundary.

Migrating from an Existing HR System

If you already run HR software, the technical migration is the easiest of the three profiles — the data is structured, exports exist, and field names usually map cleanly. The complications are commercial.

Sort these out before you give notice:

• Check your data export rights. Read the contract, specifically what you are entitled to extract and in what format on termination. Do this before the conversation about leaving, not after. It is a much easier request while you are still a paying customer.
• Know your renewal date. Renewing for another year and then migrating in month two is an expensive and entirely avoidable mistake. Work backwards from the renewal to set your go-live.
• Take a full export while access is live. Employees, historical payroll, leave balances, leave history, documents, and audit logs. Store it as your compliance archive regardless of what you migrate. Access sometimes ends faster than expected.
• Confirm the notice period. Some contracts require notice well ahead of renewal. Missing it by a week can cost a year.
• Ask about post-termination read access. Some vendors provide it, some do not. Assume they do not and plan your archive accordingly.

And one thing to avoid on the technical side: do not import the old system's configuration assumptions along with its data. If your previous platform could not handle a rule, your team invented a workaround, and that workaround now looks like policy. Re-decide the rules from your actual written policy rather than reverse-engineering them from how the old software behaved. This is the single most common reason a second HRIS reproduces the frustrations of the first.

If you are switching because a previous implementation failed, that history is genuinely useful. It is worth being specific about which stage broke — migration, configuration, training, or adoption — because it tells you exactly where this project needs more attention.

The Pre-Migration Data Cleanup Checklist

Work through this before any import, whichever profile you are in. It is the highest-return hour in the project.

1. Remove exited employees. Anyone who left is archived, not migrated as active. Legacy spreadsheets and old devices both carry ghosts.
2. Resolve duplicates. The same person under two employee codes, usually from a rehire or a branch transfer — or two device enrolments.
3. Standardise name formats. One convention, applied consistently. This is what payroll and bank files match against.
4. Map device User IDs to employee codes. Skip only if you have no attendance hardware. Everyone else: this is the item to do carefully.
5. Verify bank details and PAN. A wrong account number is the one error employees notice immediately and remember for years.
6. Confirm join dates. They drive leave accrual, probation status, gratuity, and service-linked entitlements. An approximate join date produces wrong numbers forever.
7. Fix reporting lines. Every employee needs exactly one current approver. Vacant or outdated manager fields stall approval workflows on day one.
8. Reconcile leave balances and get them signed off. Circulate each employee's opening balance for confirmation before go-live, not after.
9. Document every salary component. List each allowance and deduction with its calculation rule. If two people describe a rule differently, that is the decision you need to make this week.
10. List your exceptions. The employee on a legacy structure, the branch with a different holiday calendar, the two people on a special overtime arrangement. Exceptions do not disappear because a new system arrived.
11. Check the device clock. Verify hardware time against actual time before any attendance data is trusted.
12. Decide your archive policy. What stays in the old system or the old export, who retains access, and for how long.

A candid note on item 8: circulating opening leave balances for employee confirmation feels like inviting trouble. It is the opposite. Every dispute raised before go-live is a cheap dispute. Every dispute raised after go-live is a strike against the new system's credibility — and credibility is far harder to rebuild than a balance.

Choosing Your Go-Live Date in Nepal

Timing is the most underrated decision in the whole project, and it is specifically local.

Best options, in order:

• The start of the fiscal year (Shrawan 1). Cleanest possible break. Leave accrual resets, payroll starts a fresh cycle, and your reporting year is contained in one system. If your timeline allows you to wait for it, wait.
• The first day of any Nepali month. The next-best option and entirely adequate. Payroll runs cleanly from day one with no split-month reconciliation.
• The start of a quarter. Workable, particularly if it aligns with an internal reporting cadence.

Avoid:

• Mid-month. You will process a split payroll across two systems in your very first cycle — the worst possible introduction to a new platform.
• Dashain and Tihar. Half the team is out, the other half is covering, and leave volume is at its annual peak.
• Audit or statutory filing season. Your finance team has no capacity to validate payroll output, and validation is the point.
• The week before an SSF submission deadline. Give yourself one clean cycle before a statutory filing depends on the new system.

One additional consideration if you are leaving a paid system: your renewal date is a hard constraint that outranks all of the above. Work backwards from it. If the ideal window has already passed this year, a short month-to-month extension is almost always cheaper than a rushed migration or a full-year renewal.

And a point specific to Nepal: if you operate on the Bikram Sambat calendar for HR and payroll but report or invoice internationally on the Gregorian calendar, confirm during configuration — not after — that the system handles both. Fiscal year boundaries, leave accrual periods, and payroll cut-offs should all be verified against your actual calendar before the first live run.

The Parallel Run: Why You Process One Payroll Twice

This is the step most companies want to skip, and it is the one that separates a smooth switch from a painful one.

For one payroll cycle, you run the new system and your existing method side by side. Then you compare, line by line: gross salary, each allowance, each deduction, SSF and PF contributions, TDS, net pay, per employee.

Yes, it is duplicated work for one month. Here is what it buys you:

• Every configuration gap surfaces before it affects a real payslip. Differences are almost always your old method carrying an undocumented exception — which is exactly what you needed to discover.
• Attendance mapping gets validated. If you migrated from a device, this is where a mis-mapped User ID shows up — as one person's hours on another person's payslip, caught in a spreadsheet rather than on payday.
• Your finance team develops confidence in the numbers, rather than being asked to take them on faith.
• You get a documented reconciliation you can show an auditor, a board, or a sceptical department head.
• The old process stays available as a fallback for exactly as long as you need it.

Expect small differences on the first comparison. That is a successful parallel run doing its job. A run that matches perfectly first time is pleasant; one that surfaces three discrepancies is genuinely more valuable.

After one clean cycle, switch off the old method — properly. Which brings us to the hardest non-technical part of any rollout: the cut-off date. Announce a date after which leave requests, attendance corrections, and payroll queries submitted outside the system are not processed. If you kept your attendance device, this applies to the old desktop software too — stop exporting from it, or people will keep treating it as the real record. Without that line, old habits survive indefinitely and you end up maintaining two systems permanently.

How Pedal1 Handles Migration

Pedal1 is a cloud business management platform built for growing SMEs, with Nepal as its home market. Because it is fully cloud-based, there is nothing to install, no server to provision, and no IT infrastructure to plan around — which removes an entire category of delay before the project starts.

Our implementation follows three stages:

1. Requirements and onboarding. We sit down with your HR policies, leave rules, shift patterns, and payroll structure and document them properly. Most of the value here is not technical — it is the act of writing down rules that previously lived in someone's memory, and resolving the ones that turn out to be contested.
2. Setup and configuration. Your instance is configured to your requirements: your leave types and accrual rules, your salary components, your approval hierarchies, your holiday calendar, your geofence boundaries and shift patterns. Configuration is against your policy, not a default template you then work around.
3. Data migration, device connection and training. Existing employee records are migrated, opening balances are loaded and verified, your attendance hardware is connected and User IDs mapped, and your team is trained — HR administrators in depth, managers and employees on the short list of things they actually need to do.

A few things about the Pedal1 HR module that reduce migration effort specifically:

• Biometric device integration. If you already run attendance machines, they connect and sync directly. You are adding intelligence on top of your current setup, not replacing it — which removes both the hardware cost and the re-enrolment disruption that stop most device-based companies from moving.
• One connected system, one migration. Because attendance, leave, and payroll are modules of the same platform rather than separate tools, approved leave updates attendance and flows into payroll automatically. There is no integration project between three vendors, and no second migration later when you add the next piece.
• Cloud and mobile from day one. Employees onboard onto the self-service portal from their phones. No device rollout, no installation, no per-machine setup.
• Geofence and geo-location for the staff your device never covered. Field teams, branch staff, and remote workers get verified attendance without hardware.
• Room to grow without re-migrating. CRM, project management, and cloud accounting run on the same platform and the same employee data. Adding a module later is a configuration step, not a fresh implementation.

Most SMEs are live within two to four weeks. The timeline is driven mainly by how quickly opening balances can be verified and how clearly your policy is documented — not by the software. For a fuller picture of the module itself, see our guide to HR software in Nepal.

What Is Included at No Additional Cost

A common and reasonable question during evaluation is what the implementation costs on top of the subscription. With Pedal1, the following are included in the standard package:

• Requirements gathering and onboarding
• Instance setup and configuration
• Technical support and assistance
• Regular software updates
• Data security and backup
• Mobile app access
• Analytics and reporting
• Cloud storage and infrastructure

For organisations with heavier requirements — comprehensive migration from a complex legacy system, multi-site device integration, extensive end-user training, or dedicated hypercare through the first cycles — a premium implementation package is available as an optional add-on. Current package and pricing details are on the pricing page.

Pedal1 vs. a Traditional Enterprise HRIS Rollout

Eight Migration Mistakes to Avoid

• Assuming you must replace your attendance hardware. A working device is an asset. Ask about integration before you budget for new machines.
• Skipping the User ID mapping check. The fastest way to put one person's hours on another person's payslip.
• Migrating everything. Years of attendance history add bulk, risk, and delay for almost no operational value. Archive it; start fresh at go-live.
• Giving notice before checking export rights. Get your data out — or at least confirm you can — while you are still a paying customer.
• Importing unverified opening balances. If employees do not agree with their starting number, they will not trust any number that follows.
• Skipping the parallel payroll run. The one shortcut that reliably costs more than it saves.
• Training only HR. Managers approve leave and employees submit it. If either group is untrained, the shadow spreadsheet survives and adoption quietly fails.
• Running both systems indefinitely. Without a hard cut-off — including on the old device software — "just this once" becomes permanent.

How to Know the Migration Actually Worked

Define "done" before you start. A migration is complete when you can answer yes to all of these:

• Headcount matches. Active employees in the new system equals your verified employee list. No ghosts, no omissions.
• Attendance lands on the right people. Spot-check device punches against employee records for a full week.
• Payroll reconciles. The parallel run matches your old calculation, or every difference is explained and deliberately accepted.
• Leave balances are confirmed. Every employee has seen and agreed their opening balance.
• Statutory outputs are correct. SSF, PF, and TDS figures match what you would have filed under the old process.
• Approvals route correctly. Every employee has a current approver, and a test request reaches the right person.
• Managers have used it. Not "have been trained on it" — have actually approved something.
• Employees can self-serve. A sample have logged in, viewed a payslip, and applied for leave without help.
• The cut-off is enforced. No parallel channel — including the old desktop software — is still accepting requests.

Run this list at the end of the first full month. Anything unticked is a specific, small piece of remaining work, which is far more useful than a vague sense that the rollout "mostly went fine."

Who Should Use This

• Growing SMEs (15+ employees) moving off Excel, email, and WhatsApp for the first time
• Companies with an existing biometric attendance device who want to keep the hardware and add cloud, payroll, and reporting on top
• Businesses outgrowing an existing HR system, particularly where attendance, leave, and payroll still do not connect
• Companies that tried HR software before and abandoned it, usually because migration or adoption failed rather than the product
• Multi-branch organisations needing branch-level holiday calendars, role-based access, and consolidated head-office reporting
• Organisations with field or shift-based teams that a wall-mounted device was never going to cover
• Companies formalising HR ahead of SSF registration, audit, due diligence, or investment

Getting Started with Pedal1

The most useful first conversation is not a feature demo. It is a scoping call about your specific migration: how many employees, what your data currently looks like, what hardware you already run, which payroll exceptions you are carrying, and when your cleanest go-live window falls.

Bring three things and you will get a realistic timeline in a single call:

1. Your current employee list, however messy it is
2. Your leave policy — written down, or the two or three rules you know are contested
3. Your salary structure with each component and its calculation rule

If you have an attendance machine, the make and model is worth mentioning too — it is usually the first thing we can rule in.

Schedule a demo with Pedal1 and we will map your migration against your own data and your own calendar.

Conclusion

The hardest part of adopting HR software is not choosing it. It is the fortnight between signing and trusting the first payroll it produces.

That fortnight is entirely manageable when it is structured: clean the data before it moves, keep the hardware that already works, document the policy before it is configured, pick a go-live date that respects the payroll calendar, run one cycle in parallel, and define what "done" means before you begin.

Whether you are coming from a spreadsheet, a machine on the wall, or a system you have outgrown, the switch is usually smaller than the fear that surrounds it — two to four weeks, one parallel payroll run, and a cut-off date that everyone respects.

Ready to see what the switch looks like against your own data and your own hardware? Book a demo with Pedal1 or call +977-9801879710.