AI-Assisted Migration of a Broker Exposure Limits Service

A top-10 global asset manager needed to move a decade-old trading limits and alerting service off ageing on-premises infrastructure without interrupting the live broker exposure monitoring its trading desk relied on every day. The modernized service is now live in production.

The complexity was in the service's shape, not its size: about 23,000 lines of code, mostly Java, with embedded SQL, XML configuration, a browser console and deployment scripts. It exposed two live protocols at once — an HTTP admin API of about 20 endpoints and a proprietary socket protocol carrying more than 30 message formats to a desktop client — and depended on a database, a directory service and outbound mail.

The client asked Findev to move the service to its strategic AWS EKS environment, keep both protocols working for the desk and its desktop client, and produce evidence that the service still behaved as before — for a service that had no automated tests to start from.

Problem

The service had grown across two technology generations: a modern framework layered over legacy wiring, configuration spread across 28 files and an outdated Java 8 runtime. Moving it meant untangling how it started and was configured, not just repackaging it.

The trading desk reached the service through a desktop client that spoke a proprietary socket protocol, documented nowhere. The target platform routed only web traffic, so a service moved as-is would have been unreachable from the desk.

And nothing captured how the service was supposed to behave: with no automated test suite, there was no way to prove it still worked the same after the move.

Solution

Findev applied its proven AI-assisted engine, phase by phase, adapted to a service whose trading desk connected over a proprietary socket protocol:

• App Assessment — Complexity Meter: we scored complexity and start readiness across the codebase, configuration, pipeline and integrations. The output was a scorecard and nine evidence-backed migration risks, led by the hybrid runtime, the missing tests and the operational dependencies.
• Knowledge Discovery — Discovery Agent: we reconstructed the service's behavior and message flows from the implementation, turning them into behavior documentation for a service known only to its code and a handful of engineers.
• Test Generation — Test Forge: starting from zero automated coverage, generated a regression test pack covering every interface the service exposes. Its baseline was recorded against the running pre-migration service on real reference data — nearly 300 exposure limits across more than 700 broker codes — making actual behavior, not assumed behavior, the standard the migration had to meet.
• Modernization: replaced the 28-file property chain with one base configuration and five environment overlays, reworked startup into framework-native configuration, upgraded the runtime and the socket stack, and built a bridge that lets the desktop client's proprietary protocol reach the service on the new platform.
• Deployment: deployed the service to the client's AWS EKS environment, ran it side by side with the on-premises instance, and cut over to production only once both held the same brokers, limits and configuration — the reference data that decides whether a trade breaches a limit.

Run in beta across every broker code on production-matched data, the pack exposed tests that could pass without proving the right answer. Each was tied to a verdict known from production (within limit or in breach), and Test Forge added the rule to its own rule set; it now rejects such tests automatically. The engine hardens itself this way with every delivery.