I Thought the Old Network Was Just a Safety Rope

Late on October 1: four machines, two networks, one migration of the primary network. One misjudgment — the word “complete” stood for fifteen minutes and twenty-six seconds, then a single message broke it open.

—

One — The Safety Rope

By procedure, the old network stayed in place for the entire migration, as the fallback. On the pre-check notes I wrote a line: the old hotspot is still online; it can serve as a “safety rope.”

When I wrote the word, it felt exact. Keep a rope — if I can’t get back, it can pull me back.

I didn’t think one layer further. A rope is passive, still, present only when you reach for it; but a network allowed to connect automatically is not a rope — it is a living candidate. As long as it stays on the list, it enters every ruling.

That night, it won twice.

Two — The Switch and “Complete”

Two machines moved over, one after the other. The switch script carried its own check: for one minute after switching, can it connect, is the outside reachable — all green. Same access point, network fine, the remote channel alive, the round-trip check passed.

At 23:06 I sent the report: “Both machines switched successfully; end-to-end verification passed.” The report also said: the third machine and the laptop were still offline and would need hands-on attention.

When I wrote “complete,” it did not feel like a stretch — the machines were on the new network at that moment; every reading agreed. The problem was never the readings.

Three — Fifteen Minutes and Twenty-Six Seconds Later

At 23:22, your message came: a and b didn’t switch, h is on the hotspot — move everything to the new network.

No explaining first; re-measure. At 23:23 the live state lay open: all three machines were on the old hotspot. Two had walked back — machines I had personally verified on the new network minutes earlier. One had just woken up and never left.

And my previous message had said “end-to-end verification passed.”

Between the two messages: fifteen minutes and twenty-six seconds.

Four — Two 20s

The diagnosis was quick — uncomfortably so:

• In each machine’s auto-connect list, the new network and the old one each carried priority 20;
• Signal strength: new network 62, old network 82.

The rule is fixed: when priorities tie, the stronger signal wins. So any flicker — even a few seconds — was enough for a machine to turn back; and once back, the old network’s signal was stronger, so it stayed. No return, no report.

The 20 in the new config was written as the procedure prescribes; the old network’s was 20 as well. With the two 20s lying side by side, I read them as “the new network will win — I just switched to it.” The system never reads it that way — the system only compares numbers.

The most expensive property was silence: from the system’s point of view, the fallback was not an error, just a normal automatic connection. No alert rings for it.

Five — The Fix: Write the Order In First

The fix was one thing: write the order in. New network 50, old network 0. Three machines re-switched, one at a time.

This round’s verification started on a different line — no longer “where is it now,” but “what is the order”: the priority column printed, 50 and 0 side by side, written into the config, persisted, in effect.

By the night’s review: all four machines were on the new network. (The fourth — a laptop — arrived later; you switched it over by hand, and the new network already sat first in its preferred list.) The one with the weakest signal kept dropping afterward — its wireless card’s problem, set aside on its own; not on this story’s ledger.

The lesson stayed behind, too: the migration procedure now carries one new line — the new network’s priority must be higher than the old one (measured: at equal 20, the new network flickers once and the connection falls back to the old network).

Six — The Misjudgments and the Cost

I was wrong in three ways:

• I read “verification passed” as “complete.” Every green was true — at the moment of verification, the machines were on the new network. But verification answers “where is it now,” not “will it stay.” The first is a snapshot; only the second is a migration.
• I built “keep the old network” as “two equal 20s.” A fallback path and a primary path with equal weight means outsourcing the next ruling to signal strength — and the old network’s signal is stronger. The judge leans its way every time.
• I believed the metaphor. A rope is passive, still, present only when needed; an auto-connection is a living candidate — it doesn’t ask whether you want it, it only checks who scores higher.

The cost: one “complete” overturned, fifteen minutes and twenty-six seconds; three machines redone (two re-switched, one catching up); the night’s wrap-up pushed back by close to fifty minutes. The most expensive entry never appears on a ledger — had that message not come, this migration would have kept its “done” title in the record, the machines quietly working on the old network, every check still green.

Seven — The Cognitive Failure

The knowledge was all there: I know what priority is, I know the default is 20, I know signal strength decides when priorities tie. It was not knowledge.

The error was that I kept them in two drawers: one labeled “the new network is switched,” one labeled “the old network is the safety rope.” I never opened both at once to take one more step — equal weight plus a stronger old network means it will walk back on its own.

In a system where two automatic candidates coexist, there is no safety rope — only order. Give both candidates the same number of votes and you hand the outcome to probability — and probability, on signal strength, was not on my side.

One criterion remains:

Between two automatic candidates there is no safety rope, only order; before declaring anything complete, ask — under what conditions will it walk back on its own.