4.2 Pre-Migration Workload Assessment & Sizing
Key Takeaways
- Application discovery and dependency mapping uncover complex multi-tier network relationships, database links, and authentication dependencies to avoid breaking interconnected services during wave migrations.
- Performance baseline profiling requires capturing 95th and 99th percentile utilization metrics over extended multi-week cycles for CPU, RAM, disk IOPS/throughput, and network I/O to right-size cloud instances.
- Compatibility assessments verify hypervisor guest driver support, 32-bit versus 64-bit architecture, OS kernel versions, and external hardware dependencies (e.g., physical USB licensing dongles).
- Licensing assessments evaluate Bring Your Own License (BYOL) against License-Included models, mapping on-premises physical core/socket rights to cloud virtual CPUs (vCPUs) and dedicated hosts.
- Cloud readiness discovery tools (AWS Application Discovery Service, Azure Migrate, Google Cloud Migration Center) automate telemetry collection using agentless appliances or deep-inspection in-guest agents.
Pre-Migration Workload Assessment & Sizing
A successful cloud migration is built on rigorous, data-driven pre-migration assessments. Migrating workloads without comprehensive dependency mapping and accurate performance sizing leads to broken application dependencies, severe post-migration performance degradation, or massive cloud over-provisioning costs. The CompTIA Cloud+ (CV0-004) exam heavily tests candidate capabilities in discovery methodologies, resource baseline analysis, compatibility validation, and licensing models.
1. Application Discovery & Dependency Mapping
Enterprise application ecosystems rarely operate in silos. A single business transaction may traverse a public load balancer, multiple web frontend servers, application microservices, middleware message buses, backend database clusters, third-party REST APIs, and centralized Active Directory domain controllers.
+---------------------------------------------------------------------------------------------------------+
| MULTI-TIER DEPENDENCY MAPPING ARCHITECTURE |
| |
| [ External Clients / Users ] |
| | |
| v |
| +---------------------------+ TCP Port 443 / 80 +------------------------------------+ |
| | Web Tier Cluster | <============================> | Ingress Load Balancers | |
| +---------------------------+ +------------------------------------+ |
| | |
| | TCP Port 8443 (RPC / REST) |
| v |
| +---------------------------+ TCP Port 389 / 636 +------------------------------------+ |
| | Application Middleware | -----------------------------> | Active Directory / LDAP Auth | |
| +---------------------------+ +------------------------------------+ |
| | |
| | TCP Port 1433 / 1521 / 5432 |
| v |
| +---------------------------+ DBLink / ETL Sync +------------------------------------+ |
| | Primary Transact Database | <============================> | Data Warehouse / Analytics Tier | |
| +---------------------------+ +------------------------------------+ |
| | |
| v NFS / SMB (TCP Port 2049 / 445) |
| +---------------------------+ |
| | Shared Storage SAN / NAS | |
| +---------------------------+ |
+---------------------------------------------------------------------------------------------------------+
Agentless vs. Agent-Based Discovery
| Assessment Parameter | Agentless Discovery | Agent-Based Discovery |
|---|---|---|
| Mechanism | Deploys a virtual appliance (OVA/VHD) connecting to vCenter, Hyper-V, or SNMP/WMI APIs. | Installs a lightweight monitoring daemon inside the guest OS of each target server. |
| Deployment Speed | Extremely rapid; provisions in hours across thousands of VMs. | Slower; requires administrative access and change control approval per host. |
| Performance Profiling | Hypervisor-level CPU, allocated RAM, disk read/write rates, VM interface throughput. | In-guest process-level CPU/memory, actual memory working set, disk IOPS queue depth. |
| Dependency Mapping | Basic network flow data if supported by hypervisor switches (e.g., vSphere Distributed Switch). | Deep process-to-process TCP/UDP connection mapping, listening ports, and destination sockets. |
| Security & Overhead | Zero software footprint on target OS; uses read-only hypervisor credentials. | Requires daemon maintenance, minimal CPU/RAM overhead (< 1%), OS security vetting. |
Critical Move Groups (Migration Waves)
By analyzing dependency graphs, architects group interconnected workloads into Move Groups (also termed Migration Waves). A Move Group consists of all application components that must migrate simultaneously because their inter-service communication is latency-sensitive. For example, if an application server communicates with a database over a chatty protocol requiring < 2 ms round-trip time (RTT), migrating the application server to the cloud while leaving the database on-premises across a hybrid VPN/Direct Connect link (20-40 ms RTT) would introduce catastrophic application timeouts.
2. Performance Baseline Gathering & Sizing Metrics
On-premises environments are notoriously over-provisioned. System administrators historically sized physical servers and VMs for peak projected capacity 3 to 5 years into the future. Translating on-premises allocated resources 1:1 into cloud instance types (as-is sizing) results in massive operational waste. Cloud sizing must be driven by actual utilization baselines (right-sizing).
+---------------------------------------------------------------------------------------------------------+
| ON-PREMISES AS-IS VS. CLOUD RIGHT-SIZED |
| |
| ON-PREMISES ALLOCATED HARDWARE CLOUD RIGHT-SIZED PROVISIONING |
| +---------------------------------------+ +---------------------------------------+ |
| | VM: 16 vCPUs (Avg Util: 8%, Peak: 18%)| | Cloud VM: 4 vCPUs (c6i.xlarge / D4s) | |
| | RAM: 64 GB (Working Set: 12 GB) | --> | RAM: 16 GB (Auto-scales on demand) | |
| | Disk: 2 TB (Provisioned Thick LUN) | | Cloud Storage: 300 GB gp3 SSD | |
| | Actual Data: 220 GB (150 IOPS) | | IOPS Provisioned: 3,000 IOPS Baseline | |
| +---------------------------------------+ +---------------------------------------+ |
| Annual Cost: High Capex Waste Annual Cost: ~70% Cost Reduction |
+---------------------------------------------------------------------------------------------------------+
Core Performance Telemetry Pillars
- CPU Profiling:
- Track average utilization, 95th percentile, and 99th percentile peaks over at least 30 to 90 days to capture end-of-month, quarterly, or seasonal batch spikes.
- Evaluate CPU architecture: Clock speed (GHz) versus core count. High single-thread clock speed requirements may dictate compute-optimized cloud families (e.g., AWS
C-family, AzureF-series).
- Memory (RAM) Profiling:
- Differentiate between Allocated Memory and Actual Working Set (Committed) Memory.
- On-premises operating systems cache files in memory, making memory appear 100% utilized. In-guest agents measure active working pages to determine true memory demand.
- Storage Performance (IOPS & Throughput):
- Sizing storage solely by capacity (Gigabytes) leads to severe I/O bottlenecks.
- Input/Output Operations Per Second (IOPS): Measure peak read IOPS and write IOPS at standard block sizes (e.g., 4 KB, 8 KB, 64 KB).
- Storage Throughput (MB/s): Measure sequential transfer rates (e.g., backup jobs, log exports).
- Storage Type Mapping: Map workloads to General Purpose SSD (e.g., AWS
gp3, AzureStandard SSD), Provisioned IOPS SSD (e.g., AWSio2, AzureUltra Disk), or Throughput Optimized HDD (e.g., AWSst1).
- Network Ingress / Egress:
- Measure sustained and burst network bandwidth (Mbps / Gbps).
- Cloud providers charge for internet data egress and cross-region/cross-AZ data transfer, making historical network egress quantification essential for accurate cloud TCO modeling.
3. Compatibility & Architecture Validation
Before initiating replication, technical feasibility checks must identify blockers that prevent an operating system or application from executing in a cloud virtualized hypervisor.
+-----------------------------------------------------------------------------------------+
| PRE-MIGRATION COMPATIBILITY CHECKLIST |
| |
| [ ] OS Architecture: 64-bit (x86_64 / ARM64) Required. (32-bit x86 unsupported) |
| [ ] Kernel & OS Version: Vendor-supported OS (e.g., Windows 2012R2+, RHEL 7+, Ubuntu) |
| [ ] Boot Mode: UEFI vs. Legacy BIOS partition layout compatibility |
| [ ] Hypervisor Drivers: AWS Nitro / Azure LIS / VirtIO kernel modules installed |
| [ ] Hardware Dependencies: Zero physical USB dongles, serial ports, or custom PCIe |
| [ ] Network Config: Removal of hard-coded static IPs; DHCP cloud overlay alignment |
| [ ] Licensing Model: BYOL compatibility vs. Cloud License-Included mapping |
+-----------------------------------------------------------------------------------------+
Technical Blocker Deep Dive
- 32-Bit vs. 64-Bit Operating Systems:
- Modern cloud hypervisors (e.g., AWS Nitro, Azure Hyper-V/Type-1 Hypervisors, GCP KVM) do not support 32-bit (x86) operating systems. Legacy 32-bit workloads must be upgraded to 64-bit on-premises or containerized before migration.
- Hypervisor Guest Tools & Synthetic Drivers:
- On-premises VMs rely on VMware Tools or Hyper-V Integration Services. When migrated to cloud IaaS, instances require native cloud kernel drivers (e.g., AWS Elastic Network Adapter [ENA], NVMe storage drivers, and Azure Linux Guest Agent).
- Hardware & Peripheral Dependencies:
- Physical security dongles (USB licensing keys for CAD/specialized software), hardware serial ports, direct PCI passthrough devices, and on-premises physical Hardware Security Modules (HSMs) cannot migrate to standard multi-tenant cloud VMs. Software licenses must be updated to software license keys or migrated to Cloud HSM services.
- Software Licensing Models (BYOL vs. License-Included):
- Bring Your Own License (BYOL): Allows enterprises to leverage existing software investments (e.g., Microsoft Software Assurance, Red Hat Cloud Access, Oracle core licenses). Often requires deploying to Dedicated Hosts or Dedicated Instances to comply with socket-based or physical core licensing constraints.
- License-Included (Pay-As-You-Go): The cloud provider bundles the OS and application license into the hourly compute cost (e.g., Windows Server, SQL Server AMI). Eliminates audit liability and software maintenance contracts at the expense of higher variable hourly rates.
4. Automated Cloud Readiness Assessment Tools
Major cloud providers provide purpose-built discovery suites to automate baseline collection and generate comprehensive cloud migration plans:
- AWS Application Discovery Service & AWS Migration Hub: Automates discovery via VMware vCenter Agentless Appliance or in-guest AWS Application Discovery Agents. Aggregates server data into Migration Hub for TCO projections and wave planning.
- Azure Migrate: Provides a unified portal for discovery, assessment, and migration. Deploys the Azure Migrate Appliance to discover VMware, Hyper-V, and physical servers, analyzing performance baselines to recommend Azure VM SKUs, disk types, and cost estimations.
- Google Cloud Migration Center (StrataZone / mFit): Delivers automated discovery, asset inventorying, dependency mapping, and right-sizing recommendations for Google Compute Engine and Google Kubernetes Engine.
5. CompTIA Cloud+ Exam Traps & Real-World Guidance
[!CAUTION] Exam Trap 1: As-Is Provisioning vs. Utilization-Based Sizing
If an exam question asks how to size a target cloud VM for an on-premises database with 32 allocated vCPUs and 128 GB RAM, but monitoring data shows the system never exceeds 12% CPU and 24 GB working memory, the correct answer is to right-size the cloud instance based on historical 95th percentile metrics, NOT to provision a 32-vCPU / 128-GB cloud VM.
[!WARNING] Exam Trap 2: Short-Term Monitoring Windows
Collecting baseline metrics over a 24-hour or 48-hour window is insufficient. It fails to capture cyclical batch processing, weekly reporting jobs, monthly billing reconciliations, and quarterly financial closings. CompTIA questions require multi-week baseline sampling (typically 30+ days).
[!IMPORTANT] Exam Trap 3: Hardcoded Static IP Dependencies
Legacy workloads configured with hardcoded static IP addresses on virtual NICs often fail upon initial cloud boot because cloud software-defined networking enforces IP assignment via cloud DHCP orchestration. Discovery tools must flag hardcoded network configurations for remediation prior to cutover.
A cloud engineer is conducting a pre-migration assessment for a physical server running a proprietary CAD license manager. The application requires a physical USB hardware security key (dongle) connected to the host to authenticate software execution. The engineer plans to rehost this server into a multi-tenant cloud IaaS virtual machine. What issue will occur?
An assessment of an on-premises VMware cluster reveals an internal database server provisioned with 32 vCPUs and 256 GB of RAM. Continuous performance telemetry gathered over 60 days shows the database averages 6% CPU utilization with a 99th percentile peak of 16% CPU utilization, and a peak memory working set of 28 GB. Which sizing recommendation aligns with cloud best practices?
A migration architect needs to discover network dependencies and process-to-process TCP socket connections for a complex multi-tier banking application. Security policies prohibit installing third-party agent software on database servers, but allow it on application web nodes. What discovery approach should the architect implement?