Cut the Right Wire

Every spy movie has the same scene. The hero is crouched over a briefcase full of wires, the timer is counting down, and he has to cut exactly one wire. Cut the right one, everybody goes home. Cut the wrong one, roll credits.

Nobody in that scene is panicking about the timer. The whole game is knowing which wire is load-bearing before you touch anything.

That, in one sentence, is what I mean when I say systems thinking. Beginner systems thinking is understanding how the pieces connect. Next-level systems thinking is seeing the trap before it springs, and knowing the order you have to work in so it never goes off.

Let me show you a real one. I'm going to keep it high level and keep the client anonymous, but the shape of it is the point.

"Simple" job

We recently took on a new client. They wanted three things: a new website, their email moved over to Google Workspace, and their business set up on HyppoCRM. (Quick aside: HyppoCRM is free. You don't download it, you just sign up at hyppocrm.com, connect your Stripe, and it handles the rest. Okay, back to the story.)

Move some email. Sounds like an afternoon.

Then I opened the briefcase.

Step one: find out what's actually wired to what

A tangled wiring harness laid out on a workbench, each wire tagged DNS, MAIL, DOMAIN, TXT, MX, with a magnifying glass and a hand-drawn diagram — Before you cut anything, you map it. Every wire gets a name and a job.

First thing I do on any migration is nothing. I look.

Here's what I found. Their domain (the name itself) lived at one company, the registrar. But their DNS records, the little signposts that tell the internet where the website lives and where the email goes, were being managed at a completely different company. Two providers, one domain, and nobody had written down which was which.

On top of that, some of their DNS records were flat out broken. And they didn't just have the mailboxes they told me about. They had three extra ones sitting unused, full of years of historical email that nobody wanted to lose but nobody was checking either.

None of that is a disaster. But every one of those is a wire, and a couple of them are the ones that make the whole thing blow up if you cut them early.

Step two: cut the first wire, the verification record

Wire cutters snipping a single green wire tagged TXT inside a case of tangled wires — The TXT record. Harmless on its own, and it goes in the DNS manager, not at the registrar.

To create their Google Workspace, Google has to prove you own the domain. It hands you a little text record (a TXT record) and says go put this on your DNS.

Sounds trivial. Except remember: the DNS isn't where the domain is. If you go to the registrar looking for it, you'll find nothing, get confused, and possibly start "fixing" things that aren't broken. I went to the DNS manager, added the record, Google verified it, and nothing else changed. First wire cut. Timer still running, nothing exploded.

Step three: move the mail, all of it, before you touch delivery

Wire cutters snipping a blue wire while a stream of glowing envelopes flows through a cable from an old server into a new one — Every message gets copied to the new inboxes while the old ones keep working.

This is the long, boring part, and the boring part is where people get sloppy.

I imported every mailbox into Google, including the three dormant ones with all the history. (There's a way to do that without paying for three extra seats forever. I won't get into it here, but it exists, and figuring it out is part of the job.) The key thing is that during this step, the old mail system is still fully live. Mail is still arriving in the old inboxes. Nobody's day is interrupted. We're just quietly building a copy on the other side.

Then you wait. And you don't cut the next wire until you've checked that what landed in Google matches what's in the old system. That gap between the two is the delta, and the delta needs to be zero before you move on.

Step four: the red wire, switching where mail actually goes

A red wire tagged MX held between the blades of wire cutters, other wires blurred in the background — The MX record. This is the one that decides whether email arrives or vanishes.

The MX record is the signpost that tells the entire internet "deliver this company's email here." Change it, and every email from that moment forward goes to the new place. Change it too early, and mail starts landing in inboxes that don't have their history yet. Change it wrong, and mail just disappears.

So this one gets cut last among the mail steps, only after the import is verified, only after I've confirmed every person can log into their new Google inbox and see their old email sitting right there. Then I flip the MX record, watch a test email land, and breathe.

Step five: the wire that would have blown the whole thing

An open case with every wire cut and hanging loose, the display frozen at 1, wire cutters set down beside it — Domain transfer goes dead last. Timer stopped at one second. Everybody goes home.

Here's the trap, and it's the whole reason I wrote this.

The client also wanted their domain moved to us, so we'd control it going forward. A lot of people, and a lot of AI assistants, will tell you to do that first. Get the domain in hand, then do the rest. Clean. Logical. Wrong.

When you transfer a domain, the new registrar typically flips the name servers to its own defaults. Remember that the DNS records were living at a separate provider? Flipping the name servers would have pointed the domain away from that provider entirely. Every DNS record, including the ones that route their email, would have effectively vanished in one click. Their mail would have stopped dead, mid-migration, with the history only half moved.

That's the wire you don't cut first. That's the wire you cut last, after the mail is fully cut over and living happily in Google, so that even when the name servers flip, the only records I need to rebuild are the ones I already have written down.

The part where the AI was wrong

I use AI all day. It's woven into how we build everything at Hyppo. And on this job, some of the steps it suggested were flat out wrong. Not slightly off. Wrong in the "cut the red wire first" way.

That's not a knock on the tools. It's a reminder of what they are. AI is great at telling you what the wires are called. It has no idea which one is load-bearing in your specific briefcase, because it hasn't looked inside it. You have. That's the job. The tool can hand you the wire cutters, but you're the one who has to know what happens when the blades close.

Why I told the client it would take longer

We're still in the middle of this one. Early on I told the client, straight up, that this might take a bit longer than it looks because I want to be methodical and go step by step. That's a weird thing to say when you're trying to impress a new client. But this is an important account, and the absolute worst outcome isn't "it took an extra few days." The worst outcome is "our email died and we lost a big deal because the guy we hired to move it got cocky."

Slow is smooth. Smooth is fast. The guys in the movies figured that out a long time ago.

What this actually looks like as a skill

If you take one thing from this, take this: before you touch any system, ask what's load-bearing. Not what's obvious. What's holding weight.

Then work in the order where every step is reversible until the last one, and the last one is the only one that can't be undone. That's it. That's the whole trick. It applies to email migrations, to database changes, to hiring, to pricing, to pretty much everything I do as a founder.

Anyone can cut wires. Cutting the right one, in the right order, with one second on the clock and a calm face? That's the part you get paid for.