How to Perform an AWS Cloud Migration Assessment

AWS cloud migration is a complex task, and without proper planning, it can become unpredictable, expose the project to unnecessary risks, and ultimately cost more than expected. Business, operational, current infrastructure, and budget factors all need to be weighed before you move a single workload. So obviously a quick check won’t cover that.

That’s why you need an assessment: understanding which parts of your infrastructure and applications are ready to migrate, which ones have dependencies or limitations that could cause problems, and what the migration will actually cost.

The goal of the assessment is to identify the current limitations, dependencies, and required changes needed to make the AWS migration feasible within the planned budget. Skip it, or rush it, and you lose predictability, not the problems. They just show up later, mid-migration, as delays nobody planned for.

This article breaks down how to run a cloud migration assessment properly: what to look at, in what order, and what a solid assessment should leave you with before you migrate a single workload.

Reasons to Conduct Migration Assessment

The cloud migration assessment is most useful when the question is no longer simply whether to move to AWS or another cloud provider, but how to do it without carrying existing infrastructure problems, technical debt, and unnecessary costs into the cloud. .

You should consider a migration readiness assessment when you:

• Have complex infrastructure with unclear dependencies . Existing environments include multiple applications, databases, environments, or legacy systems with complex or undocumented dependencies. Before migration, you need to understand how these components interact and identify potential issues that could make the migration more difficult or risky.
• Unclear what is actually ready to migrate . You need to understand which workloads can migrate as-is, which require changes, and which may need modernization or replacement.
• Significant technical, security, or operational risks . Existing technical debt, security requirements, performance issues, compliance constraints, or dependencies could impact the migration.
• Planning a large-scale or multi-phase migration . The migration involves multiple environments or business-critical workloads where downtime or disruption could have a significant impact. A readiness assessment helps define migration waves, dependencies, risks, and the required approach to minimize business disruption.
• You need a realistic migration budget . You need a clear understanding of the total migration cost, including infrastructure, data transfer, tooling, engineering effort, and ongoing AWS operating costs. A readiness assessment helps identify potential hidden costs, estimate the expected investment, and determine whether the migration can be delivered within the planned budget.

In each case, the assessment turns a general migration goal into a concrete plan: identifying where the real savings are, which workloads should move first, and what potential limitations or risks need to be addressed before they become blockers.

What Does AWS Recommend Assessing Before Migration?

AWS developed their own practice called AWS Cloud Adoption Framework (CAF). The CAF applies to cloud transformation broadly. It groups cloud readiness into six perspectives:

• Business – whether the migration supports real business outcomes, not just a technical upgrade.
• People – whether the team can operate in AWS, not just migrate to it.
• Governance – how cloud initiatives are managed, budgeted, and kept accountable.
• Platform – current infrastructure and application architecture, and what needs to change to run well on AWS.
• Security – data protection, access control, and compliance requirements.
• Operations – whether the organization can support and monitor workloads post-migration.

For migration specifically, AWS applies these six perspectives through a Migration Readiness Assessment (MRA) : a structured process that turns them into a concrete list of readiness gaps and an action plan to close them before workloads move.

AWS also provides tooling for the discovery and analysis work, such as:

• AWS Transform – AI-assisted infrastructure analysis, right-sizing, cost modeling, and migration-strategy recommendations.
• AWS Transform Discovery Tool – automated discovery of infrastructure, utilization, database, and dependency data.
• AWS Migration Evaluator – utilization analysis, TCO comparison, and a migration business case.
• AWS Optimization and Licensing Assessment (OLA) – licensing analysis, particularly for Microsoft/Windows workloads.

These tools handle data collection and analysis. They sequencing against business priorities, whether a compliance obligation changes the target architecture, which trade-offs the organization can accept. However, that part still depends on people who understand both AWS and the business behind the migration.

In-House Assessment or Outsourcing to an AWS Partner

Fixing issues discovered after migration has started is usually far more expensive than identifying them during a proper assessment. That’s worth keeping in mind before deciding who runs it.

