Why you should audit your infrastructure before an AWS migration Migrating to AWS without measuring what you already have is like sailing without a chart. Many teams discover only after cutover that their cost estimates were understated, that some servers consumed far more resources than assumed, or that hidden dependencies between applications made phased sequencing harder than expected. The existing infrastructure audit is therefore the foundation of any coherent migration strategy. It lets you answer three crucial questions: what do you actually have, how much does it cost today, and how much will it cost on AWS. Without those answers, you are moving blind. A rigorous audit, carried out before you even configure your first AWS account, eliminates false assumptions and gives you concrete data on which to base your migration roadmap. It is also the opportunity to identify obsolete applications, duplicates, or configurations that can be rationalized right away, reducing the project's complexity and long-term costs.
Identifying and documenting your current infrastructure The first step is to inventory precisely what you own. This starts with an exhaustive mapping of your servers, whether physical, virtualized on-premise, or already in a hybrid cloud. For each server or instance, document the operating system, the processor, the RAM, the disk storage, the network interfaces, and above all the business role it plays. Do not rely solely on procurement documents dating back three years; go into the field and verify the inventory in your hypervisors (vSphere, Hyper-V) or your existing monitoring systems. In parallel, identify all your databases: MySQL, PostgreSQL, Oracle, SQL Server, MongoDB, and so on. For each one, note the version, the storage footprint, the typical number of connections, and whether it is clustered or standalone. Do not forget shared file systems, network appliances, load balancers, firewalls, and everything else that supports your applications. This documentation should not remain a static Excel file: it forms the reference baseline on which you will apply workload measurements and that you will keep evolving throughout the migration phases.
Measuring real workloads: CPU, memory, network, and I/O Documenting a server's static configuration is only half the work. You also need to measure how that server behaves in production: how much CPU it consumes on average and at peak, how much memory, what network throughput, and above all what its disk I/O profile looks like. This data is essential to properly size the AWS instance types or the EBS/S3 storage classes that will fit. Use your infrastructure's native monitoring tools to collect these metrics over a sufficient period: at least two to four weeks, ideally a full month to capture monthly variations and seasonal peaks. If you work with vSphere, use the vCenter data; under Hyper-V, query the host; on physical servers, install lightweight agents (Prometheus, collectd, or the tools of your hyperscaler partner). For databases, do not limit yourself to CPU and memory metrics; also measure IOPS (input/output operations per second) and disk latency, because AWS bills IOPS operations as an extra, and a poor estimate here can double your bill. Also record network throughput between servers (intra-datacenter traffic), between datacenters if there is replication, and between remote users and applications. This workload profile will guide your choice between standard instance classes (M5, C5), compute-optimized, memory-optimized, or storage-optimized depending on your dominant workload.
Quantifying current costs and projecting AWS costs Now that you have measured your workloads, quantify what they cost you today. For an on-premise infrastructure, that includes the amortization of servers and storage over 4 to 5 years, power consumption, cooling, datacenter space rental if needed, software licenses (especially databases, ERP, or Windows OS), and the direct costs of vendor support and maintenance. Many organizations forget to factor in electricity consumption or the implicit cost of the full-time staff dedicated to managing this estate. Once you have this figure, use the AWS TCO Calculator (free) to simulate the same estate on AWS with the measured workloads. Enter each server type (CPU, RAM) with its average and peak load, the storage volumes, the software licenses you will have to reacquire (or not), the estimated outbound bandwidth, and the AWS managed services you are considering (RDS for databases, ELB for load balancing, and so on). The TCO Calculator will give you an annual AWS cost across on-demand, reserved instances, and savings plans, which lets you compare directly. Do not forget that some elements, such as Oracle or SQL Server licenses, can be reused on AWS through BYOL (Bring Your Own License) programs, reducing extra costs. This comparison quantifies the ROI of the migration and helps leadership decide on the timeline and budget.
Identifying dependencies and migration blockers Measuring workloads is technical; identifying dependencies is strategic. During the audit, trace the data and communication flows between applications and systems. Some applications depend heavily on very low-latency network connectivity to an on-premise database, or on a legacy system that you cannot (or will not) migrate immediately. Others generate a lot of outbound traffic to external partners and could be expensive in AWS bandwidth. Also identify applications that require non-portable proprietary licenses, those that require specific regulatory compliance (HIPAA, PCI-DSS, GDPR), or those that are so critical that any downtime is unacceptable and an instant cutover strategy is required. Also document human and organizational dependencies: do you have a team capable of running Kubernetes in production, or should you move toward AWS managed services to reduce the learning curve. These dependencies and blockers will determine your migration strategy (lift-and-shift, replatform, refactor) and your critical dependencies within the migration scope that will later be detailed in the phased plan. Without this overview, you risk committing to a migration only to realize too late that a key application cannot be moved without major architectural work.
Structuring audit data for the sizing phase The audit produces a mass of raw data that must be structured to serve as the foundation for the sizing phase (described in detail in the article on sizing the target AWS infrastructure). Organize this data according to a standardized model: a spreadsheet or database per resource type (servers/instances, databases, storage, network), with columns for static configuration (model, vCore, RAM, disk), measured workloads (average, 95th percentile, peak), current costs, and dependency notes. Validate this data with your technical teams: an error here propagates downstream. Also create a three to five page executive summary that synthesizes the main inventories, current costs, dominant workloads, and the main risks or blockers identified. This summary serves to obtain leadership's agreement before launching the sizing and migration phases. Keep the audit up to date during the early migration phases, especially if applications or workloads change or are retired; the audit data remains your reference point for assessing whether the actual costs in AWS production match your projections. If significant gaps appear, it is a signal that the sizing needs refinement or that underestimates need to be identified.
Tooling the audit: tools and partners Conducting a solid audit does not mean doing everything manually. AWS offers free tools that accelerate the process. AWS Application Migration Service (MGN) includes a lightweight agent deployable across hundreds of servers to automatically capture configuration and workload; AWS Data Center migration tooling helps import inventories from your existing management tools (vCenter, System Center, Hyper-V). Upstream, third-party tools such as CloudMapper, Cloudcraft, or Turbonomic offer graphical visibility and sizing recommendations. For databases, AWS Database Migration Service (DMS) can scan a remote database to estimate its size and complexity before migration. However, no tool replaces manual rigor and dialogue with the business owners of the applications. Some teams prefer to entrust this audit to an AWS partner or a third party specialized in migration (such as Stralya) that has a proven methodology, can validate technical assumptions, and provides an unbiased diagnosis. The time invested in a robust audit is quickly recovered by avoiding failed deployments, emergency resizing in production, or surprise bills three months in. A solid audit is therefore an investment, not a cost.