Data cleanup is one of the biggest efforts in any implementation. Records are audited, duplicates merged, gaps filled, formats standardized, and by go-live the data is in the best shape it has ever been. Everyone is relieved. A hard, thankless job is done — and, in almost every organization, quietly filed under done for good. That filing is the mistake.
Because the day you migrated is very likely the last day your data was ever fully trusted. From the first hour of real use, it begins to degrade — not through any single failure, but through a thousand ordinary actions. A new hire entered in a hurry with three fields left blank. A manager who fills in a job title free-hand instead of choosing from the list. A reorganization that happened in the business six weeks before anyone reflected it in the system. A duplicate record created because someone could not find the one that already existed. None of this is sabotage. It is simply what happens when real people use a system under real time pressure.
The framing that data quality is a one-time cleanup — a task with a start, an end, and a tick — is precisely why it decays. You treated a chronic condition with a single dose. The cleanup was real and necessary, but it addressed the data's state on one particular day, and said nothing about the rate at which it would deteriorate every day after. And deteriorate it does, silently, until one day a number that matters turns out to be wrong.
Quality Is Not a State You Reach. It's a Rate You Manage.
The most useful shift in thinking about HR data is to stop asking whether it is clean and start asking how fast it is getting dirty. "Clean data" sounds like a destination — a condition you arrive at and then possess. It is not. There is no state of cleanliness you reach and hold. There is only data decaying at some speed, and the question that actually matters: is anyone countering that decay, and fast enough?
Think of it the way you would think of a garden rather than a building. A building is finished; you construct it once and it stays built. A garden is never finished; leave it alone and it does not stay as you left it, it reverts. HR data is a garden. Every day, entropy adds a little disorder — a mistyped entry, an unrecorded change, a new duplicate — and every day either someone is doing the tending that offsets it, or the disorder accumulates. Over a year, the difference between a system that is tended and one that is not is the difference between data you can build decisions on and data everyone has quietly learned not to trust.
This reframe changes what good looks like. The goal is not a clean dataset; it is a low and managed rate of decay — controls that stop bad data entering, checks that catch it when it does, and a routine that corrects it before it compounds. You are not trying to finish. You are trying to keep the rate of rot below the rate of repair, forever.
It Fails Quietly, Which Is What Makes It Dangerous
If bad data announced itself, this would be a smaller problem. It does not. Almost everything that depends on HR data fails silently when the data is wrong — and silent failure is the most dangerous kind, because it looks exactly like success.
The report does not throw an error; it simply returns a headcount that is off by a few percent, and someone makes a decision on it. The analytics dashboard does not warn you; it confidently visualizes a trend that is partly an artifact of duplicate records. The automated workflow does not stop; it routes an approval to a manager who moved teams three months ago, because the reporting line was never updated. The compliance report does not flag itself; it is simply, quietly, wrong in a way no one notices until an auditor does. Every one of these looks like the system working. None of them is.
This is why data quality is so easy to neglect and so expensive to have neglected. Nothing breaks loudly enough to force attention, so it never reaches the top of anyone's list — right up until a decision is made on bad numbers, or a regulator finds the error first, and the cost of years of quiet decay arrives all at once. By then the problem is not a few bad records; it is that no one trusts the system's data at all, which is a far harder thing to repair than the data itself.
Managed Decay Is Somebody's Actual Job
A low rate of decay does not happen on its own, and it does not happen as a side effect of everyone being careful. It happens because it is deliberately owned — because someone treats the trustworthiness of the data as a standing responsibility rather than a project that ended at go-live. This is not a matter of one big annual cleanup; it is the unglamorous, continuous work of keeping the rate of rot down, and continuous work needs a name attached to it or it does not get done.
That ownership takes three practical forms, and they work together. Prevention: the controls that stop bad data at the point of entry — required fields, validation, picklists instead of free text, so the mistyped title and the blank field cannot happen in the first place. Detection: the regular checks that surface problems while they are still small — the duplicate scan, the completeness report, the exceptions that get reviewed on a cadence rather than discovered by accident. And correction: an actual routine for fixing what is found, on a schedule, before it compounds into something no one can untangle. The person who holds this sits close enough to the process to design the controls and close enough to the business to know which errors actually matter — and their job is not to make the data clean once, but to keep the rate at which it rots below the rate at which it is repaired.
A Final Thought
Every organization that has run a system for a few years has had the same unpleasant surprise: someone runs a number that matters, it looks wrong, and the investigation reveals that the data has been quietly decaying since the day it was migrated. No single failure caused it. It was the absence of tending, compounded over hundreds of ordinary days, in a system everyone assumed was fine because nothing had ever broken loudly.
Getting it right does not require another heroic cleanup — though you may need one to reset the baseline. It requires accepting that data quality is not a task you complete but a rate you manage: controls that prevent, checks that detect, a routine that corrects, and one person who owns whether the whole thing is trustworthy. Treat it as a garden, not a building, and the data stays worth trusting. Treat it as finished at go-live, and you are simply choosing not to notice the decay until it makes a decision for you.
You never have clean data. You only ever have data rotting slower than you fix it, or faster. Which one is a choice — and, more to the point, someone's job.
You never reach clean data and hold it. There is only data decaying at some speed — and either someone is tending it faster than it rots, or no one is and everyone has quietly stopped trusting it.