클라우드 마이그레이션 도구를 처음 보면 DMS·SCT·Snow Family·DataSync·MGN이 비슷비슷한 "옮기는 도구"로 뭉뚱그려진다. 하지만 이들을 가르는 진짜 축은 "무엇을 옮기느냐(DB·서버·파일)"가 아니라 **"옮기는 과정에서 무엇이 발목을 잡느냐"**다. 데이터베이스 마이그레이션의 적은 다운타임이고, 대용량 파일 마이그레이션의 적은 네트워크 대역폭이며, 서버 마이그레이션의 적은 이식 중 상태 불일치다. 각 도구는 이 특정 제약을 푸는 데 특화돼 있다. SAA 시험이 마이그레이션을 끝없이 변주해 묻는 이유도, 시나리오의 "제약 키워드"를 읽고 맞는 도구를 고르는 능력이 곧 아키텍트의 판단력이기 때문이다.
이 글은 마이그레이션 전략의 큰 그림(7R)에서 시작해, 각 도구가 어떤 제약을 어떻게 푸는지 — DMS의 CDC가 어떻게 무중단 전환을 만드는지, Snow와 DataSync를 가르는 네트워크 손익분기점은 어디인지, MGN과 DRS가 같은 블록 복제를 쓰면서도 왜 다른 서비스인지 — 를 내부 동작으로 따라간다.
AWS의 마이그레이션 전략은 7R로 정리된다 — Retire(폐기), Retain(유지), Relocate(이전), Rehost(재호스팅), Repurchase(재구매), Replatform(재플랫폼), Refactor(재설계)