Modernizing Legacy Investment Logic with Claude: A 70% Reduction in Debug Downtime

The Client:

The Performance Report Engine had calculated investment returns for asset management clients for more than twenty years, running on Visual FoxPro, a language Microsoft stopped supporting in 2010.

The Engagement:

SSI’s engineering team used Claude and Claude Code to migrate the engine to C#, but only after a direct, cold conversion attempt failed outright.

What worked instead was a three-stage blueprint built in-house: seed the pattern by hand, expose the legacy system’s hidden middleware, then scale the conversion with AI. That blueprint was tested against two real production defects before it was trusted at scale.

The Challenge:

Every quarter, asset managers on the platform send their clients a report built from numbers that have to be right: returns, corporate action adjustments, tax lot detail, the kind of figures that get read closely and trusted without question. Behind that report sat a piece of software most of its users never thought about, the Performance Report Engine, which had been producing those numbers for more than twenty years.

It was built in Visual FoxPro, a language that made sense when the engine was written and hasn’t made sense for a long time since. Microsoft stopped supporting it in 2010. The developers who understood it best had largely moved on. And yet the engine kept running, quarter after quarter, because nobody could afford to get it wrong, and nobody could afford to touch it either.

The engine wasn’t just old. It was opaque in the specific way legacy financial software tends to be. Over 200,000 lines of business logic sat spread across dozens of procedural files, with SQL strings embedded directly into the calculation code and no unit tests to catch a broken assumption. Table aliases shifted at runtime. Scoping rules lived in the programmer’s head, not in the code. None of it had a compiler to lean on.

What made it genuinely dangerous wasn’t the age of the code. It was what a mistake would look like. Internal rate of return, time-weighted return, and lot-level tax accounting all come loaded with edge cases, and a missed one doesn’t crash the program.

It just quietly prints the wrong number on a report a client reads as fact. A manual, line-by-line rewrite was estimated at five or more years at full team capacity.

The Solution:

SSI’s engineering team brought in Claude and Claude Code to take on the rewrite, and the first attempt was the obvious one: hand over the VFP source and ask for a complete C# conversion in a single pass.

It didn’t produce working code. The engine was too large and too interdependent for a cold conversion, and VFP’s implicit scoping, macros, and dynamic aliases had no direct translation into C#. There was no target architecture for the model to build against, so it had nothing solid to reason from.

The failure wasn’t a sign that AI couldn’t do the work. It was a sign that AI needed something to build against, a proven pattern and a real foundation, not a blank page.

So the team stopped trying to convert the engine in one motion and engineered the migration itself. What came out of that is the solution blueprint SSI now applies to legacy modernization work more broadly.

Every file produced under this blueprint could be checked directly against the original VFP reference rather than trusted on faith. That verification step is what let the team scale the migration with confidence instead of hoping it held.

Two defects surfaced during testing, and both showed whether the blueprint could hold up against the kind of quiet, high-stakes bugs that legacy financial logic tends to hide.

The first was a portfolio that had exchanged shares in a corporate merger. The old VFP report marked that line “Exchanged in Merger” where a return figure should have been. The new C# version came back blank. Claude traced the gap to a routine that had converted its numeric calculation but never carried over the special-case annotation logic behind it.

The second only showed up on newer portfolios. A holding bought partway through a month, with no starting value, should have produced a clean return for the full period. The fix that held checked the length of the reporting period itself, rather than the account balance, and the corrected number matched the VFP reference exactly.

Both fixes held under real production pressure. That confidence is what let the team scale the blueprint across the rest of the engine, corporate actions included.

The Impact:

The engine that emerged calculates the same figures its clients have relied on for years, now on code that can be tested, typed, and read by the next developer who needs to.

12,991 – Lines of Production C# Delivered

32 – Legacy Files Fully Migrated

70% Reduction in Debug Downtime

16 Commits to Ship the Engine

Zero manual line-by-line legacy reads were needed once the blueprint was established at scale.

Two production-critical defects were caught and resolved before they reached a client.

A reusable migration skill is now in place, so every issue since has been solved faster than the last.

The Performance Report Engine now runs in production on modern, typed, testable C#, verified line by line against the system it replaced.