Enterprise Platform Migration

Platform architecture before and after migration to the unified AI-powered system

Enterprise clients migrated with zero regression and full feature parity at every go-live

200+

Postman API test runs automated via Claude Code to validate outputs against the legacy system

>90%

Output match rate achieved before any client cutover, catching critical blockers in testing not production

Context

Tractable's early architecture had grown organically, with individual product features built in silos by separate teams. Each branch of the platform had its own independent codebase and team, which meant duplicated effort, high operational cost, and limited ability to move quickly as the product scaled. A strategic decision was made to scrap the legacy architecture and rebuild on a unified modern platform: smaller team footprint, lower cost, and the ability to improve on the structural shortcomings of the previous system rather than just replicating them. The new platform needed full feature parity with everything enterprise clients were already relying on, with no disruption to live operations during the transition.

Problem

Enterprise insurance clients run 24/7 claims operations. A migration touching their integration layer, data flows, or configuration model isn't a routine deployment. The stakes are high on both sides.

Every client had a different legacy setup, risk tolerance, and go-live timeline.
Downtime or feature regression could cascade into financial and reputational damage for both the client and Tractable.
No single playbook worked across all of them. Each migration needed individual treatment.
Aligning clients, engineering, and internal ops simultaneously, across multiple concurrent migrations, with no room for error.

Approach

Started with discovery: understood how clients actually used the legacy system

Ran discovery calls with CSMs and directly with clients to understand day-to-day workflows on the legacy platform. This wasn't a documentation exercise. It was about knowing what "feature parity" actually meant in practice for each client before writing a single requirement.

Wrote per-client PRDs: one spec per migration, not one spec for all

Each client had distinct integration touchpoints and configuration dependencies. A single generic PRD would have missed the edges that matter most. Writing per-client specs meant engineering had clear, testable requirements and clients had an agreed definition of done before any code changed.

Stayed embedded in engineering delivery throughout

Joined daily scrums, helped unblock dependency issues as they surfaced, and kept coordination flowing across backend and data infrastructure. Requirements ambiguity resolved the same day rather than accumulating into sprint-end surprises.

Personally owned UAT and API testing, then automated it

Ran UAT to validate business workflows and used Postman to compare API outputs between the old and new system for each client. Automated over 200 test runs using Claude Code, which made the process significantly faster and raised the confidence level before any cutover decision. Achieved a greater than 90% output match rate, catching critical blockers in testing rather than in production.

Designed and executed phased cutover with shadow mode transitions

Owned the cutover strategy for each client: phased rollouts with explicit rollback gates and shadow mode periods where the new platform ran alongside the legacy system before full switch-over. Every client went live with zero downtime. The rollback gate isn't pessimism. It's the thing that lets you move fast with confidence.

Learnings & Closing Words

Each enterprise client is its own migration. A shared playbook helps with process, but the requirements, risk tolerance, and go-live conditions need to be scoped per client. Treating them as interchangeable is where feature gaps appear.
Automating test runs changed the quality of pre-cutover confidence. 200+ Postman runs via Claude Code meant we went into each go-live with data, not just optimism. Finding a critical blocker in testing is a good day; finding it in production is not.
The rollback gate lets you move faster, not slower. Every stakeholder relaxes when they know abort is clean and safe, and that confidence is what keeps timelines from slipping due to last-minute hesitation.

Five clients migrated. Zero regressions at go-live.