How to Move Employee Records From Excel to HR Software in Nepal

To move employee records from Excel to HR software in Nepal safely, treat the work as a data-quality and control project, not a file upload. The difficult part is deciding which row is true when employee names, joining dates, citizenship details, bank information, salary revisions and reporting lines disagree across files. A successful migration produces a trustworthy employee record, documented ownership and a repeatable correction process. It does not simply report that 1,247 rows imported without an error message.

Decide what the new system must become

Name one system of record for each type of information. Core identity and employment status may live in HR software, while accounting entries remain in finance software and signed originals remain in a controlled document repository. Record these boundaries. Otherwise staff will continue updating Excel after launch, and the organization will soon have two conflicting versions again.

Choose a data owner for every field group. HR might own legal name, employment status and manager; finance might validate bank and salary data; IT might own work email and system identifiers. Ownership means deciding the correct value and approving changes—not merely having permission to edit.

Inventory every source before cleaning

• Employee master workbooks and former-employee archives
• Attendance devices, shift sheets and manual correction logs
• Leave registers and pending approvals
• Payroll workbooks, salary revision letters and deduction schedules
• Recruitment or onboarding forms
• Asset registers and access-card lists
• Bank, SSF, PAN and tax-related records used by authorized teams

For each source, note the owner, last update, time period, sensitive fields, duplicate risk and whether it is authoritative. Do not merge everything immediately. A rarely used workbook may contain older information that overwrites a newer verified record. Preserve a read-only copy of original exports with a date and access restriction so migration decisions remain traceable.

Create a canonical employee identifier

Names are poor keys. Spellings, initials, married names, Nepali and English scripts, and extra spaces can create false duplicates. Assign a stable employee ID that does not change with department, location or job title. Map attendance-device IDs, payroll codes and legacy numbers to that identifier in a separate crosswalk. Never use citizenship, phone or PAN numbers as convenient public identifiers; they are sensitive and may change or be missing.

Build a data dictionary before the import template

The dictionary should state format, allowed values, whether blank is valid, source of truth, owner and sensitivity. It also records transformations—for example converting several department spellings into one approved value. This turns one-time cleaning into an operating standard for future onboarding and updates.

Clean in a working copy, never in the only source

Normalize whitespace, dates, phone-country codes and controlled values using repeatable rules. Flag suspicious records rather than guessing. A blank exit date may correctly indicate an active employee; a zero salary may be an error or an unpaid role. Create exception columns such as “needs HR confirmation” and “needs finance confirmation.” The team should resolve high-risk fields before import and may defer low-risk optional fields with an owner and deadline.

Detect duplicates using several signals: employee ID, work email, phone, date of birth and similar names. Human review is essential because family members can share contact details and the same person can have separate historical engagements. Keep a merge log recording which record survived and which values were selected.

Minimize sensitive information

Do not migrate a column simply because it exists. Ask whether it supports a current operational, contractual or legal purpose and whether the destination has appropriate access controls. Old medical notes, unstructured remarks, interview comments and copies of identity documents deserve particular scrutiny. Restrict the migration workspace, avoid sending employee files through personal chat or email, and remove temporary exports after acceptance according to a documented retention decision.

For the legal context, review the current Nepal Labour Act 2074 and Labour Rules with qualified advisers. For contribution-related records, use current Social Security Fund guidance rather than assumptions embedded in an old spreadsheet.

Map fields and transformations explicitly

Create a mapping table with source workbook, sheet, column, destination field, transformation, default rule, owner and validation. Do not use a default such as “Kathmandu” or “permanent” merely to make required-field errors disappear. Defaults must be true for every affected employee or be replaced by an explicit “unknown/pending verification” workflow the system supports.

Test special characters and Nepali text early. Open exported samples in the destination and verify that names, addresses and notes retain the correct encoding. Leading zeros in phone numbers or codes often disappear when spreadsheet cells are treated as numbers. Dates can also shift when regional formats are ambiguous; use an agreed ISO-style transfer format where supported.

Use three migration passes

Pass 1: structural test

Import 10–20 deliberately varied records: long names, Nepali script, blank optional fields, multiple locations, managers, former employees and salary histories. The goal is to test formats, relationships, errors and rollback—not to impress stakeholders with volume.

Pass 2: rehearsal

Load a full sanitized or controlled dataset into a non-production environment. Reconcile counts by status, department and location. Sample individual records against approved sources. Test permissions so managers and employees do not gain inappropriate visibility.

Pass 3: controlled production cutover

Freeze legacy updates for a clearly announced period, extract final changes, import, reconcile and obtain owner sign-off. Record the last legacy transaction and first live transaction. Keep a rollback decision point, but avoid allowing routine parallel updates for weeks because that recreates divergence.

Reconcile, do not merely spot-check

• Total employees by active, notice and exited status
• Counts by department, location, employment type and manager
• Joining and exit dates outside expected ranges
• Employees without managers or with circular reporting lines
• Salary totals and effective-date histories visible only to authorized reviewers
• Leave opening balances and pending requests
• Attendance identifiers that fail to map to an employee
• Required documents present, missing or expired

Use both aggregate reconciliation and employee-level sampling. Equal row counts do not prove equal meaning: an import can place a value in the wrong field for every employee. HR, finance and a business manager should sign off on the portions they own. Keep the signed migration report with exception decisions and correction evidence.

Where Hajiri fits—and what to ask other vendors

Hajiri can be considered when a Nepali team wants employee records connected with attendance, leave, payroll preparation and employee self-service. Ask the Hajiri team to provide its current import template, validation behavior, role design and export process, then test them with your sample. Apply the same test to alternatives.

RigoHR describes employee, attendance, leave and payroll capabilities on its official Nepal product page. NepalHRM presents its own Nepal-focused product on its official site. Vendor mentions here are not rankings; migration quality depends on your data, configuration, validation and support agreement as much as product scope.

A practical cutover checklist

• Approve scope, owners, dictionary and security rules.
• Back up original exports and restrict access.
• Clean and map data with an exception log.
• Run structural test and correct the mapping.
• Complete rehearsal and full reconciliation.
• Train administrators, managers and employee support contacts.
• Announce freeze, cutover and query channels.
• Import final deltas and obtain written sign-off.
• Monitor corrections for two payroll or attendance cycles.
• Archive or retire legacy access without deleting required records.

After launch: prevent spreadsheet relapse

Publish the process for correcting personal data, changing reporting lines, revising salary, closing an employee record and importing bulk changes. Track who approved each change. Review duplicate and incomplete records monthly during stabilization. Employees should know where to view their data and how to raise a correction. Managers need deadlines and escalation routes. The migration is complete only when the new operating process is trusted enough that shadow spreadsheets stop growing.

Continue with these practical Hajiri guides

• 30-day HRMS implementation plan
• HR software buyer’s guide
• Role-based access for HR systems
• Employee self-service in Nepal
• Payroll accuracy checklist
• Useful HR metrics for Nepal

Plan corrections after employees review their profiles

After the first import, give employees a defined review window for appropriate personal and employment details. Do not expose salary, identity documents or other restricted fields simply to make review convenient. Provide a correction form that records the existing value, requested value, supporting evidence where necessary, and the authorized reviewer. Bulk-correct recurring mapping errors centrally instead of asking every employee to submit the same issue.

Track correction categories during the first month. Many wrong departments suggest a mapping defect; many missing managers suggest an ownership problem; repeated date changes may indicate format conversion. Use those patterns to repair the source process. Keep a cutover register showing corrections completed before payroll, those safely deferred, their owners and due dates. This makes uncertainty visible without pretending the imported dataset was perfect.