The 7 Rs and How to Choose Between Them
Every application in a migration gets one of seven decisions, and picking the right one per application is most of what makes a programme succeed or stall. The strategies run from doing nothing at all to rebuilding from scratch, and both the effort and the payback rise as you move along that line. The mistake the exam tests for is applying one strategy to the whole estate rather than choosing per workload.
Exam tip. Watch the constraint in the question. A hard data centre exit deadline pushes toward rehost or relocate, because refactoring hundreds of applications first is never achievable. A scenario about cost and agility after the move points to replatform or refactor.
Discovery and Wave Planning Before Anything Moves
Migrations fail on dependencies nobody knew about, which is why discovery comes before any tooling decision. You need the inventory, the utilisation and above all the network conversations between servers, because those conversations decide what has to move together. Wave planning turns that dependency map into a sequence where each wave is independently testable and independently reversible.
Exam tip. If a scenario says the team does not know how the applications depend on each other, no migration tool is the right answer yet. Discovery with dependency mapping comes first, and options that start replicating servers are premature.
Rehosting Servers with Application Migration Service
Rehosting is the workhorse of most migrations, and Application Migration Service is the tool the exam expects you to name for it. It replicates source servers continuously into a staging area, so the cutover itself is short and the rehearsal is cheap. The important design points are the replication path, the test launches, and what you do to the servers once they are running in AWS.
Exam tip. Scenarios that stress minimal downtime for hundreds of servers with no application changes are describing Application Migration Service. Answers that suggest rebuilding each server manually or creating images by hand are there to be eliminated.
Database Migration with DMS and the Schema Conversion Tool
Database migrations split into two very different jobs depending on whether the engine changes. Same engine to same engine is largely a data movement exercise that DMS handles well, while changing engines means schema, stored procedures and application SQL all have to be converted first. The Schema Conversion Tool does the mechanical part of that and, just as importantly, tells you what it could not convert.
Exam tip. Look for the words same engine or different engine in the scenario. Different engines always brings the Schema Conversion Tool into the answer alongside DMS, and an answer offering DMS alone for a cross engine move is incomplete.
Moving Bulk Data: Network, Devices and Hybrid Gateways
Choosing how to move data comes down to arithmetic rather than preference: how much there is, how fast the link really goes, and when it has to be there. If an online copy finishes comfortably before the deadline, use the network, and if it does not, ship devices. A third category exists for data that is not moving once but continuously, which is where the hybrid gateways belong.
Exam tip. Do the arithmetic the question gives you. When it states a data volume, a link speed and a deadline, it wants you to notice that the online copy cannot finish in time, and the intended answer is a physical device.
Modernization Patterns After the Move
Modernization after a rehost is where most of the promised value actually appears, and doing it incrementally is what keeps it from becoming a stalled rewrite. The recurring pattern is to carve one capability out at a time, put it behind an interface, and leave the old system running until the new piece has earned its place. Each step should be independently deployable and independently reversible.
Exam tip. When a scenario says the business cannot tolerate a long freeze while the application is rewritten, the answer is an incremental pattern such as strangler fig. A complete rewrite before cutover is the classic wrong option in modernization questions.
Cutover Day: Sequence, Validation and Rollback
The cutover is the only part of a migration the business actually experiences, so it is planned minute by minute and rehearsed until it is boring. The sequence matters: quiesce writes, let replication drain, validate, repoint, then watch. Just as important is deciding in advance what would make you roll back and keeping the old system able to accept that decision.
Exam tip. Ordering questions about cutover almost always want replication and validation completed before any traffic is repointed, and the source kept available afterwards. Any sequence that repoints users before validating the target is wrong.