We moved house this month, and the part nobody warns you about is not the sofa or the wardrobe. It's the quiet pile of computers in the corner that you have, over several years, made load-bearing for your daily life without ever quite admitting it. The lights, the heating schedule, the file shares, the DNS, the thing that backs up the photos. None of it is mission critical in any real sense, and all of it is the kind of thing that, when it stops, generates a steady drip of "is the internet broken?" from everyone else in the house.
So this is the long version: how I packed a homelab, moved it ten miles, and got it back on its feet, plus the handful of things I'll do differently next time. Because there will be a next time, and I'd like to be less of an idiot about it.
Photograph everything before you touch it
The single best thing I did cost nothing and took five minutes. Before I unplugged anything, I photographed the back of the rack from three angles, close enough to read the labels. Then I photographed the front. Then I photographed the little nest of power bricks under the desk, the ones that have no markings and could be 12V or 5V and will absolutely destroy something if you guess wrong.
I have moved before on the confidence that I'd remember the wiring. I did not remember the wiring. Nobody remembers the wiring. The photos meant that when I was on my knees in the new house at eleven at night, I could just look at the picture and put the blue cable back in the port the blue cable came out of, instead of reverse-engineering my own decisions from six months ago.
Write down what depends on what
The thing that catches you out in a rebuild isn't the hardware, it's the order. Everything in a homelab depends quietly on something else, and you only discover the dependency graph when you power things up in the wrong sequence and watch them all fail to find each other.
In my case the chain is roughly: the network has to be up before anything, then DNS and DHCP, then the NAS that holds the volumes, then the box that runs the containers that mount those volumes, then everything that talks to those containers. Bring that up out of order and you get a cascade of services sulking because the thing they need isn't there yet. Some of them retry forever and quietly recover. Some of them give up on first boot and need a kick. Knowing which is which, in advance, on a bit of paper, is the difference between a calm evening and a furious one.
I'd never actually written this down before. It lived in my head, which is fine right up until your head is also dealing with where the kettle is and why the broadband isn't provisioned yet. So now there's a text file, boringly titled boot-order.md, that says what to turn on and in what sequence and what to check before moving to the next step. It is the least glamorous document I own and it saved the evening.
The broadband is the real single point of failure
Here is the bit I got wrong. I had the whole lab planned to the cable, and I'd given precisely no thought to the fact that the new house's broadband wouldn't actually be live on moving day. The line was "active" in the sense that the provider had taken my money, and entirely inactive in the sense that any packets left the house. So I had a perfectly rebuilt lab with nothing upstream of it.
The lesson is that your lab does not exist in isolation. It sits on top of a connection you don't control, provisioned by people working to their own timescale, and no amount of careful cabling fixes a circuit that hasn't been turned on yet. Next time I'll arrange the install for well before the move, or keep a 4G fallback to hand so the house isn't dark while I wait. A homelab with no WAN is just a very warm cupboard.
What actually went well
For all the grumbling, most of it worked. The NAS came up, checked its array, found everything intact, and got on with life. The containers, once the dependencies were in place, started in the right order because I'd finally written that order down. The DNS came back and the chorus of "is the internet broken?" stopped, which is the only metric that really matters to anyone but me.
The things that went wrong were, without exception, the things I hadn't documented. The things that went right were the things I had. That is not a subtle lesson and I'm slightly embarrassed it took a house move to land it, but here we are.
There were small mercies too. The kit itself shrugged off the journey. Spinning disks make me nervous in transit, but they were powered down, packed properly, and came back without a single reallocated sector to show for it. The one casualty was a fan that decided the move was a good moment to start making a noise like a wasp in a jar, which is a five-pound fix and exactly the sort of thing you want to fail, loudly and cheaply, rather than silently and expensively six weeks later.
The takeaway
A homelab is a system, and a system is only as moveable as your understanding of it. Hardware travels fine in bubble wrap. What doesn't travel is the undocumented knowledge in your head about how it all fits together, because that knowledge evaporates under stress exactly when you need it. So: photograph the cabling, write the boot order down, and remember that the connection into the house is a dependency you don't own.
The lab is up. The boxes are mostly unpacked. There's a router blinking happily in its new corner, and for the first time the documentation describing it is good enough that the next person to rebuild it could be a complete stranger. That person will probably still be me, having forgotten everything, which is rather the point of writing it down.