Running the assessment in-house is realistic if your team has done more than general cloud work. Dependency mapping across legacy or hybrid environments, AWS-specific TCO modeling, and licensing analysis for platforms like Windows or SQL Server all require hands-on migration experience. Teams without that background often complete an assessment that looks thorough but misses something specific: an undocumented dependency, a licensing cost that only shows up post-migration, or a security gap that gets carried into AWS unchanged.

Outsourcing the assessment gets you more than an extra set of hands. An AWS partner that conducts regular assessments has already gained experience in areas where it’s easy to make a mistake the first time around. They know what “done” looks like for dependency discovery, have a working model for comparing current infrastructure cost against AWS rather than a rough guess, and have gone through the process of turning findings into a sequenced migration plan rather than a static report.

Romexsoft runs AWS Migration Readiness Assessments that produce exactly the deliverables outlined at the end of this article: a readiness report, a prioritized gap list, a migration strategy per workload, a TCO comparison, and a sequenced roadmap.

Contact Romexsoft to scope an assessment for your environment.

How to Perform a Cloud Readiness Assessment

A useful cloud readiness assessment should show what needs to change, which migration approach fits the workload, where the main risks are, and whether the move makes financial sense.

The flow below is based on AWS guidance and supported by practical lessons from migration projects Romexsoft has delivered. Each step focuses on what to check and how the findings should influence the migration plan.

Understand the Migration Goals and Constraints

This might sound like an obvious starting point, but skipping it is exactly why so many migrations end up technically fine and strategically disappointing. Before any technical work starts, the assessment needs to answer a basic question:

• What is this migration actually supposed to achieve?
• What’s constraining how you get there?

Goals vary widely: cutting infrastructure costs, gaining elasticity to handle demand spikes, improving reliability, or supporting a broader modernization plan. At the same time, every migration has constraints that shape what is realistically possible – budget and timeline, required uptime, compliance and security requirements, existing technology, team capabilities, application dependencies, or the need to keep parts of the current infrastructure running during the transition. For example, we had a client who was paying high hosting costs for a platform that still couldn’t deliver the scalability they needed, and that single constraint shaped the entire direction of the assessment that followed.

Assess the Current Applications and Infrastructure

Once the migration goals are clear, build a reliable picture of the current environment you are planning to move to. AWS recommends documenting the applications and their supporting infrastructure, including compute, storage, networking, databases, environments, software versions, performance data, criticality, known issues, and dependencies. This should also include information of current on-premises compute and data resources – such as CPU, memory, storage capacity, utilization, and data volumes – to understand actual resource consumption and establish a reliable baseline for sizing the target AWS environment. To carry out more detailed assessments, it is important to pay special attention to the analysis of dependencies, as unidentified connections between systems can complicate the migration process or require last-minute changes.

But don’t treat this stage as a simple inventory exercise. You also need to understand how the current environment behaves in practice and what is already causing problems .

We have seen this distinction across our own migrations. Before moving Gorgany from OVHcloud , our specialists analyzed the existing infrastructure and used the findings to prepare the AWS migration plan. The analysis had to account for an application and database running on the same server, limited scalability, security issues, and the application’s monolithic architecture.

Here are a few helpful tips:

• Document problems, not just resources. A list of servers and applications tells you far less than knowing which of them are already fragile, why, and what happens if that fragility carries over into AWS unchanged.
• Map dependencies before deciding what moves together. Pay particular attention to databases, internal services, third-party integrations, networking, and connections between cloud and on-premises components. AWS also recommends validating dependency information with programmatic discovery where possible rather than relying entirely on documentation or institutional knowledge.
• Look at actual workload behavior. Performance requirements, peak periods, resource utilization, recovery needs, and operational processes help determine whether the existing architecture can simply be moved or should be changed during migration.

Identify Migration Risks and Readiness Gaps

Once you understand the current environment, the next step is to identify what could make the migration difficult, risky, or unnecessarily expensive. For each gap, decide whether it’s a blocker that must be resolved before migration, or an opportunity that can be addressed later. This turns the assessment into an actionable plan rather than a long list of findings with no clear next step.

