I find it unbelievable that people setting up switches don't know what a VLAN is, or don't use them. I've dealt with a number of IT managers and IT contractors who literally have no idea what a VLAN even is.
I've heard all sorts of rubbish reasoning, but never a reason to NOT deploy VLAN's on almost every network by default, the second you take it over.
And if you're worried about adding them to a "legacy" network, just do it. Put anything new on the "new" VLAN's, and access to them, and leave everything on the "default / untagged" VLAN until you can start moving it over.
With server VM's (also a no-brainer that should be your FIRST job if you're taking over a non-virtualised network), it's literally just adding another interface on the necessary VLANs and off you go.
You should be isolated as much as possible.
- Make the default VLAN as boring and empty as possible.
- Separate off wireless, guest wireless, access control, CCTV, telephony (probably job #1!), printers, inter-server traffic, etc. into their own VLAN. Put the necessary VLAN interfaces on the VM's that need it (e.g. telephony integration servers).
Then you can separate and monitor traffic (e.g. CCTV VLAN using much more traffic than telephony VLAN, etc. rather than have to do protocol analysis to find that out), remove any opportunity for browsing and bypassing stuff, and apply completely separate settings to entire VLANs (e.g. QoS on the entire telephony VLAN, rather than on individual endpoints, or DSCP tagging, or port-detection or whatever).
Personally, I think even printers should be on their own VLAN (hint; They don't even need VLAN support for you to do this! Just keep your wiring sensible so that they don't piggyback/share with other devices). That way nobody can "browse" for printers to exploit / prank, and have to go through - say - a Papercut server that's the only "computer" on the printer VLAN, and has a public web interface on the client VLAN. You're also separating out thee broadcast traffic to only those devices that actually need to be listening in on it (not everything does multicast properly) - no more dozens of printers constantly advertising their wares to every port on your network.
And though it might allow you to run two identical IP ranges over two different VLANs on the same cable, I think that's stupid. Just renumber. Internal ranges are plentiful. In fact, I tend to number ranges to mirror the VLAN number - e.g. 192.168.10.x - 192.168.19.x to be on VLAN 1, 192.168.20.x - 192.168.29.x to be on VLAN 2, etc.). Because then you can spot your mistakes so much more easily and someone "just browsing" has much more work to do.
VLANs are a no-brainer. I work for schools and for years, stupid educational companies ingrained the concept of separating wiring for "admin" and "curriculum" networks. When all the kit could have just supported VLANs (and proper damn permissioning / authentication would solve the problem anyway). I still walk into schools wired that way, where a bursar cannot log in in a meeting room, etc. because he's "on a different network" that's physically separated so even domain trusts aren't possible.
VLAN. VM. First two jobs to solve in every workplace that doesn't already have them. Anything else is just madness.