India’s Leading Domain & Web Hosting Provider
Support
Domain & Login
Blog
Infrastructure Discovery: Agentless Inventory and Dependency Mapping
Infrastructure discovery is the collection of a verified inventory of every server, VM, storage volume and network flow in an estate, with utilisation history and dependencies, so migration decisions rest on measured data. NTSPL runs agentless collectors for at least 30 days, reconciles the result against your CMDB and licence register, and hands over owner-confirmed move groups to CIOs planning a data-centre exit.
Delivered on
In scope
Why a CMDB Export Fails as a Migration Baseline
Most estates we discover differ from the CMDB by 10-30 percent: retired VMs still licensed, a physical box under a desk running payroll, a SQL instance three applications quietly depend on. A one-off vCenter export misses peak utilisation, so sizing uses allocated rather than consumed CPU and memory, and cloud quotes come out 35-50 percent high. Nobody can say which servers must move together, so the first wave breaks an interface on cutover night.
NTSPL deploys the provider's own collector, the Azure Migrate appliance, the Migration Evaluator Collector on AWS or the Migration Center discovery client on Google Cloud, with read-only vCenter, Hyper-V and SSH/WinRM credentials. We collect at least 30 days including a month-end close, add agents only where flow data is missing, and reconcile every record against the CMDB, Active Directory and licence register before drawing a move group.
Signals That Your Estate Needs Measured Discovery
Signals you need Infrastructure Discovery
- The CMDB was last reconciled over 12 months ago, or infrastructure and finance quote different server counts
- A colocation contract or hardware AMC renewal falls due within 9-12 months
- More than 150 servers across VMware, Hyper-V and physical hosts, with no flow-level dependency data
- An earlier cloud quote built on allocated vCPU came back 40 percent above expectation
- Windows Server 2012 hosts still run after ESUs ended on 13 October 2026 and nobody holds the full list
When to choose something else
- Fewer than 30 servers with a trusted inventory: a two-day workshop and a vCenter export suffice, so start with a Cloud Readiness Assessment.
- The estate already runs in cloud and the concern is waste: that needs a cost assessment of the live bill, not on-premises discovery.
What the Discovery Sweep Covers
Virtual estate
vCenter, Hyper-V and Nutanix AHV inventories with configuration, snapshots and 30-day CPU, memory, IOPS and network percentiles.
Physical and orphan servers
Subnet sweeps and AD computer objects compared with inventory; every unmanaged host gets an owner or a retire flag.
Storage footprint
SAN LUNs, NAS shares and backup repositories with used versus provisioned capacity and growth rate.
OS and software
OS, database and web-server versions per host, with end-of-support items such as Windows Server 2012, RHEL 7 and CentOS 7 flagged.
Dependencies and licences
Port-level server-to-server edges with connection counts, plus Windows, SQL Server and RHEL entitlements matched to hosts.
Collector-to-Move-Group Discovery Pipeline
Agentless Discovery and Dependency Mapping Pipeline
Collectors gather configuration, performance and connection data for 30 or more days into one normalised inventory. NTSPL reconciles it with the CMDB, clusters a filtered dependency graph and publishes owner-confirmed move groups with right-sized specs.
Select any component
Agentless Discovery and Dependency Mapping Pipeline: click any of its 8 components to see its role and the design choice NTSPL makes for it, or trace the 7-step primary path.
Native Discovery Tooling on AWS, Azure and Google Cloud
Collector utilisation and RVTools data feed AWS Transform for VMware-estate grouping; right-sized EC2 and EBS gp3 targets are priced in Mumbai or Hyderabad.
Azure Migrate maps dependencies agentlessly for VMware and Hyper-V VMs, so agents are rarely needed; servers staying on-premises are onboarded to Azure Arc during discovery.
An RVTools import starts analysis on day one while the discovery client gathers 30 days of performance; outputs map to Compute Engine families in Mumbai and Delhi.
Choices That Decide Discovery Accuracy
Agentless versus agent-based collection
Default to agentless for VMware and Hyper-V: zero guest change and roughly 90 percent coverage. Add agents only where agentless dependency capture is unsupported, typically physical Linux, older Windows builds or hosts behind strict firewalls. If more than 15 percent of hosts need agents, raise a separate change request rather than slipping installs into the window.
Length of the collection window
Thirty days is the floor, and the window must include a month-end or quarter-end close. Retail and education clients get 45 days to catch festive or admission peaks. Short windows under-size batch servers that idle for 27 days and run flat out for three, exactly where post-cutover complaints start.
Sizing basis
Size on P95 utilisation, not allocation and not the mean. Apply 20-30 percent headroom only to customer-facing and database tiers; dev and test get none. Where P95 CPU stays below 10 percent for the whole window, flag the VM for consolidation or retirement before it receives a target SKU.
Shared-service noise in dependency maps
Domain controllers, backup proxies, antivirus consoles and monitoring servers talk to everything and collapse the graph into one giant cluster. Exclude them by host list and port, treat them as landing-zone foundation services, then cluster remaining edges with a minimum daily connection threshold.
The Six-Week Discovery Sprint
Collector deployment
Service accounts, firewall rules, project registration and an RVTools/CMDB import for an immediate first view.
Collection with completeness tracking
Daily report of silent hosts; any host missing for 48 hours is chased by name.
Host-by-host reconciliation
CMDB, AD, backup catalogue and licence register compared; orphans get owners or shutdown tests.
Dependency clustering and owner review
Each proposed group is confirmed or split with infrastructure and application leads.
Sizing and readout
P95 specs mapped per cloud; inventory and move groups handed to readiness and TCO workstreams.
What you receive
How We Measure Discovery Quality
| KPI | Typical target |
|---|---|
| Hosts reporting versus expected | 98 percent or higher |
| Servers with 30+ days of performance data | 95 percent or higher |
| Move groups confirmed by owners | 100 percent before wave planning |
| Post-migration sizing variance | Within 15 percent of plan |
Where Discovery Projects Go Wrong
| Risk | How NTSPL prevents it |
|---|---|
| Endpoint security silently blocks the collector | Daily completeness report against the expected host list, with named escalation after 48 hours. |
| The window misses the business peak | Window set from the finance and operations calendar, extended rather than extrapolated. |
| Discovery credentials carry excess privilege | Read-only, vaulted roles rotated at sprint end, with access logs kept for CERT-In's 180 days. |
Is an RVTools export enough, or do we need a full discovery tool?
An RVTools export is a good day-one snapshot of VM configuration, allocated resources and datastores. It cannot size or sequence a migration because it has no utilisation history and no network connections. Use it in week one to start pricing and spot obvious retirements, then run a provider collector for at least 30 days to get P95 performance and dependency edges. Under about 50 well-understood VMs, RVTools plus owner interviews can suffice. Above 150 VMs, skipping measured discovery usually costs more in oversizing and failed cutovers than discovery itself.
Key facts: Infrastructure Discovery
Infrastructure Discovery in Practice
2 Infrastructure Discovery scenarios, from Engineering services and Logistics parks and warehousing, plus related platform case studies.
Engineering-services firm finds 61 unlisted servers before committing a 9-month exit
Logistics park operator separates edge and cloud systems across five parks before AWS
EPC company vacates its owned data centre in 7 months and halves run cost
D2C fashion brand absorbs 14x festive flash-sale traffic with zero checkout outages
Infrastructure Discovery: Frequently Asked Questions
How long does infrastructure discovery take?
About six weeks for estates of 150-1,500 servers: one week to deploy collectors, at least 30 days of collection and analysis overlapping the tail. The collection window sets the calendar, so a larger estate adds analysis effort rather than weeks.
What does an infrastructure discovery engagement cost?
A single-site estate of around 300 VMs typically needs 18-25 consultant days, driven mostly by site count and the share of physical hosts. Provider collectors carry no licence fee, and hyperscaler assessment funding can offset part of the effort where the estate qualifies.
Will the collectors slow down production systems?
Not measurably in our experience. Agentless collectors query vCenter or Hyper-V APIs and guests at low frequency from one VM on the management network. We still run network sweeps outside business hours with an agreed rollback. Collection can be paused per host within minutes if a performance concern is raised.
Does discovery data raise DPDP Act or CERT-In concerns?
It is configuration metadata rather than customer personal data, but hostnames, accounts and IP plans are sensitive. We select an Indian geography for the discovery project where offered, restrict access to named staff and delete NTSPL working copies at closure, consistent with DPDP Act 2023 and CERT-In obligations.
Do agents have to be installed on every server?
No. Agentless collection covers most VMware and Hyper-V VMs, including dependency capture on Azure Migrate. Agents are mainly for physical servers and unsupported hosts, typically under 10 percent of the estate. Each agent install is raised as a standard change with the host owner's approval.
What happens to the discovery output afterwards?
It becomes the programme's system of record: readiness work uses the OS data, the TCO model uses P95 specs and wave planning uses the move groups. We hand it over in native import format so nobody re-collects. A refresh of the inventory is advisable if migration starts more than six months after the readout.