Moving Off Spreadsheets: What the First Month Actually Looks Like

Vendors describe implementation in terms of features going live. That is not what the first month feels like from the inside. From the inside it feels like discovering how much of your HR process was held together by one person’s memory.

Here is a more honest version, based on how these go at companies of forty to two hundred people.

Week one is data, and it will be worse than you think

You export what you have and immediately find that the same person appears as Nguyen Van A, NV A, and A Nguyen across three files. Start dates disagree between the contract and the payroll sheet. Eleven people have no recorded end date for a probation that clearly ended.

This is normal, and it is also the most valuable week of the project. Every one of those inconsistencies was already costing you something, quietly. You just could not see them while they were spread across separate files.

One decision matters more than the rest here: pick a single source of truth per field before you start, and write it down. Start date comes from the contract. Salary comes from the latest signed appendix. Phone number comes from what the person confirms this week. Without that rule, the cleanup turns into an argument about which spreadsheet is more correct, and that argument has no end.

Week two is quiet, and that is a bad sign

Configuration happens, the system starts to look right, and the project feels like it is going well. Meanwhile nobody outside the project team has touched it.

Use this week to get five real people into the system doing one real task. Not a demo. An actual leave request from an actual employee who was not involved in choosing the software. What they say in the first ten minutes will tell you more than the whole configuration checklist.

Week three is when it gets worse

Everyone I have watched go through this hits the same dip. The old spreadsheet is still running because people trust it. The new system is running because it is supposed to. Now there are two systems, both half-maintained, and the work has doubled.

The dip is not a sign the project is failing. It is a sign you have not yet turned anything off. Pick a date, announce it, and on that date make the spreadsheet read-only. Not deleted. Read-only. People need to see it still exists and stopped moving.

Teams that skip this step run parallel systems for eight months and conclude the software did not work.

Week four is habits, not features

By now the question is no longer whether the system works. It is whether the twelve people who need to use it weekly actually do.

The things that decide this are unglamorous. Whether managers approve leave in the system or reply in a chat message and expect HR to key it in. Whether the payroll person exports from the system or maintains a private copy because they do not trust it yet. Whether new joiners are entered on day one or in a batch at month end.

Watch those three behaviours. They predict the outcome better than any usage dashboard.

What success looks like at day thirty

Not everything migrated. Not every feature switched on. Success at day thirty is narrower: one process runs end to end in the new system with nothing running beside it, the old file is read-only, and you can name the person responsible for each remaining gap.

Everything else is month two.

If you are somewhere inside this month right now, TalentHR imports from a spreadsheet and flags the duplicates and the disagreeing dates before you commit anything. Better to read that list in week one than in week three.