Cloud Migration and Digital Transformation

Introduction

Cloud migration is the planned movement of applications, data, infrastructure, and operational capabilities from existing environments into cloud-based services. Digital transformation is broader: it is the sustained redesign of how an organization creates value, serves customers, operates processes, and makes decisions through digital technologies. Cloud computing is often an enabler of transformation, but migration alone does not constitute transformation. An organization can move servers to a cloud provider and retain inefficient processes, rigid governance, and outdated customer experiences.

Migration is therefore both a technical and organizational activity. It requires decisions about application architecture, data, security, compliance, skills, operating models, finances, suppliers, and change management. Poorly planned migration can increase cost, disrupt services, expose sensitive information, or reproduce technical debt in a new environment. Well-planned migration can improve scalability, resilience, delivery speed, observability, and access to advanced services such as analytics and artificial intelligence.

This chapter presents a structured approach to assessing readiness, analyzing application portfolios and dependencies, selecting migration strategies, and planning adoption and organizational change.

Learning Objectives

By the end of this chapter, students should be able to:

1. Explain the relationship between cloud migration and digital transformation.
2. Assess organizational, technical, financial, security, and cultural cloud readiness.
3. Analyze application portfolios, business criticality, technical condition, data, and dependencies.
4. Select among rehost, replatform, refactor, repurchase, retain, and retire strategies.
5. Construct a migration roadmap that addresses sequencing, risk, governance, and value.
6. Explain how cloud adoption changes operating models, skills, controls, and organizational culture.
7. Evaluate ethical, regulatory, financial, and sustainability issues in migration programs.

1. Migration as a Strategic Change

A cloud migration program normally has several possible objectives:

• Cost and efficiency: reducing data-center expenditure, improving utilization, or converting capital expenditure into operating expenditure.
• Agility: shortening the time required to provision environments and release software.
• Resilience: improving recovery capabilities, availability, and geographic redundancy.
• Scale: responding to variable demand without purchasing permanent capacity.
• Innovation: using managed databases, event platforms, analytics, machine learning, and automation.
• Business renewal: redesigning products, channels, and processes around digital interaction.

These objectives should be expressed as measurable business outcomes rather than as a vague ambition to “move to the cloud.” For example, a target might be to reduce a product release cycle from monthly to weekly, achieve a recovery-point objective of 15 minutes, or provide a customer portal with 99.9% monthly availability.

The business case should distinguish direct savings from strategic benefits. Direct savings may include avoided hardware refreshes and reduced facility costs. Strategic benefits may include faster experimentation and improved customer responsiveness, which are valuable but more difficult to measure. Cloud can also increase expenditure if workloads are poorly sized, data transfers are excessive, or teams consume services without financial controls.

Migration and transformation compared

A migration program should therefore begin with business capabilities and desired outcomes, not only with a list of servers.

2. Cloud Readiness Assessment

Cloud readiness is the degree to which an organization is prepared to adopt and operate cloud services safely and effectively. It is not a binary state. A business may be ready to migrate low-risk web applications but unready to move regulated data or mission-critical systems.

A useful assessment examines six dimensions.

2.1 Strategic and business readiness

The organization should identify executive sponsorship, business owners, transformation objectives, acceptable risk, and decision rights. Every migrated workload needs an accountable owner who can approve downtime, funding, service levels, and retirement decisions. Readiness is weak when migration is treated as an isolated information-technology project with no business participation.

Important questions include:

• What business problem does migration solve?
• Which outcomes have priority if cost, speed, and resilience conflict?
• Which services cannot tolerate interruption?
• What benefits will be measured, by whom, and when?

2.2 Technical readiness

Technical assessment covers network connectivity, identity management, endpoint security, monitoring, configuration management, automation, backup, disaster recovery, integration interfaces, and data quality. It also considers whether existing applications assume fixed IP addresses, local storage, synchronous communication, or data-center proximity.

A technically modern cloud environment normally requires standardized landing-zone capabilities: account or subscription structure, identity and access management, logging, network segmentation, encryption, policy controls, naming standards, and automated provisioning. These controls should exist before large-scale migration begins.

2.3 Financial readiness

Cloud changes cost behavior. Traditional infrastructure often involves large purchases followed by depreciation and maintenance. Cloud commonly introduces variable consumption charges for compute, storage, requests, network transfer, licenses, and managed services. Financial readiness requires budgets, tagging, ownership, forecasting, approval thresholds, and cost-optimization practices.

A simple total-cost comparison should include more than provider prices:

