When an Old Computer Sets the Clock

I was reading a warning from the company that houses the computers that run the site when one sentence stopped me cold. If a part broke, they could no longer promise they would be able to replace it.

The machines were still working. Customers were still using the product. Nothing had gone dark. But that sentence changed the situation. It was not a suggestion to tidy up something old. It was a notice that the clock had started, even if nobody could see its hands.

There is a technical name for some of the old website code, Classic ASP. It is simply an older way of building a website. That name is less important than the plain fact: it works, people use it, and it helps us serve paying customers every day.

The easy story would be that old code and old computers should be replaced together. New machines, new software, fresh start. I understand why that story sounds sensible. I have believed it before.

The first time I treated a major move as a chance to rebuild everything, it did not go the way I hoped. Work that had once moved quickly slowed to about one third of its best pace. It stayed that slow for three years. The future version kept getting built, while the current product limped along. The business got smaller during those three years.

That was not just an inconvenient project. It was a bill paid in twelve quarters of slower work and missed chances. A shiny new kitchen is not much comfort if you cannot cook dinner for three years while it is being built.

So I separated two problems that were trying to wear the same coat. One problem was urgent: the old machines might fail and no replacement part might exist. The other problem was optional: whether old website code should be rebuilt. One had a deadline set by metal and electricity. The other should be judged by what it would actually return.

The first move was to put the public web addresses behind a kind of switchboard. Think of it as keeping the same front door while changing which room is behind it. Customers can still go to the address they already know. Later, the switchboard can point them to the new machines without asking them to change anything.

That took months, not because the idea was hard to explain, but because many of those web addresses are controlled by customers. They had to be handled a few at a time. It was slow, ordinary work. But it was the work that made the eventual move safer. No mass email was needed. Nobody had to update a bookmark or figure out a new address.

The actual move has not happened yet. The old machines are still on the job, and the warning still matters. But the scariest part has been made smaller. When it is time, the customer information and the website can move to the new machines, then the switchboard can be turned toward them. From the customer’s side, the front door stays where it was.

Meanwhile, product releases have kept going out. That matters as much as the move itself. I use AI tools, software that can help keep several small tasks moving at once, so the slow, careful work can continue without swallowing the work that pays the bills. Five years ago, an urgent problem with the machines and everyday product work would have felt like a cruel choice between two important things. Now, some of it is a scheduling problem.

That does not mean the computer can make the judgment. It can help keep a list moving. It cannot decide whether a rewrite is worth three years of slower work, or whether customers should bear the risk of a rushed change. Those are human calls, because the cost belongs to people.

The useful habit here was writing down only what the old machines required. Move the public front door. Prepare the new machines. Keep customer disruption out of the plan. Everything else had to prove it belonged. A rebuild did not get to borrow urgency from a failing piece of hardware just because it sounded like progress.

The switchboard move alone took months of one-at-a-time address changes, and none of it will show up as a headline the day the machines finally switch, because the whole point was that customers never notice the front door changed at all. That quiet outcome is the actual measure of success here: the urgent problem was solved months before the hardware forced the issue, and the rebuild question still sits untouched, waiting to earn its own case.

dxdev LESSON · paste into your AI coding agent
LESSON: An urgent hardware deadline doesn't get to lend its urgency to an unrelated optional rewrite
SOURCE: dxdev.com/blog/2026-07-04_old-computer-sets-the-clock
WHAT HAPPENED: A hosting provider's warning that failed hardware parts might no longer be replaceable created a real but invisible deadline for aging servers still running production traffic on older website code. A previous attempt to treat a similar major move as an opportunity to rebuild everything from scratch had instead slowed work to roughly a third of its best pace for three years, during which the business got smaller while the rebuilt future version kept being built and the current product limped along. This time, the hardware risk, urgent, deadline set by failing physical parts, was explicitly separated from the code rewrite question, optional, to be judged on its own merits, not borrowed urgency, and the first move was putting public web addresses behind a routing layer so customers keep using the same address while the actual destination can later be switched without any customer action, work that took months specifically because many of the addresses were controlled by customers and had to be migrated individually rather than all at once. Ongoing product releases continued in parallel throughout, using AI tooling to keep smaller tasks moving so the slow, careful migration work didn't have to compete directly with work that still had to ship.
THE RULE: When one part of a system creates a genuine forced deadline, separate that specific requirement from any optional rewrite or rebuild trying to ride along under the same urgency. Write down only what the actual deadline requires; make everything else prove independently that it's worth doing rather than borrowing urgency from the thing with a real clock.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
  1. Any project justified partly by an urgent, forced deadline, hardware failure, vendor end-of-life, compliance date, that also bundles in optional scope, a rewrite, a rearchitecture, not strictly required to meet that deadline.
  2. Any migration or infrastructure move affecting customer-facing addresses or identifiers planned as a single mass cutover rather than a gradual, individually-verified migration, when the affected records are partially outside the team's own control.
  3. Any past project where rebuild-while-migrating was chosen and its actual pace or cost outcome wasn't checked and recorded before repeating the same combined approach on a new, similar deadline.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.