Every established company has one. The system nobody dares touch.
At one client, billing ran on software written by a man named Dave. Dave left in 2019. The documentation was Dave. There was a server in a closet with a sticky note on it that said, in fading marker, "DO NOT RESTART."
Nobody knew what would happen if you restarted it. Nobody wanted to find out. So the company's revenue flowed, daily, through a machine protected primarily by a Post-it and a prayer.
If you have a Dave system — and if your company is more than ten years old, you do — this post is the conversation everyone's been avoiding.
Must Read: Fixed-Price vs Hourly Software Development: Who Pays for Surprises?
Why "leave it alone" feels safe and isn't
The logic sounds reasonable: it works, touching it is risky, so don't touch it. Here's the accounting error in that logic — you're not avoiding the risk. You're paying it in installments.
Every year the Dave system runs untouched:
- The eventual migration gets harder, because more of the business grows roots into its quirks.
- Hiring gets worse, because you're recruiting for a technology stack whose other fans are mostly retired.
- The odds of an unplanned failure quietly rise — and an unplanned failure gets to choose its own timing. It will not choose a quiet Tuesday in March. It will choose renewal season.
- The people who half-understand it get closer to their own retirement parties.
"Safe status quo" versus "risky modernization" was never the real choice. The real choice is planned change on your schedule, or unplanned change on the system's.
How modernization works without stopping the business
Here's the part that unclenches most executives: nobody serious rips out a load-bearing system in one weekend. That's the disaster-movie version, and it's how modernization got its scary reputation.
The grown-up version works like roadworks: you don't demolish the bridge while cars are on it. You build the new lane alongside, shift traffic over gradually, and only tear down the old lane when it's carrying nothing.
In practice:
- Map what the old system actually does. Not what the 2011 spec said — what it does today, including the weird parts everyone works around. This step alone is worth the price; most companies discover they don't fully know.
- Build the replacement for one function first. The most painful or riskiest piece. The new system runs alongside the old one.
- Shift that traffic over, verify, repeat. Piece by piece, with the old system as the safety net the whole way.
- Retire the old system last — when it's carrying nothing, and the sticky note can finally come off the server.
At no point does the business stop. At no point is there a heroic cutover weekend. Boring, incremental, reversible — which in this line of work are the three most beautiful words in the language.
Signs it's time (a quick self-check)
- Only one person (or zero people) truly understands it.
- "We can't do that, the system won't allow it" is shaping business decisions.
- Compliance or security questions get answered with nervous laughter.
- Integration requests from customers or partners keep getting declined.
- There is, anywhere in your building, a sticky note that says DO NOT RESTART.
Two or more of those, and the conversation is overdue.
What to ask a modernization partner
The vetting rules are the same as any serious build — named senior ownership, real discovery, fixed scope in writing — plus two specific to this work: "Walk me through how the old and new systems run side by side" (if their plan is a big-bang cutover, keep looking) and "What's your rollback story at each stage?" The right partner talks about safety nets more than features.
The short version
The untouchable system isn't safe — it's risk on layaway, and it picks its own due date. Modernization done properly is the least dramatic project you'll ever run: map it, replace one piece at a time alongside the old, keep a rollback at every step, and retire Dave's masterpiece with honors when it's carrying nothing.
Got a Dave system of your own? Tell us about it — we'll give you an honest read on where we'd start and what it'd take. The sticky note stays on until then. No pitch.
Must Read: In-House Team vs. a Healthcare Software Development Partner
Blogs:
Explore all blog
