Architecture, integrations, users, workflows, and operational dependencies should shape the modernization path—not the other way around.
Engineering Perspective · 4 min read · CognitivZen Editorial Team
Modernization programs usually begin with a target. Microservices. A new front end. A move to the current framework. The target is chosen first and the plan works backwards from it.
This is the wrong order, and it produces a familiar outcome: eighteen months in, the new architecture is partly built, the old system is still running because three workflows could never be moved, and the organization is now operating two systems instead of one.
The better starting point is less satisfying. Before deciding what the system should become, map what it cannot stop doing.
The integrations you do not control. Every enterprise system has connections to things owned by someone else — a partner’s EDI feed, a regulator’s submission format, a device that speaks a protocol from 2004. These set hard boundaries. A modernization plan that assumes they will change is a plan with a dependency on another company’s roadmap.
The data model people reason in. Users have internalized the current structure. They know a “case” has one owner and a “claim” can have several, and their mental model is load-bearing for how they work. You can change it, but changing it is a retraining program, not a schema migration, and it should be costed as one.
The workflows with a reason behind them. Every legacy system contains steps that look redundant. Some are. Others encode a regulatory requirement, an audit finding or an incident from six years ago that nobody documented. The expensive mistake is removing one of the second kind because it looked like one of the first.
The users who cannot be disrupted. There is almost always a group — a contact center, a warehouse, a clinical team — whose throughput is the business. They can absorb change, but only at a certain rate and usually not during peak. That rate is a constraint on sequencing whether or not anyone writes it down.
The operational dependencies. The nightly batch that three downstream systems wait for. The report that goes to a regulator on the fifth working day. The reconciliation that only one person fully understands. These dictate what can be changed in what order, and they are rarely in the architecture diagram.
The constraints often rule out the clean-rewrite option within the first few weeks, which prevents the program from committing too early to an unsuitable path.
More usefully, they tend to reveal the seams — the places where the system can be split without breaking something that matters. Those seams are almost never where the architecture diagram suggests. They follow the contours of ownership, data custody and operational timing, not the module boundaries somebody drew a decade ago.
Once you can see the seams, modernization becomes a sequence of bounded moves rather than one large bet. Each move is independently valuable, independently reversible, and small enough that a bad quarter does not strand you halfway.
This discovery does not need to take months. A focused effort can cover most of the ground within a few weeks.
Talk to the people who operate the system daily rather than the people who own it — they know which steps have a reason. Trace the integrations outward until you reach something you control. Find out what breaks if each scheduled job is late, by asking rather than by testing. Read the last two years of incidents, which is the cheapest way to find the constraints nobody mentions.
Write the result down as a constraints register, with an owner and a confidence level against each item. The low- confidence ones are where the program risk is concentrated.
Starting with constraints produces a less exciting plan. There is no diagram of the target state to put on a slide in week two, and executives who wanted a transformation narrative will find the first month underwhelming.
What they get instead is a plan whose assumptions have been tested against the system as it actually is. That is worth the duller kick-off, but only if someone makes the case for it early — because the pressure to produce a target architecture in week two is real, and it is usually what derails the thing.
Explore Digital Product & Platform EngineeringTalk to our engineers