8 min read · Shelorve practice note · For CTOs, CIOs, and enterprise technology leaders
Across more than a decade of enterprise IT engagements, the same failure pattern repeats with remarkable consistency. A legacy transformation project begins with confidence. An architecture is agreed. A timeline is set. Work begins. Three months in — sometimes six — the team discovers a dependency nobody knew was there. The migration plan is wrong. The schedule slips. In the worst cases, production systems are broken in ways that take months to recover from.
The root cause is almost always the same: the team began changing systems before they fully understood what they were changing. Documentation of enterprise systems is almost universally incomplete. The systems that run enterprises were built over years, extended by people who have since left, and connected to other systems in ways that were never written down.
The undocumented dependency is the most dangerous kind. A documented dependency can be planned for. An undocumented one is discovered when it breaks. In a legacy migration, it breaks at the worst possible moment — in production, under load, during cutover — when the team is at maximum stress and minimum options.
In the environments Shelorve has scanned with Reveliq™, the average number of undocumented integrations per enterprise application is 14. The range runs from 3 to more than 40, depending on the age of the system and the number of modification cycles it has been through. Every one of these is a potential migration failure point that would not appear in a project plan built from documentation alone.
The integrations that cause the most damage are not the complex ones. They are the simple ones — a scheduled job that writes directly to a database table. A configuration file entry that points to an external service. An environment variable that holds a connection string nobody updated when the target system moved. These are invisible in documentation. They are visible in the running system.
"The dependency was always there. Nobody found it because nobody looked before they started moving."
The solution is systematic dependency discovery before any migration work begins. Not documentation review — the documentation is incomplete. Not interviews with the team — institutional memory fades. Automated analysis of the running system: codebase scanning for connection strings and API references, runtime traffic analysis that records every external call during a representative operational period, configuration file inspection, and database connection monitoring.
This multi-lens approach is important because different types of undocumented dependencies are visible in different ways. A scheduled job that writes to a database is invisible in static code analysis but visible in network traffic and database connection monitoring. A configuration file entry is visible in static analysis but might not appear in runtime traffic if the connection it references is only used under specific conditions.
When the complete dependency map exists before migration begins, the migration plan is built on reality. Undocumented integrations are identified and addressed before they become production failures. The migration sequence is designed around the actual risk profile — high-risk dependencies are migrated last, after surrounding dependencies have been stabilised, not first because they appear at the top of the architecture diagram.
Evidence-first dependency mapping adds time to the front of a migration programme — typically three to six weeks depending on the size and age of the estate. It reduces the probability of the mid-project surprises that add months. The net effect on overall programme timeline is almost always positive. More importantly, it changes what the team knows before they start, which changes every decision that follows — sequencing, risk management, stakeholder communication, and the confidence with which each phase is executed.
Start with a Reveliq™ discovery engagement. Know what is actually in your environment before deciding how to change it.