Relocation as Refactor

Moving countries is a migration with no rollback plan. You lift an entire system — paperwork, relationships, daily routines, the small infrastructure of being a person — and you redeploy it onto unfamiliar substrate. Some services come back up immediately. Others stay broken for months. The ones that stay broken the longest are the ones you forgot were running.

I made the call to leave on a Tuesday, in the bath, with a spreadsheet open on my phone. The spreadsheet had two columns — what I would keep, what I would let lapse — and a row count that kept growing every time I thought of something else. That spreadsheet is the migration plan. The bath is the staging environment. The Tuesday is the ticket number, the one I will eventually quote to myself when I forget why I started.

The system you are migrating is mostly invisible

The visible work of relocation is the immigration paperwork, the lease termination, the dog import permit, the box of cables you finally throw out. The invisible work is the substrate underneath it: the GP who knows your medical history, the pharmacist who fills the script without asking, the friend who picks up on the second ring at 11pm. None of that comes with you. You will rebuild it from scratch, in a city where you have not yet earned the right to call anyone on the second ring.

Software engineers underestimate this part because we are trained to think of migrations as data transfer. A relocation is closer to a cold start of an entire service mesh. Every dependency has to be re-resolved against the new environment. Every retry policy has to be re-tuned for new latencies. You will spend the first six months learning which of your habits were portable and which were specific to the runtime you left behind.

Defaults become explicit configuration

At home, almost everything is a default. The way you order coffee. Where the cutlery goes. Which day the bins are collected. What is rude to say at a dinner table. None of this is conscious until you cross a border and discover that the default has been swapped underneath you. The cognitive load of relocation is not the new things you have to learn. It is the old things you have to stop assuming.

Auckland will not be the city I came from. It will not be the cities my work mostly lives in. The defaults around weather, daylight, work hours, social distance, and politeness all shift simultaneously. Every shift is small. The aggregate is enormous. For the first months, you are running on a debugger — every action stepped through manually, because the cached assumption is no longer trustworthy.

This is the part nobody warns you about, because the people who have done it have either repressed the memory or have rebuilt the cache so thoroughly they have forgotten what it cost to populate. The exhaustion of the first six months is not weakness. It is the bill for every constant becoming a variable at once.

The work is still running while you rebuild it

You do not get to take the system down for maintenance. The clients keep paying. The code keeps shipping. The newsletter still goes out. The mortgage application still wants a payslip dated this month, in the new currency, from the new employer, who has not yet hired you because you have not yet arrived. The whole migration runs hot — production traffic, live writes, partial schema, and a maintenance window that exists only in theory.

I am doing the relocation in deliberately staged phases. December 2026 through February 2027 is the Auckland interview window — three months on the ground, candidate-facing, learning the runtime. The full relocation lands later in 2027, once an offer makes the move funded rather than speculative. Treating it as two deploys instead of one is the only reason this looks tractable from the inside.

Refactors that touch this much state look like regressions first

A refactor that rewrites how money flows, where you sleep, who you call, and what language the doctor speaks always looks worse before it looks better. The first metrics dashboard you check after the migration will be red. You will conclude you have ruined your life. You have not. You have just deployed to an environment with no warm cache, and the latency reads as failure until you remember it is just absence of history.

The trick is to measure progress in commits, not feelings. A commit is: I opened a bank account. I registered with a GP. I learned the name of the corner store owner. I figured out which bus actually runs on Sundays. Each one is a small line in the changelog of the new life. Stacked up, over months, they become a system again. The feelings catch up later. The commits go first.

What you intentionally leave broken

Not every service is worth restoring. A migration is also a chance to delete code you have been afraid to touch — friendships that were running on inertia, commitments that drained more than they returned, recurring obligations that had outlived their reason. The legacy system gave you cover to keep them running. The new system requires you to opt them back in. Most of them, quietly, you do not.

This is the part of relocation no one writes the blog post about, because it sounds cold. It is not cold. It is honest accounting. You cannot rehydrate every connection from the old environment, and pretending you will is how the first year of the new life gets eaten by maintenance work for a system you do not even live in anymore.

The rollback plan you do not get to use

Every senior engineer knows you do not deploy without a rollback. Relocation is the exception. There is no rollback. You can move back, eventually, but you will be moving to a country that has continued evolving without you, into a version of your old life that no longer matches the schema you left. The ‘rollback’ is just another migration.

Accepting that is the moment the migration actually starts. As long as you secretly hold open the possibility of reverting, you will not fully commit to the new environment. You will keep half your bandwidth in the old runtime, paying double tax. The decision to close that door is what frees the rest of the cycles to actually rebuild.

Auckland is not the destination. It is the next checkpoint. The system will keep refactoring itself after I land — that is what systems do. My job in 2027 is to ship the migration cleanly, document the breaking changes for the version of me who has to live inside the result, and resist the urge to call this ‘done.’ Relocations, like codebases, are only ever finished in the sense that someone eventually stops working on them. // JV, from the orchid dark.