← All posts
Process

Migrating off legacy software without breaking the business that runs on it

Tribal Health's scheduling, onboarding, and billing all ran on a Salesforce setup nobody wanted to touch, for the obvious reason: touching it was how you broke payroll. Here's how a four-month migration survived that fear.

When we took on modernizing Tribal Health's operations, the legacy Salesforce setup was expensive, slow, and universally disliked, and also the thing every paycheck, every shift assignment, and every onboarding flow quietly depended on. Nobody disputed that it needed to go. Everybody was afraid, reasonably, of what happened in the gap between turning it off and the new platform being fully trustworthy.

The real risk was never the destination

Migration projects get planned like the risk is "will the new system work." In practice, the new system working in isolation is the easy 80%. The dangerous 20% is the weeks or months where both systems are partially true at once, where a schedule change made in the old system hasn't propagated to the new one yet, or a user's record exists in both places with two different answers to the same question. That gap is where a healthcare staffing business can genuinely hurt real people: a shift that doesn't get covered, a credential that doesn't carry over correctly.

Nobody's business breaks because the new platform is bad. It breaks because for a while, there are two sources of truth, and nobody agreed in advance which one wins.

What actually made the four months survivable

  • One explicit source of truth at every point in the migration, written down and communicated to the whole operations team. Never "check both systems," always a specific, named answer for which one was authoritative that week.
  • Migrating by function, not by date. Scheduling moved as a complete, tested unit before onboarding started moving, rather than a single flag-day cutover across everything at once.
  • A rollback plan for each function, treated as seriously as the migration plan itself, not a footnote but a tested path back to the old system if the new one's early weeks surfaced a problem we hadn't caught.
  • The operations team in the room from week one, not informed after the fact. They were the ones who'd notice a scheduling edge case the migration plan hadn't considered, long before it reached a real shift.
In practice

The migration took four months and shipped AI-powered scheduling, onboarding, and a resume parser on the new platform, saving roughly $800k a year, with task completion rising from 31% to 68%, without a single week where payroll or shift coverage broke.

What I'd check before any legacy migration now

Not "is the new system ready." Ask instead: for every single day of the migration, can everyone on the operations team answer, without checking two places, which system is the truth right now? If that answer is ever fuzzy, the migration plan isn't finished yet, no matter how solid the new platform is in isolation.