Here, TCO is total cost of ownership over a defined period; C_provider is cloud consumption and subscription cost; C_migration is one-time migration expenditure; C_operations is the cost of people, support, monitoring, and tooling; C_compliance is the cost of meeting legal and control obligations; and C_exit represents portability, transition, or exit costs. The expression is a planning model, not a universal accounting identity. The period, currency, scope, and assumptions must be consistent.

2.4 Security and compliance readiness

Readiness requires an understanding of shared responsibility. A provider may secure physical facilities and core infrastructure, while the customer remains responsible for identities, configurations, data classification, application security, and legal obligations. Responsibilities vary by service model and contract.

Assessment should cover:

• data classification and permitted locations;
• identity lifecycle, privileged access, and authentication;
• encryption in transit and at rest;
• vulnerability and patch management;
• logging, detection, and incident response;
• retention, deletion, and legal hold requirements;
• supplier assurance and audit rights;
• privacy impact and cross-border transfer requirements.

Cloud does not automatically make a system secure or compliant. It changes the control environment and often provides new security capabilities, but those capabilities must be configured and governed.

2.5 People and cultural readiness

Migration requires architects, cloud engineers, security specialists, developers, data professionals, product owners, finance partners, and service managers. Existing roles may change from infrastructure administration toward automation, platform engineering, reliability, governance, and product enablement. Resistance often arises when employees fear job loss, loss of control, or unrealistic delivery targets.

Readiness includes a skills inventory, training plan, career pathways, communities of practice, and mechanisms for communicating decisions. Training should combine formal learning with supervised work on real workloads.

2.6 Operational readiness

Cloud operations require reliable processes for incident management, change, service requests, configuration, observability, backup, recovery, capacity, supplier management, and cost control. Organizations should decide which responsibilities remain centralized and which are delegated to product teams.

A readiness assessment can use a qualitative scale such as initial, developing, managed, and optimized. The scale is useful only when supported by evidence, such as tested recovery procedures, documented ownership, and measured control performance. A numerical score can create false precision if criteria are not defined.

3. Application Portfolio and Dependency Analysis

A portfolio view prevents the organization from treating every application identically. The basic unit of analysis is usually a workload: an application together with its data, infrastructure, interfaces, operational processes, and accountable owners.

3.1 Portfolio attributes

For each workload, collect at least:

• business capability and owner;
• users, customers, and critical business processes;
• availability, performance, recovery-time objective, and recovery-point objective;
• technology stack, age, licensing, and technical debt;
• data classification, volume, growth, and retention;
• interfaces and upstream or downstream systems;
• peak and average utilization;
• current operating cost and contract commitments;
• deployment frequency and testability;
• regulatory and sovereignty constraints;
• retirement, replacement, or modernization plans.

The recovery-time objective (RTO) is the maximum acceptable time to restore a service after disruption. The recovery-point objective (RPO) is the maximum acceptable period of data loss measured in time. For example, an RPO of 30 minutes means that recovery should lose no more than approximately 30 minutes of data under the stated design and assumptions.

3.2 Dependency mapping

Dependencies may be technical, data-related, organizational, or contractual. Technical dependencies include databases, identity services, message queues, APIs, DNS, file shares, and batch schedulers. Organizational dependencies include a specialist team that must approve changes. Contractual dependencies include licensing restrictions and outsourced interfaces.

Discovery tools can identify network flows, processes, ports, and resource relationships, but automated discovery is incomplete. Interviews, architecture documents, source-code analysis, transaction tracing, and business-process workshops are necessary to identify hidden dependencies. A dependency map should record direction, criticality, latency sensitivity, data type, owner, and migration implication.

A common error is to migrate a user-facing application while leaving a highly chatty database or file service in the original environment. The result may be increased latency, network charges, and operational complexity. Another error is to migrate systems in organizational rather than technical order, ignoring shared identity, payment, or reporting dependencies.

3.3 Portfolio segmentation

A practical portfolio matrix considers business value and technical condition. High-value, healthy applications may be good candidates for early modernization. Low-value, obsolete applications may be retired. High-value but technically fragile systems require careful planning, testing, and perhaps interim rehosting.

Segmentation should also consider change risk. A low-complexity application may be a useful pilot, while a highly integrated payment platform should not be selected merely because it is visible to executives. Pilot workloads should demonstrate the target operating model without putting essential services at unacceptable risk.

4. Migration Strategies: The Six Rs

The six migration strategies are decision patterns, not rigid categories. A workload may use one strategy initially and another later.

