Ship of Theseus - Recipe for Healthcare IT Modernization

There’s a paradox that every healthcare CTO eventually meets — the Ship of Theseus.

If you replace every plank of a ship until none of the original wood remains, is it still the same ship?

I’ve been haunted by that question for years, because modernization — whether of a system, a product, or a company — is just that: rebuilding while staying afloat.

In healthcare IT, that isn’t just philosophy, it’s our daily paradox. We replace brittle integrations, outdated APIs, and legacy workflows plank by plank, trying to keep the ship afloat while honoring the mission that started it all.

Every healthcare organization carries a core identity that outlives any technology stack — compassion, trust, and the promise of care. The systems change, the teams evolve, the funding fluctuates, but the soul remains. Our work as technologists is to protect that soul while renewing every plank that holds it up. That’s why the strangler fig pattern still feels like the most humane approach to modernization. It’s slow, deliberate, and deeply respectful of continuity.

Over the years, I’ve seen the same story play out across organizations: everyone wants the future, but no one wants to pause the present. The intention is there, support builds, roadmaps are drawn — until patience runs out or budgets tighten. That’s where the strangler pattern becomes not just a technical strategy, but an emotional one. It gives leadership a way to see progress without panic, to replace systems side by side rather than all at once. It’s modernization by evolution, not revolution.

And then there are the quiet guardians — QA engineers, DBAs, DevOps, SREs, security and data folks — the plumbers and electricians of our digital world. They are the ones who keep the lights on while we change the wiring, who make modernization survivable.

The healthiest modernization efforts I’ve seen don’t start with a cloud migration or a shiny new diagram. They start with clarity and humility. You begin by listening with your eyes. Watch real users struggle before automating anything. Be the ethnographer on day one — quiet, curious, present. As Steve Blank says, get out of the building. Sit with billers, nurses, and care coordinators, not just your Slack channel. Sitting in a basement speculating on a Miro board in a committee isn’t how good software is born. Listen to the users before you go guns blazing on a cure.

Then you map what exists. Architecture is archaeology before it’s art. Draw what’s actually there, not what you wish was there. And while you’re at it, check the bus factor. Do you have to blow up an engineer’s RV trip to fix an insurance claim issue? Are there modules only one person understands? Admire the heroes, but don’t architect around them. Uncover that risk in the first 30 days so you can design redundancy before the radar goes dark.

Write the tests first. Make the code confess.

One thing I’m genuinely excited to explore in my next modernization journey is this: most legacy systems don’t fail because the code is old. They fail because the intention is lost. Documentation is missing, tribal knowledge has evaporated, and everyone is afraid to touch the module that “somehow works.”

So before I strangle anything, I want to do what the legacy code playbook teaches: write tests first to prove the current behavior. Not perfect unit tests that require a rewrite to even exist — I mean practical system integration tests and functional pathway tests that represent how the business actually uses the software today. These tests become the new documentation. They give you a stable baseline. They turn mystery into something measurable.

Then you modernize like TDD, but at the system level: write the stable pathway tests first, then refactor and swap planks while keeping coverage intact. If you have A/B deployments, feature flags, or any form of controlled rollout, even better — test the new module on a small slice of users before you bless the whole fleet. That’s how you modernize without waking up to a support wildfire.

And honestly, the new AI tools make this feel less daunting. I’m excited about using tools like Codex or Claude Code to accelerate the creation of solid integration tests and build coverage before swapping modules. The real work isn’t typing the tests — it’s choosing where to start.

My hunch is you already know. Your JIRA “swiss cheese” heatmap is basically the system telling you where it hurts. Start there. Those fragile modules are already irritating your customers. Use modernization not just to replace technology, but to stabilize trust while you modernize.

Let data — not politics — reveal where friction lives. Study your JIRA tickets since inception. They already tell you why the system looks like Swiss cheese. Every bug, workaround, patch script, and “temporary fix” is an artifact of where the system cracked under real-world use. That’s your modernization backlog, unfiltered.

Once you’ve done this, something interesting happens. The fear drops. The system stops feeling fragile and starts feeling observable. You’re no longer guessing what might break — you’ve captured the intent in tests, and the code has finally told you the truth.

And that’s when the data becomes useful.

At that point, your JIRA history stops being noise and starts acting like a map. The swiss-cheese pattern isn’t just technical debt anymore; it’s a prioritization signal. It tells you which modules are already brittle, already annoying users, already eroding trust. Those are the planks worth replacing first — not because they’re old, but because the system itself is asking for help.

Then strangle gently. Build new next to old until users prefer the new one naturally. And when new projects arrive, don’t keep bolting them onto the old codebase just because it’s convenient. Co-exist with intent. Design a bridge, a transition path, a shared service — something that avoids running two divergent products forever. Think harder about the middle path of co-existence now, so it doesn’t become impossible later.

Finally, cut over when it’s boring. If release day still feels heroic, you’re not ready. Modernization, done right, feels calm, not cinematic. Good engineering should look boring from the outside — no heroics allowed.

And let’s be honest, good intentions don’t pay for pipelines. Modernization without money is theater. Without investing in observability, automation, security, and the humans who keep things stable, you’re just repainting the hull while the rot spreads beneath. Healthcare transformation requires real financial scaffolding — funding that supports the people who safeguard data, uptime, and compliance while the change unfolds. It’s not glamorous, but it’s the most ethical use of budget there is.

If you’ve read this far, chances are your ship already needs a few new planks. Don’t overcomplicate the starting line. Pull your JIRA data. Look at five years of tickets. They’re your X-ray, a record of recurring pain points and design debt. Draw your dependency map. One sheet of paper, one box per subsystem, arrows for integrations. You’ll instantly see the knots that slow every release and the orphans no one maintains anymore. Then shadow your users. Spend an hour watching a nurse, biller, or care coordinator use your product. Don’t ask them to explain — observe. The quiet moments of frustration reveal more than any spec doc ever could.

Do that, and by the end of the week you’ll know exactly where the ship leaks, which planks rot fastest, and where new growth should begin. That’s how every meaningful modernization starts — not with a strategy deck, but with a flashlight, curiosity, and the humility to listen.

Healthcare is complex, but there is a method to the madness. You stare at it long enough and your brain eventually says, “Ah, I see you, trouble — ha!” And because most of the protocols we still lean on — HL7, EDI, HEDIS — were invented in the 1970s and 1980s and are still very much alive, it’s cheaper to think longer than to redo the project twice. So slow the heck down, change the plank right, and sail the ship for the next decade without living under a permanent duct-tape deluge.