In 1995, I wrote a professional application called CyberTuner for Mac Classic. That same application — same core algorithms, same business logic (with improvements along the way) — still runs today on modern iOS devices, serving thousands of professionals worldwide.

It has survived: Mac Classic → Windows → Mac OS X → Windows Mobile → iOS. Four platform transitions. Five platforms. Thirty years.

Most software doesn’t survive one platform transition, let alone four. Here’s how we did it — and why the conventional wisdom (rewrite from scratch) would have killed the application years ago.

The Joel Spolsky Problem

If you’re a software engineer tasked with maintaining or porting an older codebase, you should run, not walk, to Joel Spolsky’s famous 2000 article “Things You Should Never Do, Part I.”

Spolsky wrote that rewriting from scratch is “the single worst strategic mistake that any software company can make.” He was right. But he didn’t tell you what to do instead.

I’ve spent 30 years solving that problem. But not everyone figures it out in time.

The Cost of Ignoring Legacy Systems

In December 2022, Southwest Airlines provided an $825 million lesson in what happens when you don’t maintain legacy systems. Their crew scheduling software — built in the 1990s and starved of investment for decades — collapsed under a winter storm that other airlines handled routinely. The system couldn’t match pilots and flight attendants to planes, forcing dispatchers to coordinate manually by phone. Southwest canceled 16,900 flights in ten days, stranded over 2 million passengers, and became a national punchline.

The cruel irony: their pilots’ union had warned a month earlier that they were “one thunderstorm away from a complete meltdown.” The flight attendants’ union had prioritized IT upgrades over pay raises. Management knew. They just didn’t act.

Whatever Southwest would have spent to modernize that scheduling system — $10 million? $50 million? — it would have been a rounding error compared to the $825 million they lost in a single week, plus the incalculable damage to their reputation.

Legacy systems don’t care about your budget constraints. They fail on their own schedule, usually at the worst possible moment. The question isn’t whether you can afford to modernize — it’s whether you can afford not to.

Why Rewriting Fails

“The old code is messy. Let’s rewrite it cleanly with modern best practices and a fresh start.”

I’ve heard this pitch many times. From my own team. From consultants. From well-meaning developers who just want to write “good” code. It sounds reasonable. It feels like progress. It’s a trap.

Here’s what you lose in a rewrite.

·       Decades of bug fixes — every strange-looking line of code probably fixes a real corner case you don’t remember anymore.

·       Edge cases nobody can reconstruct — that “unnecessary” bounds check prevents a crash from corrupted data. It still happens.

·       Domain expertise encoded in algorithms — that strange-looking calculation compensates for a real-world quirk that took years of empirical testing to discover.

·       Institutional knowledge that simply evaporates — you think you understand what the code does, but you don’t. Not all the subtle behaviors that users depend on.

From my own codebase: there’s a validation check that the UI already enforces. Redundant? In 2001, a corrupted preferences file bypassed the UI and the app crashed spectacularly. The validation stays. There’s a signal processing algorithm that runs slower than modern libraries. But it produces bit-identical results to the 1996 version. Users have built decades of saved data trusting those results. Changing the algorithm, even to make it “better,” would break that trust.

Every application that’s been in production for years has hundreds of these. A rewrite loses them all.

The “mess” is actually accumulated wisdom. The code has been shaped by reality — by actual users, by real-world problems, by years of “oh, we need to handle this case too.” You’d be trading tested code for untested code. And 6–12 months later, the new code will be just as “messy,” because the mess is inherent in the problem domain, not in the developers.

What to Preserve: The 80/20 Rule

After 30 years of porting, I’ve learned this: 80% of your code’s value lives in 20% of the codebase. That 20% is the business logic — algorithms, calculations, domain-specific functionality. The other 80% is UI and platform glue, and it can and should change.

Think of your application in three layers:

• UI (20% of value)                ← REWRITE THIS

  Platform-specific, dated