Rehost

Rehost, sometimes called lift and shift, moves an application with minimal code change, often into virtual machines or compatible infrastructure services. It is fast and can reduce data-center dependency, but it may preserve inefficient architecture, licensing cost, weak automation, and poor elasticity. Rehost is useful when deadlines are strong, the application is stable, or modernization will follow later.

Replatform

Replatform makes limited changes to gain cloud benefits without redesigning the complete application. Examples include moving to a managed database, using a managed container platform, or changing the runtime while preserving application behavior. It can reduce operational burden, but compatibility testing and data migration remain important.

Refactor

Refactor, often called rearchitect when the design changes substantially, modifies application structure to use cloud-native capabilities. Examples include decomposing a monolith, introducing managed messaging, using autoscaling, or designing stateless services. Refactoring can improve agility and resilience, but it requires substantial skills, testing, funding, and business involvement. It should be justified by a durable business benefit rather than by technology fashion.

Repurchase

Repurchase replaces an existing system with a commercial product or software-as-a-service offering. This can remove maintenance responsibilities and accelerate capability delivery. Risks include data migration, process standardization, vendor lock-in, licensing changes, integration limitations, and reduced customization.

Retain

Retain means keeping a workload in its current environment for a justified reason. Reasons may include regulatory restrictions, unresolved dependencies, low economic value, hardware coupling, or a planned replacement. Retain must not become an unexamined default; each retained workload should have an owner, review date, and risk treatment.

Retire

Retire removes a workload that is duplicated, obsolete, unused, or replaced. Retirement creates value by reducing attack surface, license cost, support burden, and migration scope. It requires evidence, archival decisions, stakeholder confirmation, and a rollback or recovery plan where appropriate.

The selection should be evidence-based. Relevant criteria include business value, technical complexity, change risk, compliance, urgency, expected benefit, skills, and future strategic fit.

5. Building a Migration Roadmap

A roadmap converts assessment into sequenced action. It normally contains the following stages:

1. Discover: establish inventory, ownership, dependencies, data classification, and baseline cost and performance.
2. Assess: determine readiness, migration strategy, risks, target architecture, and business case.
3. Prepare: create the landing zone, connectivity, identity, security controls, observability, automation, and operating procedures.
4. Pilot: migrate a bounded workload, validate controls, measure outcomes, and improve the migration factory.
5. Migrate and modernize: execute waves grouped by dependency, business capability, risk, or platform.
6. Stabilize: validate service levels, security, cost, recovery, support, and user experience.
7. Optimize and transform: remove unused resources, improve architecture, automate delivery, and redesign products and processes.

Migration waves should account for dependency order. A foundational identity or integration service may need to move before dependent applications. Conversely, a shared service with many consumers may be safer to retain temporarily while consumer applications are adapted.

Each wave should define entry and exit criteria. Entry criteria may include approved design, tested backup, security review, communication plan, and rollback procedure. Exit criteria may include successful functional testing, performance results, recovery test, monitoring coverage, owner acceptance, and reconciliation of data.

Worked example: comparing two migration options

An organization evaluates a workload over three years. A rehost option has cloud charges of $180,000 per year, migration cost of $70,000, and operations cost of $50,000 per year. A replatform option has cloud charges of $150,000 per year, migration cost of $180,000, and operations cost of $35,000 per year. Ignore compliance and exit costs for this simplified comparison.

For rehost:

For replatform:

Under these assumptions, replatforming has the lower three-year cost by $25,000. However, cost alone does not decide the strategy. The organization must assess delivery risk, expected performance, skill availability, compliance, and the value of earlier migration. The calculation assumes all values are in the same currency, are comparable, and exclude financing, tax, inflation, and benefits not stated in the example.

6. The Target Operating Model

Cloud adoption changes how technology work is organized. A traditional model may separate infrastructure, security, development, and operations into specialist silos. Cloud encourages product-oriented teams that own services through their life cycle, supported by shared platforms and guardrails.

A target operating model should define:

• Accountability: who owns the product, service level, data, security risk, and cost.
• Platform services: which capabilities are provided centrally, such as identity, networking, logging, deployment pipelines, and approved templates.
• Team autonomy: what product teams may provision and change independently.
• Governance: which controls are mandatory, automated, risk-based, or subject to review.
• Service management: how incidents, changes, availability, continuity, and suppliers are managed.
• Financial management: how budgets, forecasts, allocation, optimization, and accountability operate.

