For years everything in the house lived on one flat 192.168.1.0/24. The NAS, the laptops, the printer, a pile of IoT junk, the cameras, a couple of VMs, the kids' tablets. All on one broadcast domain, all able to talk to everything, which is fine right up until you read about a smart plug phoning home or a camera with a firmware CVE, and you'd quite like the toaster not to be on speaking terms with the file server.
So: VLANs. The plan was sensible, the execution was where the pain lived. I wanted a trusted segment, an IoT segment, a guest segment, and a management segment, with firewall rules between them rather than the current "everyone trusts everyone" arrangement. The mistake I nearly made was trying to do it in one weekend big-bang cutover. The thing that saved me was doing the opposite.
discover before you cut
The first and most useful step had nothing to do with VLANs. It was finding out what was actually on the network, because a flat /24 accumulates devices you have entirely forgotten about. I ran a sweep and then sat reading the list with growing unease.
sudo nmap -sn 192.168.1.0/24 -oG - | grep Up
There were things on there I could not immediately identify. An IP that turned out to be an old Raspberry Pi running a temperature logger I'd set up and forgotten. A device that was the garage door opener. Two that I never did identify and eventually traced by unplugging things until one disappeared. The point is that if I'd defined my VLANs and migrated DHCP in one go, I'd have silently cut off several things I rely on and only found out days later when something didn't work and I'd lost the thread of what changed.
migrate one segment at a time
The actual migration was incremental and boring, which is exactly what you want from networking. I created the new VLANs and subnets on the router, each with its own DHCP scope, but left the old flat network running alongside. Then I moved one category of device at a time.
IoT went first, because it was the riskiest and the least likely to cause a domestic incident if something broke. Move the devices onto the IoT SSID and VLAN, watch them get the new addresses, then add the firewall rule that says IoT can reach the internet and nothing on the trusted side, full stop. Test that a light still turns on and a camera still records. Leave it a couple of days.
Then guest. Then the management VLAN for the switches and the router and the hypervisor, which is the one you tiptoe around because locking yourself out of the management interface from the wrong subnet is a genuinely funny way to spend an evening, in the way that is not funny at all. I kept a wired laptop on a trunk port with access to everything while I did that one, as an escape hatch.
The trusted segment, the laptops and the NAS, I moved last and slowest, because that is where the family lives and where a broken evening means complaints. By then the pattern was routine.
the rule that made it bearable
One principle did most of the work: default deny between segments, then open exactly the paths you need and nothing more. IoT cannot start a conversation with trusted. Trusted can reach IoT, so I can still open the camera app and turn off a plug. Guest reaches the internet and nothing internal. Management is reachable only from trusted and only on the ports that matter.
What I learned, mostly, is that the hard part of segmenting a flat network is not the VLAN tagging or the firewall syntax, both of which are well documented and quick once you sit down to it. The hard part is that a flat network has been quietly hiding how much talks to what. The moment you put walls up, every undocumented dependency you've ever created announces itself by breaking. Doing it one segment at a time, with a discovery pass first and an escape hatch open, meant each break was small, obvious, and traceable to the one thing I'd just changed. Big-bang would have given me a pile of failures and no idea which wall caused which.
It is markedly tidier now, and the toaster no longer has an opinion about my files.