The problem
FMV-MD is VMG Health’s compensation valuation software, designed to help healthcare organizations efficiently manage physician compensation and fair market value analyses. It’s built on two decades of industry-leading physician compensation expertise. On the inside, that meant many lines of code, and a complex tech stack, making modernization a challenge. The internal estimate for the modernization work started at six months and crept up to ten months to almost a year. Not an unreasonable number for a conventional rewrite of that size, and an arduous feat for all the reasons above.
How we solved it
We delivered the platform deployment-ready in 12 weeks, with full feature parity validated by VMG Health, on a modern stack (Angular 21, NestJS, real CI/CD) that they own outright. Here are the three big decisions that made it possible:
We planned like code was cheap (because it is now). Before writing a line of migration code, AI agents produced sixteen deep audits of the legacy system, covering security, business logic, dependencies, scheduled jobs, and access control. Those audits became one master migration plan and a complete backlog of roughly 300 tickets, sequenced by risk. The plan even found eight features nobody had used in years, so we didn’t migrate them. It also mapped the security debt that builds up in any decade-old stack, all of which we fixed structurally in the new build.
AI did the typing. The migration ran on a pipeline of composable Claude Code skills that treat the legacy system as the spec. Each ticket went through the same steps: explore the legacy code and UI, derive requirements from observed behavior, write tests first, then implement. The implementing agent never saw the test files, which kept the tests honest. Our engineers reviewed at every checkpoint and every PR, spending their time on architecture and edge cases instead of boilerplate.
Humans proved it. The validation layer was deliberately old-fashioned. We pointed the new app at the same production data as the legacy system and ran side-by-side UAT with their product owner twice a week. Their own engineers built a tool that diffed old and new outputs across every record. Real production traffic was validated against the new platform before any user touched it, and cutover was gradual, behind feature flags, with config-only rollback.
VMG Health’s product owner had his reservations early in the project, but by the end, he was signing off on features himself: “It’s looking very good. I was a little bit skeptical, to be real. But now that I have seen this progress [...] it’s a very big improvement. Very, very good.”
What VMG Health got
Twelve weeks after kickoff, VMG Health had a modern secure platform at full parity with a roadmap that never froze. But the part we care most about is that VMG Health’s own engineers were shipping in the new stack with the same tools before we left.
The So What
If there’s a system like this in your company, the estimate taped to it was probably based on human thinking through and hand typing code. That’s no longer a constraint. The work that matters now is the plan and the proof, and those compress a year into a quarter.
We start every migration with a short intake sprint: you get the full migration plan, the audit findings, and the real number before committing to the whole project.
Got a rewrite that keeps not happening? Let’s talk.