Your HRIS Isn’t the Problem. Your Data Is.
When systems don’t agree on what an organisation is
Most HR system projects begin with a sentence that sounds reasonable and harmless enough: “We’re implementing a new system, and we need to migrate our data.”
It is a comforting way to think about what is about to happen, because it frames the work as something technical and bounded. ETL, clean a few things up, map a few fields and move on.
In practice, this framing is almost always wrong.
What most organisations are actually doing is not migrating data. They are migrating a model of themselves, and they usually do not realise that until they are well into the project.
Every HRIS has an opinion about what an organisation is. It has ideas, often quite rigid ones, about what a location means, what an organisational unit is, what a role is, where costing belongs, where rules attach, and how all of those things relate to each other. These ideas are not neutral. They are design decisions. They reflect the world as the system’s designers thought it should be.
Your organisation already has its own model, whether anyone has ever written it down or not. It is embedded in your structures, your job codes, your awards and agreements, your cost centres, your reporting lines, and in a thousand small decisions that were made over years to solve very local problems.
Most of the time, these two models are not the same.
Every system has a theory of the organisation
It is easy to underestimate how opinionated enterprise systems really are. They look flexible because they offer configuration, hierarchies, and drop down lists, but underneath that surface they are enforcing a particular way of carving the world up.
Some systems want everything to live in a clean organisational tree. Some are location first and treat everything else as an attribute. Some assume that roles are stable and that people move between them. Some assume that people are stable and roles are just labels. Some attach costing to positions. Some attach it to people. Some attach it to time.
None of these choices are inherently wrong. They are just different abstractions.
The problem is that your organisation has also evolved an abstraction, and it has done so slowly, pragmatically, and in response to real constraints. It encodes funding models, industrial boundaries, asset ownership, historical compromises, and operational reality. It works, but it often looks nothing like the clean model that a new system is expecting.
This is where the trouble starts, because implementations are not really about moving data from one place to another. They are about translating one worldview into another, and translation always involves loss, distortion, or invention.
Messy is often rational
One of the laziest ways these situations get described is to say that the organisation’s data or structure is messy. Sometimes that is true but more often, it is just incomplete or misunderstood.
From the outside, many organisations look simple. A church is a church, a university is a university, a zoo is a zoo. But if you assume that their internal structures more or less mirror their public identity you will soon find that they don't.
I once worked with a very large religious organisation that, from the outside, looked like a single, fairly coherent entity. Internally, it employed people under a surprising range of industrial instruments, including a number under the Live Performance Award, because it had professional organists, choirs, and performance staff as part of its operations. It also had administrative staff, community workers, educators, and various other roles that lived in completely different industrial worlds.
I have seen the same thing in universities, which many people think of as purely academic or professional environments, but which often have a substantial number of staff running cafes, shops, and food outlets across their campuses. From a payroll perspective, these are not edge cases, this is normal.
What looks like a single organisation from the outside is usually a federation of very different kinds of work that just happen to share a logo.
Inside these organisations, the structures that exist are not arbitrary. They encode which bits are funded in which ways, which assets belong to whom, which awards apply where, and how various historical arrangements have been managed. Calling this mess misses the point, it is a coherent model that just does not happen to match the one your new system is bringing with it.
The multi site problem that is not really about sites
A particularly clear example of this showed up in a large, multi site, asset heavy organisation I worked with some years ago, think large retail operation, with multiple physical locations, different kinds of staff attached to each site, and a complex internal costing and funding model.
The existing structure was deeply intertwined with how it thought about locations, cost centres, and pay rules. The new system they were implementing had a much cleaner, more abstract model of what a location and an organisational unit were.
Everyone involved could see that the existing structure was complicated but changing it was not a matter of renaming a few departments. It would have meant rewriting JD's, reclassifying roles, and potentially reopening agreements.
So the organisation made a rational choice. They decided to carry the existing model forward.
From a project perspective, this looked like a mapping exercise. From a systems perspective, it was something closer to forcing square pegs into square(ish) holes. The result technically worked, but only because the new platform was bent into a set of conceptual contortions to preserve the old world inside the new one.
What most projects fail to take into account is what I call the time horizon. You do not replace HR or payroll systems on a whim, and it is entirely normal for these platforms to be in place for ten years or more. A structure that works on day one is a very different thing from a structure that will still be workable in a decade, after people have moved on, strategies have changed, funding models have shifted, and external forces, whether regulatory, industrial, or economic, have imposed changes that nobody could fully anticipate at the time.
Decisions that are made under project pressure, and often quite reasonably in context, end up shaping how the organisation understands and governs itself for a very long time. By the time the limitations of those decisions are fully felt, many of the people who were there at the beginning are no longer around to explain why they were made. In that sense, they did not migrate complexity they just reframed it.
The hidden cost of just map it
Faced with a gap between the organisation’s model and the system’s model, projects reach for mapping tables, translation layers, and artificial hierarchies. A concept that is one thing in the old world becomes three things in the new one. Or three things become one, with flags.
Each individual decision looks reasonable. Taken together, they create a structure that is harder to understand, harder to change, and harder to govern than either the old system or the new one would have been on their own.
What makes this especially difficult is that these decisions are rarely made in one place. They emerge incrementally, driven by deadlines, data loads, and the need to keep the project moving. By the time anyone stands back and looks at the whole, it is usually too late to unwind. At that point, the system works, but only in the sense that a machine full of shims and braces works. It runs, but nobody would choose to design it that way.
Why this keeps happening
Part of the reason this keeps happening is that almost nobody in an organisation actually owns the organisational model as a thing in its own right. HR owns some of it, finance has a say, operations is in the mix and IT is asked to implement it.
Procurement looks at features, projects look at milestones, Data migration looks at fields and formats but very few people are explicitly asking whether the way the organisation currently describes itself still makes sense, or whether the new system’s way of describing the world is actually a better fit.
Even when those questions are asked, the answers are rarely simple. As in the multi site example, changing the model often means triggering industrial, contractual, or governance processes that are far larger and more complex than the system project itself. In those circumstances, carrying the existing structure forward is often the only viable option. The mistake is not in making that choice. The mistake is in pretending that it is a neutral or purely technical one.
The choice most organisations are really making
Framed honestly, the choice in most HRIS implementations is not between clean and dirty data, it is between different kinds of complexity.
You can choose to confront some of that complexity, simplify parts of the model, and accept the organisational cost of doing so. Or you can choose to preserve it, translate it, and accept the technical and governance cost of that instead.
What you cannot do is avoid the choice altogether.
When organisations tell themselves they are just migrating data, what they are really doing is choosing, by default, to make their existing model permanent.
Treat the model as the system
The deepest mistake in many HR and payroll projects is to treat the software as the system. Your organisational model is the system, the software just encodes it.
If you do not surface that model, examine it, and make conscious decisions about what you are carrying forward and what you are not, then the implementation will do it for you, quietly and irreversibly, under the pressure of timelines and cutover dates.
None of this means that organisations should always try to redesign themselves during a system implementation. That is often unrealistic, but it does mean that they should be honest about what they are really doing.
You are not migrating data. You are translating a worldview.
And worldviews, unlike spreadsheets, do not move without changing shape.