12 min read · Shelorve practice note · For CTOs, enterprise architects, and programme leaders
Reveliq™ was built out of necessity. After a series of engagements where transformation projects hit undiscovered dependencies mid-migration — causing delays, cost overruns, and in some cases production outages — Shelorve built a platform to solve the problem systematically rather than managing the consequences case by case. The methodology has three phases: Discover, Map, and Rank.
The discovery phase is automated analysis of the application estate through multiple lenses simultaneously. Static analysis scans codebase and configuration files for connection strings, API endpoints, queue references, database names, and hardcoded IP addresses. Runtime observation monitors the running application, recording every external call and connection made during a representative operational period — typically 72 hours to two weeks, depending on batch cycle length. Network inspection captures traffic at the infrastructure level, finding integrations that application code itself does not reveal.
The multi-lens approach is critical because different types of undocumented dependencies are visible in different ways. A scheduled job that writes directly to a database table is invisible in static code analysis but visible in network traffic monitoring and database connection logs. A configuration file entry pointing to an external service is visible in static analysis but might not appear in runtime traffic if the service is only called under specific conditions — quarterly batch runs, error handling flows, or administrative functions that are rarely executed but load-bearing when they are.
This is why documentation-based discovery always misses the dependencies that matter most. The most dangerous integrations are the ones nobody thought to document — because they were added informally, because the person who built them has since left, or because they have been running reliably for so long that they are simply assumed to be part of the environment.
The mapping phase produces the dependency graph — a complete representation of every component and every connection in the application estate. Every service, every database, every API, every message queue, every file dependency, every scheduled job, every configuration-level integration. The graph explicitly distinguishes between documented dependencies (those that appear in architecture diagrams or existing documentation) and undocumented ones (those discovered only by analysis of the running system).
This distinction matters because undocumented dependencies carry a different risk profile. A documented dependency has a known owner, known behaviour, and known impact if disrupted. An undocumented one may have no owner, unknown behaviour in edge cases, and unknown downstream impact. The dependency graph makes these invisible risks visible before any migration work begins.
The ranking phase scores every dependency for migration risk on three dimensions. Blast radius — how many other components depend on this one, directly or indirectly. A component at the centre of the dependency graph has a large blast radius: disrupting it affects many downstream systems simultaneously. Criticality — what business process stops if this dependency fails. A payment processing integration is more critical than a reporting feed, even if the reporting feed has a larger blast radius. Complexity — how difficult is this dependency to replicate in the target architecture, accounting for protocol differences, data format transformations, and the availability of equivalent services in the target environment.
These scores determine migration sequence: high blast radius, high criticality dependencies are migrated last, after surrounding dependencies have been stabilised and validated. This is counterintuitive — teams often want to tackle the most complex dependencies first. The evidence-first approach says: reduce the risk surface around the complex dependencies before touching them, so that when problems do occur they are isolated rather than cascading.
"Reveliq™ does not tell you what to do. It tells you what is actually there — which changes every decision that follows."
The Reveliq™ output is a risk-ranked migration path — the sequence in which components should be migrated to minimise the probability of failure at each stage. It is accompanied by phase confidence reports that show, for each migration phase, which dependencies have been fully resolved, which remain open with mitigation plans, and what the residual risk is before go-live. This becomes the factual basis for the migration plan — not an architecture diagram built from documentation, but a migration plan built from evidence of what is actually running.
In the environments Shelorve has scanned, the average enterprise application has 14 undocumented integrations. The range runs from 3 to more than 40. Every one of them represents a migration risk that would not appear on a project plan built from documentation alone — and finding them in a three-week discovery engagement costs a fraction of finding them in month six of a live programme.
Start with a Reveliq™ discovery engagement. Know what is in your environment before you decide how to change it.