So focus on the gaps that can affect the migration outcome directly.

• Separate migration blockers from modernization opportunities. Not every weakness discovered during assessment has to be fixed before migration. Some issues, such as unsupported dependencies, security vulnerabilities, connectivity constraints, missing backup procedures, or single points of failure, may create direct migration risk and should be addressed early. Others, such as introducing containers, autoscaling, managed services, or more advanced observability, may be improvements that can be implemented during or after the move.
• Look for risks created by the existing architecture, not only individual components. A server may be healthy on its own but still represent a risk if it hosts both the application and database, cannot scale independently, or creates a single point of failure, as was the case with Gorgany’s OVHcloud environment before migration . Similarly, hybrid environments may introduce dependencies, latency, recovery, or operational issues that only become visible when you look at the architecture as a whole.
• Assess operational readiness as carefully as technical readiness. Ask and note how the environment is monitored today, how incidents are handled, how backups are restored, how access is managed, and what happens when a critical component fails. Migration to AWS will not automatically resolve weak operational processes if they are simply carried over from the existing environment.
• Prioritize gaps by business impact. Give the highest priority to issues that could cause downtime, data loss, security exposure, migration delays, or unpredictable costs. Lower-impact improvements can be planned for later phases instead of expanding the migration scope unnecessarily.

Identify and Reduce Current Dependencies

Before moving workloads to AWS, it is important to understand not only what each part of the application does, but also what it depends on. Hidden or tightly coupled dependencies can turn a simple migration into a complex one and increase the risk of downtime, unexpected changes, and additional costs.

The assessment should identify:

• Application-to-application dependencies: APIs, shared services, messaging, and integration points.
• Data dependencies: shared databases, file systems, storage, and data replication requirements.
• Infrastructure dependencies: network connectivity, DNS, load balancers, authentication, and shared infrastructure services.
• External dependencies: third-party services, external APIs, payment systems, or other systems outside the environment.
• Opportunities to reduce dependencies: removing obsolete integrations, separating shared resources, and decoupling tightly connected components before migration.

Reducing unnecessary dependencies before migration makes workloads easier to move, test, operate, and scale independently in AWS.

Choose the Migration Strategy and Target AWS Direction

With the current environment, dependencies, and readiness gaps documented, you can start deciding how each workload should move to AWS and what it should look like after migration.

AWS defines seven common migration strategies, known as the 7 Rs: rehost, relocate, replatform, repurchase, refactor or re-architect, retain, and retire. The right choice depends on the business goals you defined earlier, the condition of the existing workload, its dependencies, migration constraints, and how much change you want to introduce as part of the move. Here’s how that played out across three of our own migrations:

• Rehost for Gorgany . The priority was resolving scalability and security issues quickly without a full architectural overhaul, so we performed a lift-and-shift migration to AWS, moving the existing setup onto EC2, Aurora RDS, and VPC without changing the application itself first. The plan for splitting the monolith into microservices came after, as a separate phase.
• Replatform fo r CorporateGift’s ecommerce platform . The monolithic, single-server setup identified during assessment wasn’t viable to simply lift and shift. The application was containerized and moved to ECS Fargate with Aurora Serverless, gaining scalability and cost efficiency without a full rewrite.
• Refactor i n our monolith-to-microservices project . The assessment findings pointed toward a deeper architectural change. The application was broken into services running independently, which the existing monolithic structure couldn’t support without a redesign.

We defined a few principles that are particularly useful when choosing the migration strategy:

• Don’t modernize simply because you’re moving to AWS. If the existing application can meet its requirements after a straightforward rehost, adding architectural changes may introduce unnecessary cost and migration risk. At the same time, don’t assume rehosting is automatically safe: reproducing an architecture that already has scalability, availability, or operational limitations just carries those same problems into AWS. The findings from Steps 2 and 3 are what tell you which side of that line a given workload falls on.
• Design the target state around requirements, not around the current infrastructure. Use the source architecture as an input, but don’t automatically reproduce it service for service in AWS. Consider the availability, scalability, security, recovery, performance, operations, and cost requirements identified earlier and determine which AWS architecture can meet them with the least unnecessary complexity.