A central cloud center of excellence can provide standards, enablement, architecture guidance, training, and reusable patterns. It should not become a permanent bottleneck that approves every low-risk change. Mature governance uses policy-as-code, automated checks, standard templates, and exception management.

DevOps, platform engineering, and FinOps

DevOps integrates development and operations through collaboration, automation, continuous integration, delivery, testing, and feedback. Platform engineering creates internal products that make secure and compliant delivery easier for application teams. FinOps is a collaborative discipline connecting engineering, finance, and business teams to manage the value of cloud consumption. These practices are complementary, not substitutes for sound architecture.

7. Skills, Adoption, and Change Management

Cloud migration fails as often from adoption problems as from technical defects. A skills program should distinguish awareness, practitioner capability, and specialist expertise. Core capabilities may include cloud architecture, identity and security, infrastructure as code, containerization, data engineering, reliability engineering, observability, cost management, vendor management, and communication.

A useful development cycle is:

1. assess current skills and role requirements;
2. define competency levels and learning pathways;
3. provide training, mentoring, labs, and certification where useful;
4. apply skills in supervised migration work;
5. measure operational outcomes and close gaps.

Change management should explain why the change is needed, how roles will be affected, what support is available, and how success will be recognized. Adoption metrics may include active use of the platform, deployment frequency, recovery-test completion, policy compliance, incident trends, training completion, and user satisfaction. Metrics should encourage safe learning rather than reward reckless speed.

8. Governance, Ethics, and Risk

Cloud migration raises governance questions beyond technology.

Privacy and data protection: Personal data should be processed lawfully, minimally, and for defined purposes. Location, transfer, retention, deletion, and processor obligations must be understood. Data should not be copied into test environments without suitable protection.

Security and surveillance: Centralized logging improves detection but may create extensive records about employees and customers. Access to logs should be restricted, justified, monitored, and retained only as required.

Accessibility and inclusion: Digital transformation should not exclude users with disabilities, limited connectivity, low digital literacy, or inability to use a particular device. Alternative channels and accessible design remain important.

Supplier concentration and lock-in: Dependence on one provider can create resilience, bargaining, portability, and geopolitical risks. Multi-cloud is not automatically safer; it adds complexity. Portability requirements should be selective and based on business risk.

Algorithmic and AI risk: Cloud platforms make analytics and AI easier to adopt, but models may reproduce bias, expose confidential data, or produce unreliable decisions. Human oversight, data governance, testing, explainability appropriate to the use case, and clear accountability are required.

Sustainability: Cloud may improve utilization through shared infrastructure, but total environmental impact depends on energy sources, hardware life, data movement, workload efficiency, and rebound effects. Organizations should measure meaningful impacts rather than assume that cloud is automatically green.

9. Illustrative Case: Northstar Insurance

Background

Northstar Insurance, a fictional regional insurer, operates a claims application in a private data center. The application is 12 years old, uses a relational database and file shares, and integrates with payment, identity, document, and regulatory-reporting systems. Claims volume varies significantly after severe weather events.

Problem

Infrastructure refresh costs are increasing, recovery testing is infrequent, and the claims team waits several weeks for test environments. Executives propose moving everything to the cloud within six months. The technology team identifies undocumented interfaces, sensitive personal data, and a licensing agreement that restricts deployment models.

Analysis

The portfolio assessment classifies the claims application as high business value and high operational criticality. Its RTO is four hours and its RPO is 15 minutes. Dependency discovery identifies identity, payment, document storage, fraud analytics, reporting, and a batch scheduler. The database is tightly coupled to the application, while the document repository has an independent interface.

A single lift-and-shift migration would be fast but would not address recovery testing, environment automation, or event-driven claims surges. Immediate refactoring of the entire application would create unacceptable delivery risk. The team therefore chooses a staged approach: replatform selected database and storage components, rehost the core application initially, and later refactor the surge-processing component.

Approach and solution

Northstar first establishes a landing zone with centralized identity, encryption, logging, network controls, backup, and policy checks. It classifies data and creates masked test data. A low-risk document service is used as a pilot. The pilot validates connectivity, monitoring, deployment automation, access controls, and recovery procedures.

The claims workload is then migrated in waves. The document service moves first, followed by a replicated database and application environment. Payment and regulatory reporting are tested with business owners. The organization runs a controlled failover exercise before production cutover. After stabilization, the surge-processing component is redesigned to use asynchronous messaging and autoscaling, while the core claims application remains temporarily on a managed virtual-machine platform.

Outcome

