Modernizing a Decade-Old Scheduling System Without Taking It Offline

Customer context

BrightPath operates an outpatient care network managing scheduling and referrals across multiple clinics, running on a scheduling system that had gone essentially unmodified for over a decade.

The challenge

The scheduling system was business-critical and poorly documented, built on aging technology that made it difficult to hire or retain engineers confident enough to modify it safely. A full rewrite was tempting on paper but carried real risk: any disruption to scheduling would directly affect patient care across BrightPath's clinic network.

Requirements

• Zero disruption to active operations

  Clinic scheduling could not go down or behave unpredictably during modernization.

• Preserve undocumented behavior

  Years of edge-case handling existed in the system with no written record of why.

• Improve long-term maintainability

  The end state needed to be a system BrightPath's team could confidently extend.

• No single high-risk cutover

  Leadership was explicit that a big-bang rewrite and switchover was not acceptable given the stakes.

Discovery

Before writing any new code, we spent several weeks building a behavioral test suite directly against the live legacy system's actual outputs — not its documentation, which was sparse and partly outdated, but its real behavior across a wide range of scheduling scenarios, including edge cases BrightPath's staff flagged as important but unusual. This became the safety net for everything that followed.

Solution

We modernized incrementally using the strangler pattern: extracting well-defined functionality — starting with core appointment booking logic — behind a stable API that matched the legacy system's external behavior exactly, verified against the behavioral test suite, then gradually migrating callers to the new implementation while the legacy system kept running throughout.

Technical architecture

A routing layer sits in front of both the legacy system and the newly built components, directing each type of request to whichever implementation currently owns that functionality. As each piece of functionality was extracted, rebuilt, and verified against the behavioral test suite, the routing layer was updated to send that traffic to the new implementation — with the ability to route back to the legacy system immediately if anything unexpected surfaced.

Implementation approach

We extracted and migrated one bounded piece of functionality at a time, starting with appointment booking — chosen because it was both high-value and well-covered by the behavioral test suite — validating thoroughly in a staging environment against real historical data before ever routing live traffic to the new implementation. Each migration was a small, reversible step rather than a large, hard-to-undo one.

Key features

• Behavior-preserving test suite

  Built against actual legacy system behavior before any modernization began.

• Incremental extraction

  Functionality moved to the modern stack piece by piece, not in one cutover.

• Stable API contract

  New implementation matches legacy external behavior, so callers don't need to change.

• Zero-downtime migration

  Clinic operations continued uninterrupted throughout the modernization.

Integrations

• Existing patient records system

  Modernized components maintain the same integration contract as the legacy system.

• Clinic scheduling workflows

  No disruption to staff-facing scheduling tools during migration.

Challenges & decisions

The most consequential decision was resisting pressure to move faster by skipping the upfront behavioral test suite investment. It added real time before any visible modernization progress, which was a hard sell initially — but it's what made every subsequent migration step safe to verify and safe to roll back, and BrightPath's leadership came to see it as the reason the migration had zero patient-facing incidents.

Representative outcomes

Technology stack

In their words

Related services