Cloud Migration Testing: AWS, Azure & GCP Strategy

Gartner estimates that through 2025, 99% of cloud security failures will be the customer's fault — not the cloud provider's. The root cause is not just misconfigured security groups or IAM policies. The root cause is that organisations migrating to cloud underestimate how comprehensively the cloud environment differs from on-premises, and how thoroughly those differences must be tested before workloads go live.

Cloud migration is not a deployment event. It is a fundamental change to the infrastructure, networking, identity, data, and integration architecture of the systems being migrated. Every assumption that was true on-premises — network latency, storage performance, authentication mechanisms, backup behaviour, licensing — must be re-validated in the cloud target environment. Testing is the mechanism for that validation, and the organisations that skip it discover their cloud environment does not behave as expected during a production incident.

Why Cloud Migration Testing Fails — The Four Most Common Root Causes

• Testing against the wrong environment — a cloud migration test that runs against an under-provisioned or incorrectly configured test environment produces results that do not predict production behaviour. The test environment must be production-equivalent in instance types, network topology, security group configuration, IAM policies, and data volume. Organisations that cut costs by testing against a smaller environment consistently discover that production behaves differently.
• Integration testing deferred too late — cloud migrations break on-premises integrations in ways not obvious from architecture diagrams. IP-based network rules must be replaced with cloud-native security group rules or private endpoint configurations. Service discovery mechanisms change. DNS resolution behaves differently in VPC environments. Integration testing deferred until after migration adds weeks to the timeline when breaks are discovered at the worst time.
• Performance tested at wrong data volumes — cloud storage I/O characteristics differ significantly from on-premises SAN or NAS storage. Databases that performed well on-premises may behave differently on EBS, Azure Managed Disks, or GCP Persistent Disk — particularly for I/O-intensive batch or analytics workloads. Performance testing must run at production data volumes with production-representative I/O patterns.
• Security posture not validated end-to-end — the cloud shared responsibility model places significantly more security obligation on the customer than many organisations realise. Security testing that validates only perimeter controls misses IAM misconfiguration, overly permissive service account policies, unencrypted data in transit between cloud services, and logging and monitoring gaps.

The Cloud Migration Testing Framework: Five Phases

• Phase 1 — Pre-migration assessment and baseline: Establish the performance, availability, and integration baseline of the source system before migration begins. Document all integration points, dependency maps, current performance SLAs, and security controls. This baseline is the benchmark against which cloud performance will be measured.
• Phase 2 — Infrastructure and environment validation: Validate that the cloud target environment is correctly provisioned and configured before migrating any workloads. Instance type validation, network connectivity testing across VPC peering and private endpoints, IAM policy validation, storage configuration testing, DNS resolution validation, and certificate management verification.
• Phase 3 — Data migration validation: Validate the completeness, accuracy, and integrity of migrated data. Row count reconciliation between source and target databases, hash-based data integrity checks, schema validation for structural changes, referential integrity validation for foreign key relationships, and spot-check sampling of migrated records against source data.
• Phase 4 — Integration and functional testing: Validate that all applications and integrations function correctly in the cloud environment. End-to-end business process testing, API integration testing against cloud-hosted endpoints, authentication and authorisation testing (particularly SSO and identity provider integrations), and third-party service connectivity.
• Phase 5 — Performance, load, and security testing: Validate that the cloud environment meets performance SLAs under production load, that security controls are correctly implemented, and that disaster recovery and backup mechanisms work as expected. This phase is the most commonly compressed under schedule pressure — and the one that produces the most expensive production incidents when skipped.

AWS Migration Testing: What Australian and US Enterprises Must Validate

• EC2 instance type performance validation — migrating from on-premises servers to EC2 involves instance type selection that may not perfectly replicate on-premises CPU characteristics. Graviton3 (ARM) instances offer better price-performance for many workloads but require application compatibility validation. Performance testing must validate that selected instance types meet CPU, memory, and network throughput requirements under production load.
• EBS and storage performance testing — EBS volume types (gp3, io2, st1) have different throughput and IOPS characteristics. Database workloads that relied on on-premises SAN performance may require io2 Block Express provisioned IOPS to meet latency SLAs. Storage performance testing must validate I/O-intensive operations against the selected EBS configuration.
• RDS and Aurora migration testing — database migrations to RDS or Aurora require schema compatibility validation (particularly Oracle-to-Aurora or SQL Server-to-RDS PostgreSQL migrations), stored procedure and trigger behaviour validation, query performance testing using production-representative query loads, and replication lag testing for multi-AZ deployments.
• AWS Lambda and serverless testing — applications migrating to serverless on Lambda require cold start latency testing, concurrent execution limit testing, timeout behaviour validation, and memory configuration optimisation. Lambda cold starts under peak load are a common production performance surprise for teams that did not specifically test serverless scaling.
• IAM and security posture validation — IAM policy validation confirms least-privilege access for all service accounts, EC2 instance profiles, and Lambda execution roles. Security testing includes IAM privilege escalation path analysis, S3 bucket policy validation, and VPC security group rule review against the approved network segmentation design.

