According to Flexera's 2025 State of the Cloud Report, 94% of enterprises now operate in a cloud environment, yet 47% report that cloud spending is significantly over budget. The gap between "we're migrating to AWS" and "our AWS migration delivered the outcomes we planned for" is wider than most organizations realize before they start — and it's almost always attributable to decisions made (or skipped) in the planning phase.

This checklist was built for mid-market IT and operations leaders: organizations with 200–2,000 employees, existing on-premises or collocated infrastructure, and enough complexity that a lift-and-shift won't cut it, but without the dedicated cloud center of excellence that enterprise migration playbooks assume.

The phases below represent the actual AWS cloud migration https://www.nearcontact.com/cloud-services/ journey in sequence. Skip a phase at your peril — the cost of addressing its skipped components grows exponentially the later you catch it.

Phase 1: Migration Readiness Assessment
Before any workload moves to AWS, answer these questions with documentary evidence rather than assumptions:
Inventory your current environment completely. This sounds obvious; it is consistently incomplete. Most mid-market organizations discover 20–40% more servers and services than they documented when they run discovery tools against their actual environment. Use AWS Migration Hub, CloudEndure Discovery, or a third-party discovery tool (Lansweeper, Movere) to scan your environment and generate an authoritative asset inventory. The inventory should capture: server specifications, operating system versions, installed applications, network dependencies, database versions, and estimated utilization patterns.
Classify workloads by migration type. AWS and Gartner popularized the "7 Rs" migration classification framework. For mid-market companies, the relevant tiers are:
Rehost (lift and shift): Move the workload as-is to equivalent AWS infrastructure. Fast, low-risk, doesn't capture cloud-native benefits immediately, but establishes the cloud footprint.
Replatform (lift, tinker, and shift): Migrate with minor optimizations — moving to RDS instead of self-managed SQL Server, or containerizing an app without re-architecture.
Refactor/Re-architect: Rebuild the workload to take advantage of cloud-native capabilities (Lambda, DynamoDB, ECS). High value, high effort — limit to highest-priority workloads in the initial migration.
Retain: Keep on-premises for now (regulatory, latency, or technical dependencies). Document retention criteria and timelines.
Retire: Decommission workloads that are no longer needed. Discovery consistently surfaces 15–25% of workloads as candidates for retirement.
Map application dependencies. The most dangerous assumption in cloud migration planning is that you know how your applications communicate with each other. Build a dependency map — visually — before you define your migration waves. Tools: AWS Application Discovery Service, Dynatrace, or application layer analysis from your monitoring platform. Undiscovered dependencies are the primary cause of outages during migrations.
Assess AWS account structure. For mid-market companies, a multi-account AWS organization using AWS Organizations is the standard best practice. Define your account structure before migration begins: separate accounts for production, development, and staging environments, organized under an organizational structure that allows consolidated billing, centralized logging, and security guardrails via AWS Control Tower.

Phase 2: Cloud Migration Strategy and Architecture
With your inventory and dependency map in hand, your cloud migration strategy defines how you'll execute:
Define migration waves. Order workloads by complexity, dependency, and business criticality. A proven ordering: start with non-production workloads (development, test environments) to build team competency. Move low-complexity, low-dependency workloads next. Reserve complex, high-traffic production workloads for later waves, when your team has real AWS operational experience. Most mid-market migrations run 3–5 waves over 12–18 months.
Design your AWS Landing Zone. A Landing Zone is your pre-configured AWS environment baseline: VPC architecture, network segmentation, security baselines, logging, IAM standards, and governance controls. AWS Control Tower automates Landing Zone configuration with pre-built guardrails. Establish the Landing Zone before any workload migration begins — retrofitting governance and security controls after migration is significantly more expensive and disruptive than establishing them upfront.
Define connectivity architecture. How will your on-premises environment connect to AWS during the migration period (and potentially long-term for hybrid workloads)? Options: AWS Site-to-Site VPN (lower cost, more latency variance), AWS Direct Connect (dedicated private connectivity, 50Mbps–100Gbps, typically 60–90 day provisioning lead time), or AWS Transit Gateway for hub-and-spoke connectivity management. Mid-market organizations typically start with Site-to-Site VPN and plan Direct Connect for production-grade hybrid connectivity.
Establish your cost management framework. AWS cost overruns are predictable and preventable with advance planning. Before workloads migrate: set up AWS Budgets with alerts at 80% and 100% of planned spend, enable Cost Explorer with resource tagging standards that allow cost attribution by department and workload, and define Reserved Instance or Savings Plans commitments based on your right-sizing analysis. Organizations that establish cost governance before migration report 30–40% lower cloud spend variance than those that address it retroactively.

