Cloud Digital Leader Why cloud technology is transforming business Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  All applications should be completely rewritten as cloud-native microservices for maximum cloud benefit

  Why it's wrong here

  Rewriting every application as cloud-native microservices ignores the enterprise’s need for a differentiated migration strategy that accommodates varying application architectures, dependencies, and business priorities. This approach is tempting because it promises maximum cloud optimisation through decoupled, independently deployable services, and would be correct for a greenfield project or a small portfolio where full re-architecture is cost-justified and technically feasible.

• ✓

  A portfolio-based migration framework (such as the 6 Rs: Rehost, Replatform, Refactor, Repurchase, Retire, Retain) that applies the right migration strategy to each application based on its business value and cloud-readiness

  Why this is correct

  The 6 Rs framework is the industry-standard answer for enterprise migration portfolio management. Simple internal apps: rehost (lift-and-shift). Commercially available replacements: repurchase. End-of-life apps: retire. Mission-critical legacy: retain. The right strategy for each application maximizes value while managing risk and cost.

• ✗

  Migrate all applications simultaneously during a single weekend cutover to minimize the total migration duration

  Why it's wrong here

  A single weekend cutover of 200+ applications is operationally reckless because it violates the fundamental principle of reducing blast radius: any unanticipated dependency, data-integrity issue, or performance bottleneck discovered during the cutover would have to be debugged and resolved across the entire portfolio simultaneously, with rollback posing a near-impossible challenge for distributed systems. Furthermore, comprehensive testing, security validation, and user acceptance cannot be realistically completed for such a large scope in one window, so the approach guarantees an unacceptable risk of partial failure, data loss, or prolonged downtime. Phased migration in waves—ordered by business value, dependency, and readiness—allows teams to validate each wave, replicate approaches, and apply lessons learned, aligning with industry-standard cutover planning and change management practices.

• ✗

  Keep all applications on-premises until a complete cloud-native replacement is built for each one

  Why it's wrong here

  Waiting for a complete cloud-native replacement before any migration forces the organization to forgo immediate cloud benefits (e.g., scalability, cost savings, managed services) and creates a multi-year stall during which existing on-premises systems continue to accrue technical debt and operational overhead. In practice, full rewrites of every application are rarely feasible or justified; a portfolio approach using the 6 Rs enables incremental modernization, allowing rapid wins (rehost/replatform) while gradually refactoring only the applications where the business case warrants it, and retiring or retaining the rest. This option mistakenly treats 'cloud-native' as a prerequisite rather than one of several migration end-states, ignoring that many workloads run effectively with minimal changes and that value realization can start immediately.

Go deeper

Related to this question