It's easy to say "move them to the cloud" or "isolate the legacy server." Those are outcomes. The scoping work is everything between the outcome and a bill of materials someone can actually buy: choosing the architecture, sizing the hardware, mapping every dependency, validating compatibility, and pressure-testing the plan against the ways it can fail. Get it wrong and the project either doesn't work or doesn't fit the budget, and you find out at the worst possible time.
What "figuring out how" actually involves
- Architecture selection. Picking the actual design pattern (cloud-native vs. hybrid, replace vs. isolate, which identity model, which segmentation approach) and being able to defend why this one over the alternatives.
- Vendor and product research. Comparing specific models and licensing modes, reading the spec sheets that matter, and confirming a product does the thing the design needs it to do before it's on the list.
- Sizing. Matching throughput, capacity, interface counts, and runtime to the real load, so nothing is dangerously under-provisioned or wastefully over-built.
- Compatibility and dependency mapping. Tracing what talks to what, which ports, which protocols, which licenses, and what breaks if one piece moves. This is the work that finds the landmines.
- Bill of materials. Turning the whole design into specific line items, each justified, so the plan becomes a number a client can approve.
Across my team this is why everyone is hand-selected from our most experienced technical base. We're not the deepest specialist in every domain (nobody is), but we're deep enough in all of them to recognize the gaps, and disciplined enough to research the gaps we find instead of guessing past them. Breadth plus the willingness to go find the answer beats narrow depth for this kind of work.
Example one: a non-obvious path
A legacy ERP that couldn't be retired or affordably upgraded
A client ran an archival ERP and accounting platform, plus an in-house job-tracking system, on SQL databases hosted on a Windows Server 2008 R2 VM. The data was approaching three years stale, but open and unpaid jobs still needed referencing, so it couldn't be switched off. An unsupported, end-of-life server also couldn't safely stay on the production network.
The obvious initiative: upgrade the OS and SQL onto new hardware. I scoped it fully, and it was cost-prohibitive, because the ERP vendor required roughly nine years of back-dated support licensing to land on a supported release. The "correct" technical answer was the wrong business answer.
So I solved a licensing-and-hardware problem with networking instead. I designed an isolation pattern: segregate the VM onto its own restricted segment, allowed to do exactly two things: authenticate against Active Directory and back up to the BDR appliance. Controlled remote access runs through a separately segmented Windows 7 jump VM that can reach only AD and the 2008 R2 server, and nothing else. Same business capability preserved, unsupported system removed as a lateral-movement risk, at a fraction of the upgrade cost.
That solution only exists because the scoping work crossed domains (ERP licensing economics, SQL, Active Directory, network segmentation, BDR, and remote-access design) and didn't stop at the first textbook answer. The expensive, obvious upgrade would have looked responsible on paper and quietly drained the budget for no real gain. The containment design came out of scoping, not strategy.
Example two: designing from nothing
A secure network for a brand-new overseas production site
A new international production location of about 10 users and 30 devices needed secure access to company resources from day one, with no existing infrastructure beyond cabling and no local IT. The ISP and static IP wouldn't be known until the building lease was signed, and the physical install would be done by non-technical staff on the other side of the world.
The first cut of the design assumed a site-to-site VPN back to headquarters. But scoping isn't a one-time act, and as the parent cloud migration finished that assumption stopped being true: with company resources now living in Microsoft 365, the site didn't need a tunnel into HQ at all. The design pivoted to cloud-direct access gated by device-based Conditional Access, so only managed, compliant devices reach company data, and an entire international VPN boundary dropped off the attack surface.
What shipped was a Sophos XGS firewall as the local security edge, three VLANs (wired, internal WiFi, isolated guest) with explicit inter-VLAN policy, UniFi switching and access points centrally managed, and a UPS sized to shut everything down gracefully. The part that made it deliverable was sequencing around the unknowns: every device staged, configured, and lab-tested in the US before shipping, with only the ISP-dependent values left to set on site, all of it wrapped in an installation runbook and diagnostics checklist written for non-technical hands.
Each risk in that plan came with a mitigation because each one was found during scoping, not during deployment: ISP delay, firewall rules too tight or too loose, WiFi coverage gaps, insufficient UPS runtime, a device that couldn't reach the cloud leaving a user stranded. And the biggest call, dropping the VPN once it was no longer needed, came from treating scoping as something you revisit rather than a plan you defend. Naming the risks ahead of time is the difference between a remote site that comes up clean and a transcontinental support emergency.
Why I absorb this work on purpose
I could hand a thin outcome to a design desk and wait. But the scoping is the alignment. The decision to isolate rather than replace, to eliminate rather than refresh, to spend on networking instead of licensing: those aren't downstream implementation details. They're the recommendation. If the person setting the strategy can't also engineer the execution, the strategy drifts away from what's actually buildable and affordable. Owning both is what keeps the roadmap honest.