Assessing Your Current Infrastructure

Assessing Your Current Infrastructure

Photo by panumas nikhomkhai on Pexels

Before migrating to the cloud, you must thoroughly understand what you currently have. A complete infrastructure assessment prevents costly surprises, identifies dependencies you might miss, and forms the foundation of your migration plan.

Why Assessment Matters

Studies show that 60% of cloud migrations exceed budget due to poor upfront assessment. Without knowing what you have, you cannot estimate what it will cost to move or run in the cloud. Assessment is the step that determines whether migration is even the right choice for each workload.

What to Assess

1. Server Inventory: List every physical and virtual server with CPU, RAM, disk, and network specs. Note the OS, installed software, and which applications each server hosts.

2. Application Dependencies: Map which applications talk to which databases, APIs, and external services. Use network monitoring to discover connections you didn't know existed.

3. Data Volumes: Measure storage for databases, file shares, backups, and archives. Cloud egress and storage costs depend heavily on data size.

4. Network Topology: Document firewalls, load balancers, VPNs, and inter-server communication patterns. Cloud networks need to replicate critical paths.

5. Performance Metrics: Collect CPU utilization, memory usage, disk IOPS, and network throughput over a 30-day period. This data determines the right-sized cloud instances.

6. Licensing: Catalog software licenses—OS, databases, middleware. Some licenses are portable to the cloud; others are not. This alone can save or cost thousands.

Step-by-Step: Conducting Your Assessment

Step 1: Install monitoring agents on all servers to collect performance data for at least 30 days.

Step 2: Run a network discovery tool to map server-to-server communication and external dependencies.

Step 3: Interview application owners to document business-critical processes, acceptable downtime windows, and compliance requirements.

Step 4: Create a spreadsheet listing every workload with columns for: name, type, dependencies, data size, CPU avg%, RAM avg%, criticality (high/medium/low), and migration priority.

Step 5: Categorize each workload as: Easy to Migrate (standard apps), Needs Replatforming (custom configs), or Stays On-Prem (highly sensitive or legacy systems).

Free Tools for Assessment

• AWS Migration Evaluator: Free service that analyzes on-premises server utilization and recommends right-sized AWS instances

• Azure Migrate: Free assessment tool that discovers on-premises servers and builds migration plans

• Google Cloud Migration Center (formerly StratoZone): Free discovery and assessment platform

• Nmap: Open-source network scanner for mapping server dependencies

• Prometheus + Grafana: Open-source monitoring stack for collecting performance metrics

Key Takeaways

• Assessment is the foundation of a successful migration—skip it at your peril

• Measure at least 30 days of performance data before selecting cloud instance sizes

• Map all application dependencies before migration order—broken dependencies cause outages

• Use free vendor tools to automate data collection and reduce manual errors

Common Questions: Assessing Your Current Infrastructure

Q: What free tools can help inventory our current infrastructure?
Spiceworks Inventory (free) provides network discovery and asset management. Nmap (free, open-source) maps network hosts and services. Ruby (free) by Zendesk maps IT dependencies. Open-AudIT (free community edition) automates hardware and software discovery. For cloud migration specifically, AWS Migration Evaluator, Azure Migrate, and Google Cloud Migration Center all offer free assessment tools that scan your on-premises environment and provide right-sizing recommendations. Start with these tools to build a complete picture of what you have before planning what to move.

Q: What happens if we skip the infrastructure assessment phase?
Without proper assessment, you'll likely over-provision cloud resources (wasting money) or under-provision them (causing performance issues). You may migrate applications that should be retired, move workloads that aren't cloud-compatible, or miss critical dependencies between systems. This leads to migration failures, cost overruns, and extended downtime. The assessment phase typically takes 2-4 weeks and prevents months of remediation work later. It's the foundation of a successful migration—every subsequent decision depends on accurate infrastructure data.

Q: How deep should our dependency mapping go?
Map at minimum: network connections (which servers talk to each other), data flows (which databases feed which applications), authentication dependencies (Active Directory, LDAP, SSO), and external integrations (third-party APIs, payment gateways, email relays). For each application, document: what it depends on, what depends on it, peak usage times, and acceptable downtime windows. Missing even a single dependency—like a legacy SMTP relay that an application uses for notifications—can cause a migrated application to fail in production. Use automated discovery tools to supplement manual documentation, as hidden dependencies often exist that IT teams aren't aware of.