Microsegmentation products are good. They are also a purchase, a deployment, an agent on every workload, and a new operational discipline. Before that, there is a large amount of value available from what you have.
The part that is actually hard
Not enforcement. Enforcement is a configuration line on equipment you already own.
The hard part is knowing what legitimately talks to what. Without that map, any policy you write is a guess, and a guessed policy either blocks something important or permits everything, and the second is what happens because the first causes an outage.
A microsegmentation product helps here by discovering flows. That discovery is its main value, and it is the part people underestimate when they assume the product will do the work.
What you can do first
Get the flow data. Your switches and firewalls already export it. Collect thirty to ninety days and you have an observed map of actual communication. This is the input to everything and it costs nothing but storage.
Separate the tiers that obviously should be separate. Management networks from production. Out-of-band management on its own. Backup infrastructure isolated. Development from production. These are coarse boundaries, they are enforceable with VLANs and firewall rules, and they close the paths that matter most.
Coarse segmentation done properly beats fine segmentation planned forever.
Deny inter-subnet traffic by default within a zone, where you can. Many environments permit anything within a tier because that was the default. Servers in the same subnet rarely need to talk to each other, and lateral movement depends on exactly that.
Use host firewalls. Every operating system has one. They are enforcement points you already own, on every workload, with no additional agent. Managed centrally through configuration management, they are genuinely effective, and they are switched off almost everywhere.
Isolate the recovery path. Backup infrastructure should be reachable from the systems it backs up on specific ports and from nowhere else. This single boundary is worth more than any number of fine-grained rules between application tiers.
Where the product earns its money
Workload mobility. Policy that follows a VM rather than depending on where it is plugged in.
Identity-based policy. Rules expressed as application roles rather than addresses, which survive re-addressing and scale better.
Scale of rule management. Beyond a few hundred rules, managing them on network equipment becomes its own problem.
Continuous discovery. Seeing new flows appear and flagging them.
All real. All worth buying at a certain scale and maturity. None of it a substitute for having done the coarse work first, and a product deployed onto an environment nobody has mapped produces a very expensive permit-any policy.
The order I would go in
Collect flows. Draw the actual map. Separate management, backup and out-of-band. Enable host firewalls with a sensible baseline. Deny what the map says is unused, starting with the highest-value boundaries.
Then, if the residual risk justifies it and you have the operational capacity, buy the product to do the fine-grained work.
That order gets most of the risk reduction early and cheaply, and it means that if the product purchase never gets approved, you are still much better off than you were.