Phase 3: Security and Compliance Baseline
This phase is consistently underestimated in timeline and almost impossible to retrofit at scale:
Identity and access management architecture. Define your IAM strategy for AWS: federation from your existing identity provider (Okta, Azure AD, on-premises AD) via AWS IAM Identity Center (formerly AWS SSO), role-based access control aligned with least-privilege principles, and MFA enforcement for all human user access. Document which roles exist, what they can access, and the process for requesting access changes.
Encryption standards. Define and enforce encryption standards: encryption at rest for all EBS volumes, S3 buckets, and RDS instances using AWS KMS, encryption in transit for all inter-service communication, and key management policies. Enable AWS Config rules to enforce and alert on encryption compliance.
Logging and monitoring baseline. Enable AWS CloudTrail across all accounts and regions (API-level audit logging), VPC Flow Logs (network traffic logging), and configure CloudWatch for operational monitoring. Route logs to a centralized security account with appropriate retention policies. For mid-market organizations with compliance requirements (SOC 2, HIPAA, PCI DSS), this baseline is the foundation for evidence collection.
Compliance mapping. If your industry has specific regulatory requirements, document which AWS services are in-scope and map your control requirements to AWS-native controls before workload migration. AWS has pre-built compliance frameworks in AWS Config Conformance Packs for common standards. Mapping compliance requirements post-migration frequently discovers gaps that require workload re-architecture.

Phase 4: AWS Migration Execution
Execution follows the wave structure defined in Phase 2, with these elements active for each wave:
Migration runbooks for each workload. For every workload being migrated, document: pre-migration state validation steps, migration procedure with estimated duration, rollback procedure and criteria, post-migration validation tests, and success criteria. The runbook should be executable by someone other than the person who wrote it.
Testing protocol. Define acceptance criteria for each migrated workload before migration begins. Post-migration validation should cover functional testing (application behaves as expected), performance testing (response times meet or exceed baseline), integration testing (dependencies function correctly), and security testing (controls are in place and functioning).
Cutover planning. For production workloads, define your cutover approach: big-bang cutover (move everything at once, higher risk, simpler) or parallel run (run old and new environments simultaneously for a validation period, lower risk, higher cost and complexity). Most mid-market production migrations use a parallel run of 1–2 weeks for critical systems. Plan your DNS cutover timing, communication to users, and hypercare support period post-cutover.

Phase 5: Post-Migration Optimization and AWS Migration Best Practices
Migration is not optimization. After workloads are running stably in AWS, a second phase of work captures the cloud-native value that justified the migration:
Right-sizing analysis. Initial lift-and-shift migrations typically over-provision because you're mapping on-premises server specifications to AWS instance types without cloud utilization data. After 2–4 weeks of production operation, run AWS Compute Optimizer analysis and right-size instances based on actual utilization. Typical savings: 20–35% of initial EC2 spend.
Reserved Instance and Savings Plans commitment. After right-sizing, commit 70–80% of stable baseline workload compute spend to Reserved Instances (1-year or 3-year) or Compute Savings Plans. This alone typically generates 30–60% savings versus on-demand pricing on committed workloads.
Cloud-native modernization backlog. Document workloads that were rehosted and are candidates for replatforming or refactoring in the next phase. This becomes your ongoing modernization roadmap, prioritized by cost savings potential, performance improvement opportunity, and operational complexity reduction.

Frequently Asked Questions
How long does an AWS cloud migration take for a mid-market company?
A mid-market migration with 100–500 servers typically takes 12–24 months from initiation to completion of primary workload migration. This includes 2–4 months for assessment and planning (Phases 1–3), followed by migration waves of 4–8 weeks each. Organizations that invest adequately in the planning phases consistently complete migrations faster and with fewer disruptions than those that rush to execution.

What are AWS migration best practices for cost control?
The most impactful cost control practices are: establishing tagging standards before any workload migrates (enabling cost attribution by workload, team, and environment), running Compute Optimizer right-sizing analysis before committing to Reserved Instances, and using Savings Plans rather than instance-specific Reserved Instances where your workload mix is evolving. Organizations that establish cost governance in the planning phase consistently report lower cloud spend variance than those that address it post-migration.

Should mid-market companies use AWS migration consulting?
AWS cloud migration consulting adds clear value in two scenarios: organizations that lack internal AWS expertise and complex migrations with significant regulatory requirements or application interdependencies. The ROI on AWS migration services is typically realized in faster timelines, lower error rates during execution, and governance frameworks that prevent ongoing operational issues. Mid-market organizations most commonly engage AWS migration consultants for the assessment and architecture phases, building internal capability for ongoing operations.

What is an AWS Landing Zone and do mid-market companies need one?
An AWS Landing Zone is a pre-configured, standards-compliant AWS environment baseline — including account structure, network configuration, security guardrails, logging, and governance controls — deployed before workload migration begins. Mid-market companies consistently benefit from establishing a Landing Zone first: organizations that skip this step frequently discover governance and security gaps mid-migration that require workload re-architecture to address, at significantly higher cost and disruption than upfront Landing Zone configuration.

Source: https://news.prbase.org/@adrianzarco/cloud-migration-checklist-for-mid-market-companies-moving-to-aws-cq9k0m08z9od