When to patch an old asset and when to replace it

I have a 2014 MacBook Pro. Apple decided it doesn't get macOS Sequoia. I patched it in one afternoon with OpenCore Legacy Patcher, a community project that installs new versions of macOS on machines Apple has abandoned: 35 minutes preparing the USB drive, another 40 on the installation, 20 applying the patch that brings back the graphics and sound drivers. It came out functional for another year, maybe two. Cost: four hours, plus the fragility of depending on a community patch that any future update can break.

📍 Meet OpenCore Legacy Patcher, the project keeping abandoned Macs alive

I'm writing this because the decision was not about the Mac. It was about how I decide when to stretch an asset and when to accept it's time to replace it. That pattern repeats in every knowledge practice: your management software, the system where you keep your clients, your contract template, the person on the team you've spent three years meaning to replace, the invoicing process that still works but weighs on you at every month's close.

The pattern

When an asset stops doing what you asked of it, there are two paths. Patch: low or zero acquisition cost, high cost in maintenance and ongoing attention. Replace: high acquisition cost, lower maintenance if the replacement is well chosen. The decision is rarely obvious, because patching always looks cheaper in the moment, and the silent cost of continuing to patch gets collected in small installments that never show up in any report.

Four questions I use to decide

1. What is the true cost of the patch, measured in your hours and your team's?

OpenCore is free. My four hours were not. If I had to pay someone who knows how to install it cleanly, the job would cost more than a new Mac mini. I did it myself because technical curiosity is also an asset. In a professional decision, curiosity doesn't count that way.

2. Does the patch solve the problem or postpone it?

My Mac is not faster after Sequoia. The 2014 processor is still a 2014 processor. What I gained was compatibility with new software. If what I needed was speed, patching was not the answer. If what I needed was to keep opening applications that only run on macOS 14 or later, it was. The question is which pain you're putting the patch on.

3. How much time does the patch buy me, realistically?

OpenCore depends on a community. Every macOS update wipes the previous patches and forces you to reapply them. The day the OpenCore team decides not to support the next macOS, my Mac falls behind without warning. If I need this Mac for two more years, accepting that fragility is reasonable. If I need it for five, it is not.

The same question works for legacy software. A process that works today with two people can be unworkable with five. The question is not whether it works now. It is whether it works in the scenario you'll be in 18 months from now.

4. What do I lose by not replacing now?

This is the question almost nobody asks. Postponing the replacement of an asset is not neutral. Every month you continue with software that got old, with a person who doesn't fit, with a process you improvise because you never documented it, you are paying a silent cost in lost hours, errors that reach the client, and opportunities you let pass because you didn't have the capacity to take them. Patching is a decision. Not replacing is one too.

When patching won

A lawyer I worked with had spent eight years running her fees in Excel. It worked. The outside pressure was to switch to professional invoicing software. We did the math: the migration would take three weeks of implementation and configuration, plus the team's learning curve. Excel took her 20 minutes a month. We decided to patch Excel: improved the formulas, left a clean template, added automatic backups. We deferred the change by two years. Time recovered: three weeks, which went into client acquisition.

It worked because the asset was not the bottleneck. Client acquisition was. Replacing the wrong asset speeds up nothing.

When I lost by patching

I took over an operation that had spent years patching its task-tracking system. Every new need was a new field, a new rule, an exception only the old team understood. I thought migrating was expensive. I held on for eight more months. In the end I migrated. The migration took two weeks. The eight months I postponed cost, adding up team confusion, errors that reached the client, and time spent explaining exceptions, far more than those two weeks.

I lost because I never asked myself the question. I was running on inertia, not on decision. By the time I reacted, I had fewer options available than if I had chosen six months earlier.

The judgment

The mistake I make most often is not patching when I should have replaced. It is not asking myself which of the two I'm doing. I keep operating because it keeps working, until one day something breaks and the decision arrives with less margin, fewer options, and worse information than if I had made it in time.

My 2014 Mac is still here. I'll use it until OpenCore stops carrying it or until I need something it can't give me. Now I know exactly at what point the math changes. That is what separates patching as a decision from patching out of inertia.

Run the numbers on the oldest asset still alive in your work: the software, the template, the process you improvise at every close. How many hours a month is it charging you to keep patching it? If you don't know the number, that is your answer.