UI should look modern. Native to each platform. Users expect current interfaces. Don’t try to make a Windows menu bar work on a touch device.

• Business Logic (80% of value)    ← PRESERVE THIS

  Decades of refinement

Business logic should be untouched. This is your proven, debugged, field-tested code. This is where decades of refinement live. This is what users trust.

• Platform APIs                    ← ISOLATE/TRANSLATE (ABSTRACT) THIS

The platform layer needs isolation and translation (AKA abstraction). File I/O, graphics, sound, networking — these need translation layers between your business logic and the native OS APIs. Every operating system offers these services; only the APIs differ.

In my original application, the business logic was roughly 20,000 lines of C. The UI and code talking to the APIs was roughly 80,000 lines. But the value ratio is inverted. That small core is where the domain expertise, the algorithms, and the years of refinement live. Everything else is a delivery mechanism. Of course, there are many more lines now because systems are more complex, but the 80/20 rule still holds true.

The Methodology

Over 30 years and 5 platforms, I’ve refined this approach into repeatable steps.

Step 1: Assess and Separate. Before touching the new platform, work in the OLD environment while it still compiles. Pull business logic out of UI code. Every calculation, every validation, every domain rule should be callable through a clean function interface. This feels like you’re not making progress on the port. You’re making the actual port 10X easier.

Step 2: Design the New Interface. Build the UI on the new platform. It doesn’t have to do anything yet — wire it to dummy functions that return fake data. Follow platform conventions. Use native controls. Users expect a modern interface, and this is your chance to improve the experience while keeping proven logic underneath.

One caution: users migrating from the old platform need to get oriented quickly. Keep major workflow changes to what’s necessary for the new platform’s conventions. Up to about 30% change is manageable. Beyond 50%, you’re requiring significant retraining — and that user familiarity is almost as valuable as your engine’s domain knowledge.

Step 3: Port the Business Engine. If your engine is in a portable language like C, this is mostly mechanical — set up the build system, include the files, fix compiler errors. If you need to translate between languages, use the black-box method: capture thousands of input/output pairs from the old system, translate the code, run the same inputs through the new version, and verify identical outputs. You don’t need to understand every line if you can prove the translation produces the same results.

Step 4: Build the Compatibility Layer. Connect your engine to the new OS. File systems, networking, graphics primitives, and sound I/O exist on every platform — only the APIs differ. Your compatibility layer translates between your engine’s expectations and the new platform’s interfaces. Sometimes one component needs fully native code for performance. Fine — rewrite that part, but keep the business logic above it untouched.

Step 5: Black-Box Validation. Before you ship, prove the new version works identically to the old. Capture hundreds or thousands of real-world test cases — inputs, outputs, file processing results, edge cases, boundary conditions. Run them through the new version. For numerical calculations, do byte-level comparison where possible. Investigate every difference: is it a bug in the port, a harmless platform difference, or an actual improvement? This step is tedious. It’s also the most important.

Step 6: Beta Testing. Line up 20 to 50 beta testers who used the old version. Give them free copies if you have to. Nothing validates a port like real users comparing old behavior to new, and modern platforms will feed you crash reports automatically.

Step 7: Connect and Ship. Wire the new UI to the preserved engine through your clean APIs. If you did Step 1 well, this is straightforward — the UI calls engine functions, the engine returns results, the UI displays them. Neither side knows or cares how the other works. Then polish: performance, UI refinements, documentation. Ship.

Subsequent ports are dramatically faster because you’re reusing the compatibility layer and the engine. On my second, third and fourth platform transitions, the engine ported directly with very little change — only the UI and platform layer needed work.

While my examples come from a specialized domain, this methodology generalizes to any legacy system — financial, logistics, healthcare, defense. If there's valuable business logic trapped inside an aging interface, the approach is the same. The domain doesn't matter. The architecture does.

Common Pitfalls

Inadequate separation. If business logic is tangled with UI code, you end up porting everything. Separate first, port second — even if it takes weeks in the old environment. This work pays off immediately.

