A few years ago, an industrial company decided to modernize its ERP. An 18-month project, a seven-figure budget, a well-known integrator. The IT team documented the existing system, listed the features, migrated module by module. Delivered on time. Users unhappy. Processes just as heavy — on a new platform.
This wasn’t an IT failure. It was a failure of method.
The symptom — and how to recognize it
“We can’t do that. The system doesn’t support it.”
If you’ve heard that sentence in your organization, you know the underlying problem. Your business processes have gradually adapted to your IT constraints. Not the other way around. What was supposed to be a tool has become the reference: the system defines how you work, not your business defining what the system should do.
The most revealing sign is in the language.
I worked with a consulting firm where everyone talked about “timesheet entry” — a single concept in their system. When we dug into it during a domain modeling exercise, we found it covered at least three distinct business needs.
HR looked at those timesheets for payroll and talent management. The project manager looked at them to track contract profitability. The resource director looked at them to identify underutilized consultants and rebalance teams — relieving those who were overloaded, allocating those with availability.
Three uses. Three granularities. Three different timelines. But because the system only knew one concept, no one had ever questioned this artificial unity. We realized, by the end of the exercise, that HR and the resource director didn’t need the same data. The system had kept them under the illusion that they were talking about the same thing.
When your team uses your system’s vocabulary to describe your business reality, the contamination is complete.
The classic mistake in modernization projects
When a company decides to modernize, the first question asked is almost always the same: “What do we have?”
The IT team is called in, the existing system is audited, features are listed, flows are mapped. Then the integrators are asked: “How do we migrate this?”
The result is predictable: a new system that reproduces the organization of the old one. New stack, same constraints. New contract, same frustration. The budget was spent, the project was delivered — but the underlying problem was never addressed.
Starting from what exists to define the future guarantees the future looks like the present.
Problem space and solution space — the distinction that changes everything
There are two fundamentally different questions in a modernization project.
The first: what does your business actually need to do? What are your real business rules — the ones that come from your regulatory constraints, your value chain, your customers? Independent of how your current system works.
This is what’s called the problem space: the reality of your business domain, freed from any technical constraints. “Timesheet entry” doesn’t exist in the problem space. There’s payroll management, contract steering, and resource allocation — three distinct concepts with their own rules, their own stakeholders, their own data needs.
The second: how will technology serve that reality? With which systems, integrations, budget and feasibility constraints? This is the solution space: the target architecture, with its realistic trade-offs.
The sequence is non-negotiable. Problem space first. Solution space second. The reverse produces systems that perpetuate confusion rather than resolve it.
Why the sequence is almost always reversed
IT teams start from what they know. That’s human. Documenting what exists is tangible, reassuring, billable. Modeling what the business should do — independent of what it does today — is uncomfortable, and often perceived as theoretical.
Vendors and integrators aren’t incentivized to ask this question. They’re commissioned to deliver a system, not to challenge requirements. The more complex the existing system, the more expensive the migration.
And the business itself struggles to articulate its needs outside its current constraints. When you ask an operations director “how should your process ideally work?”, the answer almost always starts with “well, currently what we do is…”. The business domain has never been formalized. It lives in habits, in workarounds, in internal training. And in the system’s vocabulary.
What this changes in practice
I worked on a modernization project where we spent three months modeling the business domain before touching anything in the existing system. Three months that almost got cut from the plan at every steering committee. “We’re losing time.”
What we found: a significant portion of the “constraints” the IT team considered fixed facts were actually business rules that had never been formalized — sometimes contradicted by what the operational teams were actually doing. Entire use cases invisible in the current system, not because they didn’t exist, but because they had been worked around for so long they had become invisible.
The final migration plan was radically different from what we would have produced starting from the existing system. Fewer modules to migrate. More value delivered in the first twelve months. Less technical debt from day one.
Modeling the domain without legacy constraints is not a mistake. It’s the prerequisite to knowing which constraints actually matter.
So, concretely
Before your next modernization project, one question to ask your team or your vendor: “Where do you start — with what we have, or with what we need to do?”
If the answer starts with the audit of the existing system, the risk is there.
A project that starts from the business domain takes more time at the outset. It delivers less confusion over time, fewer rewrites six months after go-live, and a result that serves your business — not your 2014 IT system.
That’s the first thing I do in every Architecture Assessment: model the domain before proposing anything.
If you’re a CTO rather than a CEO and you’re managing this discipline under delivery pressure, this article covers the specific trap that catches teams mid-execution →