Why We Put a Switchboard in Front of Every Customer Web Address

The company that houses the computers running our site sent a warning, and one sentence in it stopped us 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.

Some of the site runs on an older way of building a website. That matters less than the plain fact: it works, people use it, and it helps us serve paying customers every day.

The rebuild we already paid for

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

The first time we treated a major move as a chance to rebuild everything, it did not go the way we 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 an inconvenient project, and it was also 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.

Two problems wearing one coat

So we separated two problems that were trying to wear the same coat. One was urgent: the old machines might fail and no replacement part might exist. The other was optional: whether the 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 switchboard

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.

The idea was easy to explain, but the work took months, 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, and it was the work that made the eventual move safer. No mass email was needed. Nobody had to update a bookmark or learn a new address.

The move itself 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.

Keeping the paid work moving

Meanwhile, product releases have kept going out. That matters as much as the move itself. We 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 makes 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 calls belong to us, because the cost lands on people.

What went on the list

We wrote 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.

None of this will show up as a headline the day the machines finally switch, because the whole point is that customers never notice the front door changed. 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. A rewrite gets judged on its own return, and the one we tried earlier cost three years of slower work.

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/everyday-ai/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). 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. That work 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.