The fictional case demonstrates a balanced program rather than a technology slogan. Northstar reduces data-center dependency, improves environment provisioning, and tests recovery more frequently. It avoids a risky “big bang” migration and preserves a later path to modernization. Benefits depend on continued governance: unused environments must be shut down, data access reviewed, and the retained legacy components assigned retirement or modernization dates.

Learning points

• Business criticality and dependency order matter more than application age alone.
• Rehost and refactor can be sequential strategies.
• A landing zone and operating controls are prerequisites, not optional documentation.
• Recovery objectives must be tested, not merely written.
• Migration creates a foundation for transformation but does not complete it.

10. Contemporary Developments and Best Practices

Several developments influence current migration programs. Managed container and serverless services can reduce infrastructure administration, but they introduce new cost, observability, and portability considerations. Infrastructure as code improves repeatability and reviewability. Confidential computing, stronger identity controls, and automated policy enforcement can support sensitive workloads. Generative AI can assist with code analysis, documentation, test generation, and migration planning, but generated output requires human review, secure data handling, license checks, and testing.

Effective practice includes:

• begin with measurable business outcomes;
• maintain an authoritative workload inventory;
• assign owners for applications, data, risk, and cost;
• discover dependencies using both tools and human inquiry;
• establish security, identity, logging, and recovery before migration at scale;
• choose migration strategies per workload rather than by ideology;
• use pilots and migration waves with explicit entry and exit criteria;
• automate repeatable controls and deployment processes;
• provide transparent cost visibility and optimization;
• test performance, security, resilience, and rollback;
• treat adoption, skills, and culture as program deliverables;
• review retained workloads and technical debt continuously;
• plan supplier, data, and service exit arrangements.

Challenges and Limitations

Migration estimates are uncertain because inventories are incomplete, dependencies are hidden, and benefits such as agility are difficult to quantify. Provider pricing can change, consumption can grow unexpectedly, and data egress may complicate architectural choices. Refactoring can become an open-ended rewrite. Retaining legacy systems may be sensible in the short term but can preserve risk indefinitely. Multi-cloud can improve negotiating position or resilience for selected services, yet it may multiply skills, tooling, and operational complexity.

No framework eliminates judgment. The six Rs simplify communication, but real decisions may combine strategies, include transitional states, or be constrained by law and contracts. Readiness models are diagnostic aids rather than guarantees. Ultimately, migration quality is demonstrated through reliable services, controlled risk, realized benefits, and the organization’s ability to continue improving after the initial program ends.

Chapter Summary

Cloud migration is the movement or modernization of workloads, whereas digital transformation redesigns how an organization creates value. Cloud can enable transformation, but migration by itself does not guarantee better products or processes. Readiness must be assessed across strategy, technology, finance, security, people, and operations.

Application portfolio analysis requires ownership, business criticality, data classification, technical condition, recovery objectives, costs, and dependency mapping. The six Rs—rehost, replatform, refactor, repurchase, retain, and retire—provide a practical vocabulary for selecting workload strategies. Decisions should reflect value, risk, complexity, compliance, skills, and future direction.

A credible roadmap establishes a secure landing zone, pilots workloads, sequences migration waves, defines entry and exit criteria, and stabilizes services before optimization. Cloud adoption also changes operating models by encouraging product ownership, platform engineering, DevOps, automation, and FinOps. Skills development, communication, governance, privacy, security, accessibility, supplier risk, AI accountability, and sustainability are essential parts of the program. Successful migration is therefore a continuing organizational capability rather than a one-time infrastructure project.

Key Terms

Cloud migration: Planned movement or modernization of applications, data, and infrastructure into cloud services.

Digital transformation: Organization-wide redesign of value creation and operations through digital capabilities.

Cloud readiness: Degree to which an organization can adopt and operate cloud services effectively and safely.

Workload: An application together with its data, infrastructure, interfaces, and operational responsibilities.

Dependency mapping: Identification and analysis of relationships among applications, data, services, teams, and suppliers.

Landing zone: Governed foundational cloud environment containing identity, networking, security, logging, and policy controls.

Rehost: Move a workload with minimal application modification.

Replatform: Make limited changes to use selected managed or cloud services.

Refactor: Change application architecture to gain substantial cloud-native benefits.

Repurchase: Replace an existing system with a commercial product or service.

Retain: Keep a workload in its current environment for a justified reason.

Retire: Remove an obsolete, duplicated, or unused workload.

RTO: Maximum acceptable time required to restore a service after disruption.

