AWS Migration Readiness Assessment: What to Check Before You Start

AWS Migration Readiness Assessment: What to Check Before You Start

Most AWS migrations that go wrong were not poorly executed. They were poorly assessed. The technical team knew how to move workloads. Nobody had mapped what those workloads actually did, who depended on them, or what breaking them would cost.

A readiness assessment is not a formality. It is the work that turns a migration plan from a guess into a project with known risks and a defensible timeline.

Why Readiness Assessment Gets Skipped

The pressure to start is almost always stronger than the pressure to assess. Leadership sees migration as an infrastructure upgrade, not a business risk event. Engineers want to get into the interesting work. The assessment looks like delay.

It is the opposite. A day spent on readiness typically recovers a week of rework post-migration. For regulated businesses, the stakes are higher: an undiscovered compliance dependency or an unassessed database coupling can halt a migration entirely mid-flight.

Do the assessment.

The Eight Checks That Matter

1. Application inventory and dependency mapping

You cannot migrate what you have not catalogued. Start by listing every application, service, and workload in scope. For each, document:

• What it does and who uses it
• What it talks to (databases, APIs, other services, on-premise systems)
• What talks to it (upstream dependencies)
• Expected traffic volumes and peak behaviour

Dependency mapping is where most assessments underestimate effort. A typical tech-led business has far more lateral service communication than its architecture diagrams suggest. Use network flow logs, APM traces, or a discovery tool like AWS Application Discovery Service to build an accurate picture rather than relying on documentation that is usually months out of date.

2. Data classification and compliance scope

Before a byte moves to AWS, you need to know what kind of byte it is. Data classification determines which workloads carry regulatory obligations and therefore which require additional controls during and after migration.

For UK and Irish businesses, the relevant frameworks are typically UK GDPR, FCA operational resilience rules, PCI DSS (if you handle card data), and DORA (if you operate within EU financial services). Each has specific requirements around data residency, encryption, audit logging, and third-party risk management.

An ICT provider is in regulatory scope under DORA. That means AWS itself is a regulated third party, and your migration plan needs to account for evidence of due diligence, not just technical completion.

3. Target architecture decision

Migration is not just a change of hosting location. The method you choose determines complexity, timeline, cost, and what you get at the end.

The main patterns:

Rehost (lift and shift): Move the workload as-is to EC2 or containers. Fast, low risk, minimal AWS benefit. Suitable for workloads with tight timelines or complex licensing.

Replatform: Make targeted adjustments without re-architecting. Move from MySQL on-prem to Amazon RDS, for example. Moderate effort, meaningful operational benefit.

Refactor/re-architect: Redesign to take advantage of cloud-native services. Highest effort, highest long-term benefit. Appropriate for strategic workloads with a longer runway.

Retire or replace: Some workloads should not be migrated at all. This is often the highest-value output of a readiness assessment.

Decide the pattern per workload, not per project. A single migration typically uses all four.

4. Network architecture and connectivity

How will your AWS environment connect to what stays on-premise? Options include:

• AWS Direct Connect: Dedicated private link. High reliability, predictable latency, higher cost and setup time.
• Site-to-Site VPN: Lower cost, faster to establish, subject to public internet variability.
• Hybrid DNS: If services need to resolve on-premise hostnames from AWS or vice versa, DNS architecture needs planning before migration day.

Map every integration that crosses the boundary. This includes monitoring agents, backup agents, authentication systems, and any service that phones home.

5. Identity and access architecture

Cloud IAM is not the same as Active Directory. Most organisations migrating from on-premise infrastructure need to decide how identities will work in AWS before they start moving workloads.

Key questions:

• Will you federate with an existing identity provider (Okta, Azure AD, Google Workspace)?
• How will human and machine identities be separated?
• What is the IAM permission model for different teams?

Getting IAM wrong at migration creates access debt that becomes expensive to unwind. Define your model early and apply it consistently from day one.

6. Observability readiness

You cannot migrate into a black box. Before the first workload moves, define how you will monitor it in AWS. What metrics, logs, and traces will you collect? Where will they go? Who will act on alerts?

This is particularly important for teams moving from an on-premise monitoring stack to cloud-native tooling. The gap between your current visibility and your post-migration visibility needs to be zero on go-live day, not closed two weeks afterwards.

If Datadog is your observability platform, the AWS integration, infrastructure agent deployment, and log forwarding configuration should all be tested in your staging environment before production migration begins. A 60% reduction in MTTR from unified observability is only achievable if observability is in place before incidents occur.

7. Operational model and runbooks

Who operates this workload after it migrates? Are their processes documented? Do they know how to respond to a failure in the AWS environment?

If you are moving from a managed on-premise environment to self-managed AWS, this is a significant capability gap. It is better to identify it in the assessment than discover it during an incident.

Runbooks for common failure modes, escalation paths, and on-call responsibilities need to exist for every production workload before migration.

8. Cost baseline and landing zone budget

Establish a cost baseline for each workload before migration. Know what it costs to run on-premise so you can benchmark against AWS. Use the AWS Pricing Calculator to estimate target-state costs.

Set up AWS Budgets with alerts before go-live. Surprise bills in the first month after a migration are common and avoidable. Tag every resource as part of the migration process, not as a post-migration cleanup task.

Prioritising What to Migrate First

Not everything should move at once. Use the readiness assessment to build a migration wave plan:

• Wave 1: Low-risk workloads with no external dependencies. Dev/test environments, internal tools. Builds confidence and AWS familiarity.
• Wave 2: Production workloads that are well-understood, with clean dependency maps and no compliance complications.
• Wave 3: Complex, high-risk, or heavily regulated workloads. By this point your team has real AWS operational experience and your environment is proven.

Resist the temptation to start with the most strategically important workload. Start with what is safest to learn on.

AWS Tools That Support the Assessment

AWS provides several services to support readiness work:

• AWS Application Discovery Service: Automated inventory and dependency mapping for on-premise servers.
• AWS Migration Hub: Central tracking for migration progress across tools and waves.
• AWS Well-Architected Tool: Framework review against six pillars (operational excellence, security, reliability, performance, cost, sustainability). Useful for identifying gaps before migration.
• AWS Migration Evaluator: Financial modelling for migration business case.

These tools reduce manual effort but do not replace judgement. The dependency map a tool produces still needs a human to interpret it.

Where Critical Cloud Comes In

Running a migration readiness assessment rigorously, then managing the migration itself while keeping production stable throughout, is operationally demanding. Most engineering teams do it once. We have done it for businesses across financial services, fintech, healthcare and the public sector.

Critical Cloud's FETCH engagement is built for exactly this: a structured discovery and migration programme that establishes your AWS environment correctly from the start, with Datadog observability running from day one. See how it works.