The tool takes an afternoon. The migration takes a month — mostly because of decisions you've been avoiding.
The hard part of moving off spreadsheets is not importing data; it is that spreadsheets let you avoid decisions software forces you to make. What exactly is the late-mark rule? Which leave types exist? Which divisor computes per-day pay? A month is the right length: week one for decisions and clean employee data, week two to configure and pilot, week three to run the whole team in parallel with the old sheets, week four to cut over and stop maintaining both.
Software needs explicit rules where a spreadsheet allowed a case-by-case judgement. Settle these first, because everything downstream depends on them:
Expect disagreement — this is the week you discover two managers have been applying different half-day rules for a year. That discovery is a benefit of the migration, not an obstacle to it.
Every module hangs off the employee list, and it is almost always the messiest sheet in the business. Before importing:
Time spent cleaning the employee sheet before import is repaid several times over. Time spent cleaning it after import is repaid at a much worse rate, because corrections now have to propagate.
| Migrate | Employee master, current salary and its effective date, current leave balances, holiday calendar, client and project list, open quotes and invoices, current asset assignments |
|---|---|
| Leave behind | Historical attendance, historical payroll runs, closed projects, resolved requests, old task history |
The instinct to import three years of history is strong and almost always wrong. It multiplies the migration effort, imports the mess along with the data, and delivers value you will use twice a year. Keep the old spreadsheets, read-only, in a clearly labelled archive folder — that satisfies the real requirement, which is being able to look something up.
The exception is leave balances. Those are a live liability and must come across accurately, because they will be used immediately.
Configure the system with week one's decisions, then pilot with five to eight people from one team — ideally including a sceptic, whose objections you would rather hear now.
During the pilot week, have them do everything for real: mark attendance daily, raise a leave request, get it approved, log daily tasks. Watch for the friction points that decide adoption:
Fix what surfaces before the whole team sees it. A bad first week is very expensive to recover from.
Roll out to the full team with a short session — 30 minutes is enough — covering how to mark attendance, how to request leave, how to log tasks, and where payslips will appear. Then, for one full month, run both systems.
Parallel running is the step teams skip and regret. It is genuinely duplicated effort for a few weeks, and it is what turns a payroll disaster into a reconciled discrepancy list. At month-end:
Differences will exist, and most will be the new system being right — an approved leave day the spreadsheet missed, a half-day the old rule applied inconsistently. Each one you investigate is a rule you now genuinely understand. Pay from whichever you trust, but reconcile before you decide.
When the parallel month reconciles, stop maintaining the spreadsheets. Explicitly:
If you are migrating from a sheet, why the sheet broke is worth reading first; if from a chat group, the WhatsApp version.
| Total timeline | About 30 days, including one full parallel month |
|---|---|
| Week 1 | Decide policy rules · clean the employee master |
| Week 2 | Configure and pilot with 5–8 people from one team |
| Week 3 | Full rollout, both systems running in parallel |
| Week 4 | Reconcile payroll, cut over at a month boundary, archive the sheets |
| Migrate | Employee master, current salary and effective date, leave balances, holidays, clients and projects, open quotes/invoices, asset assignments |
| Don't migrate | Historical attendance, past payroll runs, closed projects, old task history — archive instead |
About 30 days for a small business: one week to settle policy rules and clean the employee master, one week to configure and pilot with a small team, one week of full rollout running in parallel with the spreadsheets, and a final week to reconcile payroll and cut over. Creating the workspace itself takes minutes; the month is for decisions and verification.
Usually not. Importing years of history multiplies the effort, brings the existing mess along with it, and delivers value you will use very rarely. Migrate current state — employee master, current salary with its effective date, current leave balances, the holiday calendar, clients and projects — and keep the old spreadsheets as a clearly labelled read-only archive.
Parallel running means operating the new system and the old spreadsheets together for one full month, then computing payroll both ways and investigating every difference. It is genuinely duplicated effort for a few weeks, and it is what converts a potential payroll disaster into a reconciled list of discrepancies — most of which turn out to be the new system being correct.
At a month boundary, so a payroll period is never split across two systems. Mid-month cutovers create reconciliation problems with no clean answer and are the most common self-inflicted migration failure. Aligning with a financial year or quarter start is convenient but much less important than the month boundary.
One row per person with duplicates and leavers removed, consistent name formatting because these become logins and payslip names, departments and designations from a fixed list rather than free text, a date of joining for everyone, current CTC with its effective date, and a work email for each person to serve as the login.
Policy decisions, not technical work. Software requires explicit rules where a spreadsheet allowed case-by-case judgement — the exact late-mark rule, the leave types and their carry-forward treatment, the per-day divisor for loss of pay. Teams typically discover that different managers have been applying different rules, which is a benefit of migrating rather than an obstacle.
Creating a Merik workspace takes minutes, which is why the plan above spends its time on decisions and verification instead. Employees self sign-up and land in the right department with designation and CTC in place, so the employee master is populated by the people who know their own details rather than by one person retyping a sheet.
The rules from week one — grace windows, late marks, half-days, holiday calendar, leave types, the payroll cut-off — are configured once and then applied identically to everyone, which is precisely the inconsistency most migrations uncover. For teams bringing messy task history, the Fix Project Names screen maps historical free-typed project names onto real project records in bulk. And because attendance, leave and payroll share one dataset, the parallel-month reconciliation compares two calculations rather than two datasets. See how setup works, the feature list, or talk to us if you would like help with the import.
What to look for before picking a workforce platform.
Every clause a working attendance policy needs, in plain language.
Seven failure modes, the headcount where each one bites, and what to use instead.