Skipping the feedback loop. Your beta testers will find things you never imagined. Don't just collect their feedback — act on it, fix it, and send it back to them. Repeat until they stop finding problems. This cycle is where quality lives.

Making “improvements” during the port. Power users will expect you to improve the engine while your hands are greasy. Resist. Freeze the engine during the port. You won’t be able to distinguish between bugs you introduced by changing the engine and bugs caused by the platform change. Even most “bugs” you discover should be preserved unless they’re crashes — some external process may be expecting that behavior.

Ignoring platform strengths. Don’t make the new version a pixel-perfect replica of the old. Your new platform has capabilities the old one didn’t — touch interfaces, cloud sync, better graphics, notifications. The business logic stays preserved while the experience improves. That’s the whole point.

The Long View — And What Just Changed

Software is expensive to build but even more expensive to rebuild. The accumulated wisdom in working code — the edge cases, the bug fixes, the domain expertise — is irreplaceable.

When platforms change (and they always do), the temptation is to start fresh. To use the new shiny framework. To write “clean” code.

Resist that temptation.

Most of the apps that were around 30 years ago have disappeared — probably 99% are gone. They rewrote, introduced bugs, lost customers, and eventually failed. Their software died with the platforms it was built for. And the ones that didn’t rewrite? Many became Southwest Airlines — ignoring the warnings, starving the systems of investment, waiting for the storm that would expose what they already knew was fragile.

There’s a third path:

Preserve what works. Modernize what the user sees. Isolate and translate what’s platform-specific.

Joel Spolsky told you what not to do. This article is what to do instead.

But I need to tell you what happened next,because it changes the calculus of everything I just described.

Shortly after writing this article, I put the methodology to the test one more time — the most ambitious modernization my application has ever undergone. In roughly three months, working as a single senior developer with AI-assisted development tools, I completed all of the following:

•      Replaced a decade-old cryptographic security library with its modern successor

•      Rebuilt the entire graphics rendering pipeline on a current framework

•      Internationalized over 700 interface files, preparing the application for release in 23 languages

•      Constructed a complete cloud synchronization system with conflict resolution and merge handling

•      Built a domain-specific AI support assistant, trained and validated to 97% accuracy

•      Updated every interface component to current platform standards

Any one of these would have been three to six months of work under previous methods. Together, they represent what I’d estimate as two to three years of traditional development effort.

The methodology in this article didn’t change. The separation of business logic from UI, the compatibility layers, the black-box validation — all of that still applies, exactly as described. What changed is the speed at which an experienced engineer can execute each step. The tedious, mechanical parts of porting — syntax translation, API migration, interface file generation — are precisely the tasks that AI tools accelerate most dramatically.

Here’s what this means for your legacy system: the project that was quoted at two years and $4 million three years ago? The methodology is the same, but the economics are different now. Modernization efforts that were previously impossible for small teams are suddenly feasible. Software that wasn’t worth porting is now worth porting. Systems that were too expensive to internationalize can reach global markets.

The playbook hasn’t changed. The speed of execution has.

CyberTuner is still here. Still growing. Still competitive. Not because the code is “clean” or “modern,” but because the core logic works — and in thirty years, I never threw that away. I just got a lot faster at everything around it.

About the Author

Dean Reyburn is co-founder of Reyburn Engineering, Inc. and creator of CyberTuner, a professional piano tuning application that has survived Mac Classic → Windows → Mac OS X → Windows Mobile → iOS — five operating systems over thirty years. Reyburn Engineering specializes in legacy application modernization. Dean holds four U.S. patents in piano technology.

reyburnengineering.com

* The Ship of Theseus is an ancient Greek thought experiment: if you replace every plank in a ship one at a time, is it still the same ship? Philosophers have debated this for 2,500 years. Software engineers face the same question every time they maintain a legacy codebase. Our answer: yes — as long as you preserve what makes it the ship!