Find them first
You cannot retire what you have not found, and the inventory is always longer than expected. Look in more than one direction, because each method misses different hosts:
- Firewall rules — anything permitted to reach management ports across a segment boundary
- Authentication logs on targets — group source addresses and look for the handful that appear everywhere
- Client configuration —
~/.ssh/configand saved RDP connections on admin workstations name the hosts people actually use - Ask, without blame — "how do you reach production on a Saturday?" surfaces paths no scan will find, but only if the answer is safe to give
Expect to find modems, vendor remote-support tools, a cloud VM someone spun up during a migration, and at least one host nobody can identify an owner for.
Migrate by traffic, not by team
Cutting over an entire team at once concentrates every unknown into a single afternoon. Move in tranches ordered by risk and volume:
- Pilot. One willing team, low-consequence systems, both paths open. The goal is finding what the design got wrong while the stakes are low.
- Tune against real use. Pilot always reveals missing entitlements, protocols nobody mentioned, and a batch job that authenticates as a human.
- Expand by system class. Non-production first, then production, then the systems that frighten people. Keep both paths live throughout.
- Verify the old path is idle. Watch authentication logs on the legacy host until its traffic is genuinely zero — not low, zero.
- Block, then decommission. Deny at the firewall first and leave the host up for a defined period. If something breaks, restoring is a rule change rather than a rebuild.
What always surfaces
| Discovery | What to do about it |
|---|---|
| Automation authenticating as a person | Issue a scoped machine identity before cutover, not during |
| Accounts belonging to leavers | Do not migrate them; this is the cheapest access review you will ever run |
| A protocol nobody mentioned | Usually a database client or a vendor thick client; confirm gateway support early |
| A system that cannot support the gateway | Document as an exception with a compensating control and an owner, and give it a review date |
| Hardcoded credentials in scripts | Vault them; this is often the largest single piece of work in the project |
The political part
The technical migration is usually easier than the conversation. Administrators experience the new gateway as supervision, and some of that reaction is reasonable — you are recording their work.
What helps: explain that the recording protects them as much as it constrains them, since "there is no session record" is the fastest possible exoneration when something breaks at 2am. Be specific about who can view recordings and under what circumstances. Involve senior administrators in the design rather than presenting it finished. And apply the same rules to the security team, visibly — a gateway that everyone must use except the people who built it does not survive contact with the organisation.