Estimate Costs and Build the Migration Business Case

By this point, you know what you have, what’s risky, and what strategy fits each workload. The last step is turning all of that into something a business actually acts on: a cost comparison, a sequence for the migration, and a case that justifies moving forward. This is where the assessment produces its most tangible output.

AWS offers the AWS Pricing Calculator for estimating total cost of ownership (TCO), which allows you to compare your current infrastructure costs with the projected costs of running the same workloads on the AWS platform. This comparison can range from a relatively simple “current state vs. AWS” cost analysis to a broader business analysis that also takes into account migration costs, return on investment (ROI), payback period, and expected business outcomes.

A few things are worth keeping in mind when doing this:

• Compare AWS with the full cost of the current environment, not just the hosting bill. Depending on where the workload runs today, this can include infrastructure or platform fees, software licenses, storage and data transfer, backup and recovery, maintenance, support, and the engineering effort required to operate the environment. In our on-premises-to-AWS migration case , for example, fixed infrastructure capacity also created operational overhead and required resources to be provisioned for peak demand. Moving to elastic AWS services allowed infrastructure spending to align more closely with actual usage.
• Base the AWS estimate on actual workload data where possible. Resource utilization, storage volumes, traffic patterns, database requirements, and peak demand gathered during discovery can produce a more realistic estimate than simply matching existing server specifications with equivalent AWS instances. AWS business-case tools can also support rightsizing and cost-optimization scenarios based on the current environment.
• Include the cost of getting there. The target AWS run rate is only part of the equation. Account for migration engineering, data transfer, testing, temporary parallel environments, modernization work included in the migration, and any operational changes required before cutover.
• Don’t reduce the business case to cost savings alone. A migration may also be justified by improvements in scalability, availability, recovery, security, or the ability to release and grow faster. These benefits should connect back to the business goals defined at the beginning of the assessment.

The roadmap side is just as important as the cost side, and it’s often where assessments fall short. For the roadmap itself, focus on:

• Sequence workloads by risk and dependency, not convenience. Low-risk, low-dependency workloads should generally move first, both to build confidence in the process and to surface issues before they affect anything critical. Workloads with tight dependencies or higher risk belong later in the sequence, once the approach has been validated.
• Tie the roadmap to the chosen migration strategy. A workload being rehosted moves differently, and often faster, than one being refactored. The roadmap should reflect that instead of treating every workload as the same size of effort.
• Make the roadmap decision-ready. The output should give whoever approves the migration a realistic timeline, clear sequencing logic, and the risks being managed at each phase, not a technical summary that still requires interpretation before a decision can be made.

What Should You Get at the End of the Assessment?

A cloud migration readiness assessment should give you a clear, actionable picture of what the migration will require. By the end of the assessment, you should understand what can be migrated, what needs to change, what the migration will cost, and which risks or constraints need to be addressed.

A solid cloud migration assessment should leave you with:

• A readiness report documenting the current infrastructure, applications, and dependencies, based on actual discovery, not assumptions
• A prioritized list of gaps , each with an owner and a next step, not just a description of the problem
• A clear split between migration blockers and modernization opportunities , so the migration scope doesn’t quietly expand
• A migration strategy per workload , based on what the assessment found, not a default approach applied across the board
• A TCO comparison and business case , covering current costs, projected AWS costs, and the cost of migrating itself
• A sequenced roadmap , showing which workloads move first and why
• A target AWS architecture direction , detailed enough to validate the approach and estimate cost, without needing to be a full technical design yet

If one or more of these pieces is still missing, there is likely more assessment work to do before committing to the migration plan. Romexsoft’s AWS Migration Readiness Assessment can provide these deliverables, including a Migration Readiness Report, migration roadmap and strategy, TCO model and financial projections, and target AWS reference architecture.

If you need help turning your migration idea into a clear AWS plan – contact us to discuss your migration goals with our AWS specialists.