RPO: Maximum acceptable period of data loss measured in time.

Technical debt: Future cost and risk created by expedient or outdated technical decisions.

Operating model: Structure of responsibilities, processes, capabilities, governance, and service delivery.

FinOps: Collaborative management of cloud value and consumption involving finance, engineering, and business teams.

Platform engineering: Development of internal platforms that enable teams to deliver services safely and efficiently.

Shared responsibility: Division of security and operational obligations between provider and customer.

Policy as code: Machine-enforceable representation of governance and compliance rules.

Review Questions

Short Answer Questions

1. Why is cloud migration not equivalent to digital transformation?
2. Define RTO and RPO and explain the difference between them.
3. What information should be collected in an application portfolio assessment?
4. Distinguish rehost from replatform.
5. Why is a landing zone important before large-scale migration?

Long Answer Questions

1. Explain the six migration strategies and discuss when each may be appropriate.
2. Describe a comprehensive cloud readiness assessment covering business, technical, financial, security, people, and operational dimensions.
3. Explain how dependency mapping influences migration-wave sequencing.
4. Discuss how cloud adoption changes the technology operating model.
5. Evaluate the governance, privacy, supplier, sustainability, and AI-related risks of cloud migration.

Analytical / Application Questions

1. An organization has a low-value application with obsolete software, no active users, and duplicated functionality. Which migration strategy should be considered first, and what evidence should be gathered before implementation?
2. A high-value claims system has a tightly coupled database, strict recovery objectives, and variable demand. Propose a staged migration approach and justify the order of activities.
3. A three-year rehost option costs $760,000 while a replatform option costs $735,000 under stated assumptions. Identify at least three non-financial factors that should be evaluated before selecting the replatform option.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes cloud migration from digital transformation?

A. Cloud migration always requires rewriting every application.

B. Digital transformation is limited to moving data centers.

C. Cloud migration moves or modernizes workloads, while digital transformation redesigns organizational value creation and operations.

D. Digital transformation excludes cloud computing.

Correct Answer: C. Cloud migration moves or modernizes workloads, while digital transformation redesigns organizational value creation and operations.

Question 2

Which migration strategy involves moving an application with minimal code changes?

A. Rehost

B. Refactor

C. Repurchase

D. Retire

Correct Answer: A. Rehost

Question 3

An RPO of 15 minutes means that the organization aims to:

A. Restore the service within 15 minutes.

B. Lose no more than approximately 15 minutes of data after a disruption.

C. Keep the service available for 15 minutes each hour.

D. Complete migration testing every 15 minutes.

Correct Answer: B. Lose no more than approximately 15 minutes of data after a disruption.

Question 4

Which item is most appropriately included in a cloud landing zone?

A. An untested application rewrite

B. Identity, network, logging, and policy foundations

C. A business marketing plan only

D. A list of retired employees

Correct Answer: B. Identity, network, logging, and policy foundations

Question 5

Replacing an existing system with a software-as-a-service product is an example of:

A. Retain

B. Replatform

C. Repurchase

D. Rehost

Correct Answer: C. Repurchase

Question 6

Why can dependency mapping affect migration-wave order?

A. It identifies which services and data must be available before dependent applications can operate.

B. It eliminates the need for business owners.

C. It guarantees that every workload should be refactored.

D. It determines cloud provider market share.

Correct Answer: A. It identifies which services and data must be available before dependent applications can operate.

Question 7

Using the chapter’s simplified TCO model, which cost category represents one-time migration expenditure?

A. C_provider

B. C_migration

C. C_operations

D. C_exit

Correct Answer: B. C_migration

Question 8

Which practice most directly supports financial accountability for cloud consumption?

A. FinOps

B. Retirement without evidence

C. Ignoring resource ownership

D. Disabling usage monitoring

Correct Answer: A. FinOps

Question 9

What is a major risk of rehosting without further modernization?

A. The application may preserve technical debt and inefficient architecture.

B. The application cannot use any network connection.

C. All data is automatically deleted.

D. The workload is necessarily converted into SaaS.

Correct Answer: A. The application may preserve technical debt and inefficient architecture.

Question 10

Which statement best reflects the shared-responsibility principle?

A. The cloud provider is always responsible for application access control.

B. The customer has no security obligations when using managed services.

C. Security and operational responsibilities are divided between provider and customer according to the service and contract.

D. Regulatory obligations transfer completely to the provider.

Correct Answer: C. Security and operational responsibilities are divided between provider and customer according to the service and contract.