Azure Migration Testing: Microsoft-Stack Enterprise Considerations

• Azure Active Directory and Entra ID integration testing — Azure migrations shifting authentication to Azure AD or Microsoft Entra ID require SSO federation testing, Conditional Access policy validation, MFA enforcement testing, and legacy authentication protocol blocking validation for applications still using basic auth
• Azure SQL and managed database testing — migrations from SQL Server on-premises to Azure SQL Managed Instance or Azure SQL Database require T-SQL compatibility testing, linked server and distributed query testing, SQL Agent job migration validation, and Always On availability group configuration testing
• Azure Virtual Network and hybrid connectivity testing — enterprise Azure migrations include hybrid connectivity via ExpressRoute or VPN Gateway. Testing must validate bandwidth, latency, and failover behaviour of the hybrid connectivity layer under load — frequently the performance bottleneck for hybrid workloads
• Azure Kubernetes Service (AKS) testing — containerised workloads migrating to AKS require cluster autoscaling validation, pod disruption budget testing, persistent volume claim performance testing, and network policy validation. AKS scaling behaviour under rapid load increase must be specifically tested
• Azure Monitor and observability validation — migrated workloads must emit the right telemetry to Azure Monitor, Log Analytics, and Application Insights. Observability validation confirms alert rules trigger correctly under test conditions and dashboards reflect production-representative metrics

Performance and Load Testing in Cloud Environments: The Hidden Complexity

• Auto-scaling behaviour under load — cloud auto-scaling is not instantaneous. EC2 Auto Scaling Groups, Azure VM Scale Sets, and GCP Managed Instance Groups all have launch latency (typically 2–5 minutes). Performance testing must validate that the application scales fast enough to handle rapid traffic increases without degrading response times during the scale-out window.
• Burstable instance type testing — AWS T-series and Azure B-series instances accumulate CPU credits at idle and spend them under load. Applications on burstable instances sustaining high CPU utilisation will deplete credit balances and throttle to the baseline rate — causing severe performance degradation visible only in extended-duration tests of 4–8 hours or more.
• Cloud storage I/O performance — EBS throughput and IOPS limits, Azure Managed Disk performance tiers, and GCP Persistent Disk limits can become bottlenecks for I/O-intensive workloads. Database query performance, batch throughput, and backup/restore times must be tested at production data volumes.
• Cross-AZ and cross-region latency testing — applications distributing workloads across availability zones incur AZ-to-AZ network latency (1–3ms). Applications spanning regions for disaster recovery incur significantly higher inter-region latency. These latency characteristics must be incorporated into performance test design and validated against application SLAs.

Cloud Security Testing: What Changes When You Move to AWS, Azure or GCP

• Identity and access management posture — cloud IAM is significantly more complex than on-premises Active Directory. Testing must validate least-privilege access for all human identities, service accounts, and machine identities; privilege escalation path analysis; and cross-account access policies in multi-account AWS organisations or Azure Management Groups
• Network security configuration — security group rules, network ACLs, VPC endpoint policies, and WAF configurations must be validated against the approved network segmentation design. Cloud penetration testing should include metadata service exploitation (SSRF via IMDSv1), overly permissive security group rules, and S3 bucket access testing
• Data protection in transit and at rest — encryption configuration must be validated for data at rest (EBS encryption, S3 SSE, Azure SSE, GCP CMEK) and in transit (TLS configuration, certificate validity, protocol enforcement). Applications transmitting data between cloud services without encryption are a compliance failure in regulated industries
• Cloud security posture management — continuous assessment against CIS AWS Foundations Benchmark, CIS Azure Benchmark, and CIS GCP Benchmark validates that cloud configuration has not drifted from the approved security baseline. Automated posture testing should be implemented in the CI/CD pipeline for infrastructure-as-code changes