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.

Next, make a heatmap. 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.

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.