How do you move a company's entire digital operations – hundreds of servers, databases, and applications – from a physical data centre to the cloud without causing a costly outage or losing critical data? This is the core problem that migration strategies and assessment solve, and for the SAP-C02 exam, you need to know how to plan this move systematically using AWS's proven framework, the 7 Rs of migration (rehost, replatform, refactor, repurchase, retire, retain, and relocate), and the tools that help you discover, plan, and execute each step.
Jump to a section
A simple way to picture Migration Strategies and Assessment
First, you decide to move from your current apartment to a new house, which leads you to carefully plan how to transport all your belongings without breaking anything or losing track of what you own.
Think of your current apartment as your on-premises data centre – the physical servers, storage, and networking equipment you manage yourself. The new house is Amazon Web Services (AWS), a cloud provider where you can rent computing power and storage as needed.
Before the move, you walk through every room with a clipboard, listing everything: from the sofa (a critical database) to the kitchen blender (a minor log file). This inventory process is a migration assessment. You categorise each item: fragile antiques need careful packing (mission-critical applications), old furniture might be better to replace than move (decommission or re-architect), and things you no longer use can be donated (shut down). You also decide on the moving strategy for each item: some heavy appliances go via a specialist moving company (the 'rehost' or 'lift and shift' approach), others get sold and repurchased new at the house (the 'repurchase' or 'drop and shop' approach), and some get redesigned to fit the new home better (the 'refactor' or 're-architect' approach).
During the actual move, you don't just throw boxes onto a truck. You plan the sequence: load the essential items first so you can set up the bedroom (core infrastructure) immediately. You also test that the new house's plumbing and electricity (AWS networking and security settings) work before you unpack the delicate electronics. Finally, after the move, you check that everything is in the right room and working – this is your validation and optimisation phase. This entire process of planning, inventorying, choosing the right strategy per workload, executing the move, and verifying success is exactly what a cloud migration project looks like.
Cloud migration is the process of moving your digital assets – applications, data, and IT infrastructure – from on-premises locations (like a server room in your office) to the AWS cloud. For a total beginner, imagine you run a small bakery. Your 'on-premises' setup is a physical recipe book, a cash register, and a ledger for orders. Moving to AWS means using a digital recipe app, a cloud-based point-of-sale system, and an online order database.
Before you move anything, you must perform an assessment. This is a thorough inventory and analysis of everything you currently run. AWS provides a free tool called AWS Migration Hub and a discovery tool called AWS Application Discovery Service. These tools scan your network to identify every server, every application dependency, and every piece of software you own. This step is vital because you cannot plan a move if you do not know what you have.
Once you know your inventory, you choose how to move each workload (a workload is a collection of resources and code that delivers business value, like an email system or a customer database). AWS and the SAP-C02 exam define seven standard strategies, called the 7 Rs of migration:
Rehost (Lift and Shift): You take your application exactly as it is and move it to AWS without any changes. This is the fastest strategy. For example, you copy your virtual machine image from your on-premises VMware system to Amazon EC2. You might use the AWS VM Import/Export service or AWS Server Migration Service. This is like packing your sofa exactly as it is and putting it in the new house – it works, but it may not be perfectly optimised for the new space.
Replatform (Lift, Tinker, and Shift): You make a few small, cloud-friendly optimisations without changing the core application architecture. For instance, you might move your database from a self-managed Oracle server to Amazon RDS (Relational Database Service) which handles backups and patches for you. This is like replacing the legs of your sofa to make it fit through the new door, but keeping the same couch.
Refactor (Re-architect): You redesign the application to fully use cloud-native features, like breaking a monolithic application into microservices or using serverless compute with AWS Lambda. This is the most time-consuming and expensive strategy, but it yields the best long-term performance and cost savings. It is like building a new custom sectional sofa that uses every inch of the new living room perfectly.
Repurchase (Drop and Shop): You stop using your current software and buy a new, cloud-native version. A classic example is moving from a traditional on-premises CRM (Customer Relationship Management) system to Salesforce or a SaaS (Software as a Service) application. You are not moving the old equipment; you are getting something better.
Retire: You turn off applications that are no longer needed. Many companies find that 10-20% of their servers are doing nothing useful (often called 'zombie servers'). Shutting them down saves money instantly.
Retain (Revisit): You decide to keep some workloads on-premises for now, often due to compliance (legal requirements), latency (need for instant response), or pending application updates. This is a valid decision, not a failure.
Relocate: This is a specific strategy only for moving hypervisor-based environments (like VMware) to AWS on dedicated hardware. AWS offers a service called VMware Cloud on AWS to make this easier.
After choosing your strategy, you execute the migration. AWS provides tools like AWS Database Migration Service (DMS) for moving databases with minimal downtime, and AWS Snow Family for physically shipping large amounts of data via a portable storage device if your internet connection is too slow. Finally, you validate that everything works correctly in the cloud, optimise your new setup for cost and performance, and shut down your old on-premises resources.
Why does this matter for the SAP-C02 exam? The exam will ask you to recommend the correct migration strategy for a given business scenario. You must weigh factors like speed, cost, risk, and business value. For example, if a company needs to move a legacy application quickly because their data centre lease is expiring, 'rehost' is the correct answer. If a company wants to reduce operational overhead, 'replatform' or 'repurchase' may be better. You will also be tested on the correct assessment tools and the order of operations.
Discovery and Inventory
Scan your entire on-premises environment to identify every server, application, database, and their dependencies. Use AWS Application Discovery Service (agentless for VMware, agent-based for other servers). This creates a complete application dependency map, showing which servers talk to which databases, which is critical for creating a safe migration plan.
Assessment and Strategy Selection
Using the inventory data, categorise each workload by business criticality, technical complexity, and compliance requirements. For each workload, select one of the 7 Rs (Rehost, Replatform, Refactor, Repurchase, Retire, Retain, Relocate) based on factors like speed needed, available budget, and technical skills of the team.
Migration Wave Planning
Group workloads into logical migration waves. Start with low-risk, non-critical applications (like internal wikis) to test your migration process. Each wave should include validation steps. Do not attempt to move everything at once – use a phased approach to minimise risk and learn from early waves.
Execution and Data Transfer
Execute the chosen migration strategy for each workload using the appropriate AWS tool: AWS Server Migration Service (for rehost), AWS Database Migration Service (for databases), AWS Snowball (for large data), or manual setup. Ensure data is replicated with minimal downtime using continuous replication where possible (e.g., DMS ongoing replication).
Validation, Cutover, and Optimisation
After migrating a workload, validate that all functionality works correctly in the new AWS environment. Perform a 'cutover' – redirect user traffic from the old on-premises system to the new cloud system. Finally, decommission the old resources, then use AWS tools like Cost Explorer and Trusted Advisor to right-size instances and optimise costs.
Imagine you are a Solutions Architect at a mid-sized financial services company called 'FinSafe'. FinSafe has 200 applications running in a physical data centre that they own. The CEO has announced that the data centre lease expires in 12 months, so everything must be moved to AWS. You are responsible for the migration plan.
Step 1: Discovery and Assessment You start by deploying AWS Application Discovery Service agents on 50 of the most critical servers to understand their dependencies (which servers talk to which databases). You also run AWS Migration Hub to create a consolidated view. During this process, you discover 30 servers that have not been accessed in two years – you immediately flag these for 'retire'. You also find that the main trading application is a monolithic Java app that only runs on a specific old version of Red Hat Linux.
Step 2: Categorising Workloads You create a spreadsheet with all 200 workloads and assign each a migration strategy from the 7 Rs. For example:
The trading application: because it is complex and time is short, you choose rehost. You will use AWS Server Migration Service to replicate the entire server to Amazon EC2.
The customer database (Oracle SQL): you choose replatform. You use AWS Database Migration Service to move it to Amazon RDS for Oracle, so AWS handles backups and patching.
The employee expense reporting tool (an old SaaS product): you choose repurchase. You sign up for a modern cloud-based expense tool like Expensify.
30 zombie servers: you choose retire – you back up any data and power them down.
The core compliance logging system (required by regulators): you choose retain – it stays on-premises until the legal team approves the new cloud-based equivalent.
Step 3: Executing the Migration in Waves You cannot move everything at once. You divide the migration into waves, each wave moving 20-30 workloads. You start with the least critical applications (like the internal wiki) to test your process. After each wave, you run validation tests to ensure the application works. The CRM system fails because it relied on an on-premises Active Directory server that has not been migrated yet. You learn and adjust your plan for the next wave.
Step 4: Using AWS Tools For the database replatforming, you use AWS DMS. It replicates the data continuously, so when you are ready to cut over, the switch takes only a few minutes of downtime. For the large historical trades database (5 TB), the internet is too slow, so you order an AWS Snowball Edge device. AWS ships you a physical box; you load the data onto it, send it back, and AWS uploads it directly to Amazon S3.
Step 5: Optimisation after Migration Once all workloads are moved, you use AWS Cost Explorer to monitor spending. You realise some rehosted EC2 instances are over-provisioned (too much CPU and memory). You right-size them to smaller instance types, immediately reducing monthly costs by 20%. You also set up AWS Trusted Advisor to give you ongoing recommendations for security and cost.
This real scenario shows that a migration is not a single event but a structured, iterative project. As a professional, you would also write a Migration Readiness Assessment (MRA) report, conduct a Well-Architected Review to check the new architecture, and create a runbook for rollback if something goes wrong.
The SAP-C02 exam tests your ability to design a migration plan that meets business constraints and uses the correct AWS services. Here is exactly what you need to know:
1. The 7 Rs of Migration You must know each strategy and when to use it. Expect scenario-based questions like, 'A company has a legacy Windows Server 2008 application. The vendor no longer supports it, but the code cannot be rewritten. The data centre lease expires in 3 months. What is the best migration strategy?' The answer is 'rehost' because speed is critical and no changes are allowed. - Trap: When a question mentions 'reducing operational overhead', many beginners choose 'rehost'. But rehost does not reduce overhead – you still manage the OS. The correct answer for reducing overhead is usually 'replatform' or 'repurchase'. - Trap: 'Refactor' is often the best long-term answer, but the exam will penalise it if time, budget, or skills are constrained. Always read the business constraints first.
2. Assessment Tools and Processes The exam loves to ask about the difference between AWS Application Discovery Service (agentless and agent-based) and AWS Migration Hub (the central dashboard). You must know: - AWS Application Discovery Service: Discovers on-premises servers, their configurations, and dependencies. It can be agentless (VMware) or agent-based (any server). - AWS Migration Hub: Provides a single place to track the progress of migrations across multiple AWS and partner tools. It does not do discovery itself; it aggregates data from other tools. - AWS Database Migration Service (DMS): Moves databases with minimal downtime. Supports homogeneous (Oracle to Oracle) and heterogeneous (SQL Server to Aurora) migrations. - AWS Server Migration Service (SMS): Now known as CloudEndure Migration, it replicates entire servers for rehost migrations.
3. The Migration Readiness Assessment (MRA) This is a formal evaluation of an organisation's people, processes, and technology before migration. The exam may ask: 'Which document identifies the skills gaps in your team before starting a migration?' Answer: Migration Readiness Assessment (MRA).
4. The 3 Common Migration Scenarios - Homogeneous migration: Moving a database from one engine to the same engine (e.g., Oracle to Amazon RDS Oracle). Use AWS DMS with no schema conversion. - Heterogeneous migration: Moving to a different engine (e.g., SQL Server to Aurora MySQL). Use AWS DMS with the AWS Schema Conversion Tool (SCT) to convert the schema. - Large data transfer: If the data volume is huge (over 10 TB) or the internet is slow, use AWS Snowball or Snowmobile (a literal shipping container full of disks).
5. Key Patterns to Memorise - Retain is used for compliance, security, or pending upgrades. It is not a failure. - Retire must always be considered first – turning off unused servers saves money immediately. - Relocate is only for VMware workloads moving to VMware Cloud on AWS. It is not for standard servers. - Repurchase is for when you are replacing an application entirely, not just moving it.
6. Exam Traps to Avoid - Misreading 'lift and shift' as 'replatform'. Lift and shift is rehost. - Thinking 're-architect' is always best because it is modern. The exam tests if you consider cost and timeline. - Forgetting that AWS DMS can be used for ongoing replication (not just one-time migration) to keep databases in sync during cutover. - Confusing AWS Migration Hub with AWS Application Discovery Service. Migration Hub is the dashboard; Discovery Service does the actual scanning.
Study this section carefully – migration questions appear in nearly every SAP-C02 exam, often as part of multi-part scenario questions.
The 7 Rs of migration (Rehost, Replatform, Refactor, Repurchase, Retire, Retain, Relocate) are the standard decision framework for choosing how to move each workload to AWS.
Always start with a thorough assessment using AWS Application Discovery Service to inventory all servers and map their dependencies before choosing migration strategies.
Lift and shift (Rehost) is the fastest and cheapest strategy for migration itself, but it does not reduce long-term operational overhead.
Use AWS Database Migration Service (DMS) for database migrations, and combine it with AWS Schema Conversion Tool (SCT) when moving between different database engines (heterogeneous migration).
For very large data transfers (over 10 TB) or slow network connections, use AWS Snowball or Snowmobile to physically ship the data.
Choosing to 'Retain' a workload on-premises is a valid and strategic decision often driven by compliance, latency, or regulatory requirements.
AWS Migration Hub is a central dashboard to track migration progress, but it does not perform discovery itself.
Always consider the 'Retire' strategy first – turning off unused servers saves money immediately and simplifies the migration.
A successful migration plan balances speed (rehost), cost (retire), operational overhead (replatform), and long-term agility (refactor).
The Migration Readiness Assessment (MRA) evaluates an organisation's skills, processes, and technology before starting a migration project.
These come up on the exam all the time. Here's how to tell them apart.
Rehost (Lift and Shift)
No changes to application code or architecture.
Fastest to implement – weeks or months.
Does not reduce operational overhead; you still manage the OS.
Refactor (Re-architect)
Requires rewriting or redesigning the application.
Slowest to implement – months or years.
Maximises cloud benefits like auto-scaling and serverless.
AWS Application Discovery Service
Scans on-premises servers and maps dependencies.
Can be agentless (for VMware) or agent-based.
Produces a list of discovered resources and their relationships.
AWS Migration Hub
Central dashboard that aggregates data from multiple tools.
Does not perform discovery itself.
Tracks progress of migrations, costs, and status of each workload.
Homogeneous Database Migration
Database engine stays the same (e.g., Oracle to Amazon RDS Oracle).
Uses only AWS DMS; no schema conversion required.
Simpler and faster to execute.
Heterogeneous Database Migration
Database engine changes (e.g., SQL Server to Aurora MySQL).
Requires both AWS DMS and AWS Schema Conversion Tool (SCT).
More complex and time-consuming due to schema conversion.
Replatform (Lift, Tinker, and Shift)
You keep your own application but make minor cloud-optimised changes.
You still manage the application code but not the underlying infrastructure.
Saves on operations like backups and patching for the underlying platform.
Repurchase (Drop and Shop)
You stop using your current application entirely and buy a new SaaS product.
You do not manage any infrastructure or application code.
Best for standardised business functions like CRM or HR systems.
Mistake
Lift and shift (rehost) is always the worst strategy because it does not optimise for the cloud.
Correct
Lift and shift is often the best strategy for speed, especially when a data centre lease is expiring or a company needs to migrate quickly with minimal code changes. It is not inherently bad; it is a trade-off between speed and long-term optimisation.
Many beginners are taught that 'cloud-native' is always superior, but in the real world, business deadlines and budget constraints often make rehost the most practical choice.
Mistake
If you cannot move a workload to the cloud, you have failed the migration project.
Correct
Choosing to retain a workload on-premises because of compliance, latency, or pending upgrades is a completely valid and strategic decision. The exam explicitly tests this – 'retain' is one of the 7 Rs.
There is often pressure to move everything to the cloud, but some workloads genuinely cannot or should not move. Recognising this shows mature architectural judgement.
Mistake
AWS Application Discovery Service and AWS Migration Hub are the same tool with different names.
Correct
They are different. AWS Application Discovery Service performs the actual discovery (scanning servers, mapping dependencies). AWS Migration Hub is a central dashboard that aggregates data from Discovery Service and other migration tools to track progress. You use Discovery Service to discover, and Migration Hub to manage.
The similar names cause confusion. The exam tests this distinction directly, often by asking which tool does discovery vs. which tool tracks progress.
Mistake
Re-platforming means rewriting the entire application from scratch.
Correct
Re-platforming involves making minor, cloud-specific changes – like moving a database from self-managed to Amazon RDS – but without changing the core application code or architecture. Refactoring is the one that involves rewriting.
The prefix 're-' can be confusing. Beginners often think any 're' word means a complete rewrite, but re-platform is much lighter than refactor.
Mistake
The 7 Rs are only relevant for the migration phase, not for planning.
Correct
The 7 Rs are a planning framework. You must choose a strategy for each workload before you start moving anything. The assessment phase produces the list of workloads and the assigned Rs. The migration phase then executes those chosen strategies.
Newcomers often think migration planning is just about inventory, not strategy selection. The 7 Rs force you to decide how each workload will move during the planning stage.
Mistake
If you have a very small amount of data (less than 1 TB), you should always use the internet for migration because it is faster than ordering physical hardware.
Correct
While small data can usually go over the internet, the determining factor is not just size but also available bandwidth and the uptime requirements. If your internet connection is slow or unreliable, even 100 GB can take days, and you might still use a Snowball device to ensure a fast, reliable transfer with minimal impact on production.
Beginners often assume the internet is always the best option for small data, but real-world constraints like shared bandwidth and downtime windows make physical data transfer a valid choice even for surprisingly small datasets.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
AWS Application Discovery Service scans your on-premises environment to discover servers and their dependencies. AWS Migration Hub is a central dashboard that aggregates migration progress from multiple tools, including Discovery Service. Think of Discovery as the surveyor and Migration Hub as the project manager.
Not necessarily. With the 'Rehost' (Lift and Shift) strategy, you move applications exactly as they are without any code changes. Only if you choose the 'Refactor' (Re-architect) strategy would you rewrite the application to take full advantage of cloud-native features.
For large data transfers, use AWS Snowball or Snowmobile. AWS ships you a physical storage device, you copy your data onto it, and then ship it back. AWS then uploads the data directly into your AWS account. This avoids slow internet and reduces potential errors.
Heterogeneous migration means moving a database from one database engine to a completely different one, for example from Microsoft SQL Server to Amazon Aurora MySQL. This requires both AWS DMS (to move the data) and the AWS Schema Conversion Tool (SCT) to convert the database schema (tables, stored procedures) to the target format.
Yes. The 'Retain' strategy in the 7 Rs allows you to keep workloads on-premises indefinitely. This is common for applications with strict compliance requirements, extremely low-latency needs, or that are pending a major upgrade before migration makes sense.
Perform a thorough discovery and assessment of your current environment. Without knowing what servers, applications, and dependencies you have, you cannot create a safe migration plan. AWS recommends starting with the AWS Application Discovery Service to build a complete inventory.
Replatform involves making small, cloud-optimising changes without altering the core application code (like moving a database from self-managed to Amazon RDS). Refactor involves significantly rewriting the application architecture to use cloud-native features like microservices or serverless. Replatform is faster and cheaper; refactor offers better long-term benefits but requires more effort.
You've finished Migration Strategies and Assessment. Continue through the SAP-C02 study guide to build a complete picture of the exam.
Done with this chapter?