2017년, 거대 제조사 GE는 "9,000개의 워크로드를 클라우드로 옮긴다"는 야심찬 목표를 세웠지만 몇 년 뒤 상당수를 다시 온프레로 되돌렸다. 실패의 핵심 원인은 기술이 아니라 거버넌스의 부재였다 — 수백 개의 계정이 표준 없이 난립했고, 누가 어떤 리전에 무엇을 띄울 수 있는지에 대한 통제가 없었다. 반면 비슷한 시기 Capital One은 Organizations·SCP·표준화된 계정 팩토리를 먼저 깔고 마이그레이션을 시작해, 결국 자체 데이터센터를 전부 닫는 데 성공했다. 이 대비가 SAP-C02 Pro가 묻는 핵심을 압축한다 — 대규모 마이그레이션은 서버를 옮기는 작업이 아니라, 옮길 수 있는 통제된 착륙장(landing zone)을 먼저 짓는 작업이다.
오늘의 시나리오는 온프레 SAP·Oracle 100TB+를 6개월 안에 미주·EU·APAC에 걸쳐 AWS로 옮기되, 다운타임을 최소화하고 EU 데이터는 EU 밖으로 못 나가게 하라는 것이다. SAA 수준이라면 "MGN으로 옮기면 된다"고 답하겠지만, Pro는 그 위에 계정 구조·네트워크 토폴로지·데이터 주권·DR·7년 감사가 한 덩어리로 맞물린 설계를 요구한다. 오늘은 멀티 계정 거버넌스가 왜 이런 모양이 됐는지, 7R 마이그레이션 전략이 어떤 의사결정 트리인지, 그리고 데이터 주권이 어떤 법에 뿌리를 두는지를 깊이 분해한다.