Cloud migration is the controlled movement of applications, data, platforms, and operational capabilities from existing environments to cloud services. Digital transformation is broader: it is the redesign of how an organisation creates value, serves customers, operates, and makes decisions through digital capabilities. Migration may therefore be a technology project, whereas transformation is an organisational and business change programme.
A successful migration does not result merely in workloads running in a different data centre. It should improve measurable outcomes such as customer responsiveness, resilience, security, scalability, employee productivity, or cost transparency. Conversely, moving poorly designed systems without changing their operating model can reproduce existing inefficiencies in a new environment. This is often called “lifting and shifting the problem.”
Cloud migration decisions must balance technical feasibility, business value, risk, compliance, skills, and organisational readiness. The central professional task is not to select a cloud provider first, but to determine which capabilities should change, why they should change, and in what sequence.
Learning Objectives
By the end of this chapter, a learner should be able to:
Assess an application portfolio using business, technical, financial, and risk criteria.
Construct a defensible cloud migration business case.
Explain and select migration strategies, including rehost, replatform, refactor, repurchase, retain, and retire.
Identify application dependencies and use them to design a migration sequence.
Develop a modernization roadmap with measurable outcomes and governance gates.
Design an operating model incorporating people, process, platform, security, and financial management.
Manage organisational change, migration risk, compliance, and ethical responsibilities.
1. Migration as a Business and Architectural Decision
A portfolio is a collection of applications, data stores, integrations, infrastructure components, and supporting services. Each application has a lifecycle: introduction, growth, maturity, decline, and retirement. Cloud migration should align the technology lifecycle with business strategy.
Three questions frame portfolio assessment:
Value: Does the application support a strategically important product, process, customer experience, or regulatory obligation?
Fitness: Is the current architecture sufficiently reliable, secure, maintainable, and scalable?
Changeability: Can the application be moved or modified within acceptable time, cost, and risk?
An application with high business value and poor technical fitness may deserve investment and refactoring. An application with low business value and high operating cost may be a retirement candidate. A stable, low-risk application may be retained temporarily rather than changed immediately.
Migration should also distinguish between application modernisation and infrastructure relocation. Modernisation changes architecture, delivery practices, data use, or user experience. Relocation changes the hosting environment while leaving most application characteristics intact.
2. Application Portfolio Assessment
2.1 The assessment dimensions
A practical assessment uses a common evidence set for every application. Important dimensions include:
Infrastructure, licences, labour, support contracts
Change readiness
Can the organisation operate the target service?
Skills, processes, suppliers, ownership
Business criticality should not be confused with technical complexity. A technically simple payroll service may be business-critical, while a complex research system may have limited operational impact.
2.2 Portfolio scoring
A weighted scoring model can support, but must not replace, professional judgement. Let an application’s overall priority score be:
P = ∑(wᵢsᵢ), where ∑wᵢ = 1
Here, wᵢ is the weight assigned to criterion i, and sᵢ is the normalised score for that criterion, commonly on a 1–5 scale. The score is dimensionless. The model assumes that criteria have been defined consistently and that additive weighting is acceptable; it does not prove that one application should be migrated before another.
For example, suppose strategic value, risk reduction, cost opportunity, and technical feasibility receive weights of 0.35, 0.25, 0.20, and 0.20. If their scores are 5, 4, 3, and 2, respectively:
The result indicates a relatively high priority, but the application may still be unsuitable for an early migration if it has an unresolved regulatory dependency or if its owner lacks operational readiness.
A useful assessment produces an application profile, not merely a number. The profile should include owner, users, service-level objectives, architecture, interfaces, data classification, recovery requirements, vendor constraints, current cost, target state, recommended strategy, and confidence in the evidence.
2.3 Dependency analysis
Dependencies are relationships that affect migration order or service operation. They include:
synchronous API calls;
shared databases and files;
identity and access services;
message brokers and event streams;
scheduled batch jobs;
network routes and firewall rules;
external suppliers and regulatory interfaces; and
operational dependencies such as monitoring, backup, and incident response.
A dependency map should distinguish hard dependencies, where a service cannot function without another service, from soft dependencies, where integration can be temporarily replaced or degraded. It should also identify data ownership and direction of flow. An apparently independent application may be tightly coupled through an undocumented shared database.
Dependency mapping supports migration waves. A wave is a group of workloads migrated and validated together. Good waves have a clear business owner, manageable technical scope, defined rollback conditions, and a measurable outcome.
3. Building the Business Case
A business case compares the consequences of alternatives rather than assuming that cloud is automatically cheaper. Relevant benefits may include faster delivery, reduced provisioning time, improved resilience, elastic capacity, access to specialist managed services, and reduced data-centre commitments. Costs include consumption, connectivity, migration tooling, consulting, retraining, dual running, licence changes, security controls, and continuing on-premises obligations.
3.1 Total cost of ownership
A simple planning model for a time horizon is:
TCO = C₀ + ∑(Cₜ + Lₜ + Oₜ + Mₜ), for t = 1 to n
C₀ is one-time migration cost; Cₜ is cloud consumption in period t; Lₜ is licensing; Oₜ is operations and support; Mₜ is migration-related or platform-management cost; and n is the number of periods. All terms must use the same currency and time period. This is a nominal, undiscounted model and should include comparable costs in the current environment when used for a baseline comparison.
A more complete financial analysis discounts future cash flows. Net present value is:
NPV = −I₀ + ∑(Bₜ − Cₜ)/(1+r)ᵗ
I₀ is the initial investment, Bₜ is benefit in period t, Cₜ is cost in that period, and r is the discount rate per period. The equation assumes cash flows occur at defined period boundaries and that the discount rate is appropriate for the organisation. Benefits such as improved customer trust may be difficult to express in monetary terms and should not be falsely quantified merely to complete the calculation.
3.2 Example business case
An organisation estimates a migration investment of £180,000. It expects annual benefits of £140,000 and annual operating costs of £85,000 for three years. Ignoring discounting, the net benefit is:
Net benefit = 3×(£140,000 − £85,000) − £180,000 = −£15,000
This narrow financial view does not justify the programme. However, if the migration also avoids a mandatory data-centre renewal costing £100,000, the adjusted net benefit becomes £85,000. The decision still requires sensitivity analysis: consumption may be higher than forecast, benefits may arrive later, and dual running may last longer than planned.
A credible business case presents scenarios—conservative, expected, and optimistic—and identifies assumptions, confidence levels, non-financial benefits, and dis-benefits. It should explain who owns each benefit and how it will be measured after implementation.
4. Migration Strategies
The commonly used “R” strategies describe different degrees of change. They are not a universal algorithm; a single portfolio may use several strategies.
Strategy
Meaning
Appropriate when
Main limitation
Rehost
Move with minimal code change
Speed and risk reduction are primary
May preserve inefficiency
Replatform
Make limited platform changes
Managed databases or runtime improvements provide value
Requires testing and configuration change
Refactor / re-architect
Redesign significant parts of the application
Agility, scalability, or resilience justify investment
Higher cost, duration, and delivery risk
Repurchase
Replace with a cloud or SaaS product
Commodity capability is no longer strategic
Data migration, integration, and supplier lock-in
Retain
Keep in the current environment temporarily or permanently
Constraints, low value, or unresolved dependencies exist
Creates hybrid complexity
Retire
Remove the application and its data where permitted
Function is duplicated, obsolete, or unused
Requires careful records and stakeholder confirmation
A further option, relocate, moves a virtualised workload to a compatible hosted environment with minimal redesign. It can be useful as an interim step but should not be mistaken for transformation.
Choosing a strategy
Strategy selection should consider business criticality, target service levels, data sensitivity, architecture, technical debt, migration deadline, available skills, and expected benefit. A refactor is justified when the improvement in business value or risk reduction exceeds its additional cost and uncertainty. Rehosting is not inherently inferior; it may be the safest first step for a time-constrained workload, provided that its limitations are recorded and a later modernisation decision is made.
5. Modernisation Roadmaps
A roadmap converts an aspiration into sequenced decisions. It normally contains the following stages:
Mobilise: establish sponsorship, scope, governance, funding, and success measures.
Discover: inventory applications, owners, data, interfaces, contracts, and operational processes.
Assess: score value, risk, readiness, cost, and dependency complexity.
Design the landing zone: create identity, networking, logging, security controls, account or subscription structure, policies, and baseline automation.
Pilot: migrate a bounded workload to test architecture, controls, tooling, and operating practices.
Migrate waves: execute prioritised groups with rehearsals, validation, and rollback plans.
Cloud migration roadmap from assessment to optimisation
Figure: Cloud migration roadmap from assessment to optimisation
Figure: A staged migration roadmap with continuous governance and feedback.
Each stage should have entry and exit criteria. For example, a workload should not enter production migration until ownership, data classification, backup, monitoring, access control, test evidence, support arrangements, and rollback conditions have been confirmed.
6. Target Operating Model
Migration changes responsibility as well as technology. A target operating model describes how services are governed, delivered, secured, supported, and improved.
People and accountability
Typical roles include product owner, application owner, cloud platform team, security and risk specialists, site reliability or operations engineers, finance partner, data owner, and service desk. A responsibility assignment matrix can clarify who is responsible for performing work, accountable for outcomes, consulted for decisions, and informed of status.
Cloud provider responsibility does not eliminate customer responsibility. Depending on the service model, the customer may remain responsible for identities, configurations, data classification, application security, access reviews, and compliance evidence.
Platform and engineering practices
A platform team should provide reusable, governed capabilities rather than forcing every delivery team to become a cloud specialist. Important practices include infrastructure as code, automated policy checks, standard deployment pipelines, central logging, secrets management, vulnerability management, backup testing, and service catalogues.
Continuous integration and continuous delivery can shorten feedback cycles, but automation must include approval controls for high-risk changes. Observability should combine metrics, logs, traces, events, and user-experience indicators. Reliability objectives should be explicit. For example, an availability objective of 99.9% over a 30-day month permits approximately 43.2 minutes of unavailability, calculated as 30×24×60×(1−0.999) minutes. The calculation assumes a 30-day measurement period and that all downtime is counted consistently; contractual definitions may differ.
Financial operations
FinOps connects engineering decisions with financial accountability. Teams should use tagging or account structures, budgets, forecasts, anomaly detection, rightsizing, scheduling, and unit-cost measures such as cost per transaction. Cost reduction must not undermine security, resilience, or service quality. A cheap but unreliable service may have a higher total business cost.
7. Organisational Change and Readiness
Cloud programmes commonly fail through people and process weaknesses rather than through a lack of technical features. Readiness assessment should cover executive sponsorship, funding, skills, operating procedures, supplier arrangements, communication, and willingness to change.
A change plan should:
identify affected stakeholder groups;
explain the reason for change in business terms;
provide role-specific training and practical laboratories;
establish communities of practice and coaching;
revise job descriptions, incentives, and performance measures;
communicate migration schedules and service impacts; and
monitor adoption and address resistance respectfully.
Resistance is often rational. Operations staff may fear loss of employment, developers may distrust central governance, and business users may fear disruption. Treating these concerns as information improves the programme. Change leadership should not use training as a substitute for adequate staffing, usable platforms, or clear accountability.
8. Risk, Security, Compliance, and Ethics
Migration risk should be recorded in a risk register with cause, event, consequence, likelihood, impact, owner, treatment, trigger, and contingency. Typical risks include data loss, prolonged outage, undocumented dependency, insecure configuration, supplier lock-in, cost overrun, skills shortage, licence non-compliance, and failed rollback.
Controls should be proportional to risk and evidenced. Examples include:
encryption in transit and at rest;
least-privilege identity and privileged-access management;
network segmentation and controlled ingress and egress;
immutable or isolated backups and restoration tests;
vulnerability and configuration scanning;
security monitoring and incident response;
data retention, deletion, residency, and transfer controls; and
independent assurance for critical systems.
Privacy obligations require purpose limitation, data minimisation, lawful processing, appropriate retention, and protection of individuals’ rights. Sensitive data should not be copied into migration environments without a documented purpose and suitable safeguards. Test data should be masked or synthetically generated where feasible.
Ethically, organisations should consider surveillance, automated decision-making, accessibility, digital exclusion, and workforce effects. Cloud adoption can increase concentration in a small number of suppliers, creating strategic dependency. Architecture reviews should therefore consider portability, exit plans, open interfaces, data export, and the operational feasibility of leaving a provider.
9. Validation and Cutover
Migration validation must test more than whether an application starts. It should include functional correctness, performance, resilience, security, data integrity, integration, operational support, and user acceptance. Reconciliation checks should compare source and target records using agreed rules. For critical data, the organisation should define what constitutes an acceptable discrepancy and who authorises resolution.
Cutover approaches include:
Big bang: one controlled switch; simple to communicate but high concentration of risk.
Phased migration: users or functions move in groups; provides learning but requires coexistence controls.
Blue–green deployment: two environments exist and traffic is switched; supports rapid rollback if data compatibility is managed.
Parallel running: old and new systems operate together; increases cost but provides strong comparison evidence.
Rollback is not merely restoring servers. It may require reversing DNS or routing, reconciling transactions, preserving audit trails, and preventing users from writing inconsistent data to both systems. The rollback point, maximum acceptable data loss, and decision authority must be agreed before cutover.
10. Illustrative Case: Northstar Insurance
Background
Northstar Insurance, a fictional regional insurer, operates a policy administration system, a customer portal, a claims platform, and several nightly data exchanges. Its ageing data centre contract ends in 18 months. Customer demand is seasonal, the portal has frequent performance complaints, and claims data is subject to privacy and retention obligations.
Problem
The organisation initially proposed rehosting every server. Portfolio discovery found that the portal shared a database with the policy system, the claims platform depended on a batch file, and three applications performed overlapping customer-record functions. The proposed plan also omitted identity redesign, disaster-recovery testing, and dual-running costs.
Analysis
The programme assessed value, risk, technical fitness, dependency complexity, and readiness. The customer portal had high strategic value and poor scalability. The policy system was stable but tightly coupled and supported a critical business process. The duplicate customer-record applications had low strategic value. The claims platform was valuable but its batch integration created a sequencing constraint.
Approach and solution
Northstar adopted a mixed strategy:
retire two duplicate applications after business-owner confirmation;
replatform the portal runtime and introduce caching and automated deployment;
rehost the policy system as an interim measure, with a funded later decomposition study;
replace the batch exchange with a managed integration service after interface testing;
retain a specialist legacy component until its supplier contract ends; and
establish a governed landing zone with central identity, logging, backup, and policy controls.
The portal and its dependencies formed the pilot wave. Claims followed after data reconciliation and business acceptance testing. Policy administration was migrated in a later wave with a rehearsed rollback and extended parallel validation.
Outcome
In this illustrative case, the organisation reduced data-centre dependency, improved portal release frequency, and gained clearer ownership of customer data. It did not claim that all systems were transformed: the policy platform remained a modernisation candidate. This distinction prevented unrealistic benefits reporting.
Learning points
The case demonstrates that portfolio rationalisation can create more value than indiscriminate migration, that dependencies determine sequence, and that an interim rehost can be rational when accompanied by explicit technical-debt management. It also shows why security, operations, and data governance must be designed before production migration rather than added afterwards.
11. Contemporary Developments
Cloud-native managed services, event-driven integration, containers, platform engineering, confidential computing, and artificial-intelligence-assisted operations are expanding the modernisation toolkit. AI can help classify application documentation, identify anomalous costs, summarise logs, and suggest dependency relationships. However, generated recommendations require human validation because inventories may be incomplete, logs may contain sensitive information, and automated changes can amplify configuration errors.
Sustainability is also becoming a portfolio criterion. Teams can assess workload utilisation, storage retention, data transfer, hardware lifecycle, and regional energy characteristics. Sustainability measures should be evidence-based and should not override legal, resilience, or accessibility requirements.
Best-Practice Checklist
A professionally governed migration should:
start with business outcomes and an evidence-based inventory;
assign accountable owners for applications, data, risks, and benefits;
map dependencies, including undocumented data and operational dependencies;
select strategies per workload rather than applying one strategy universally;
establish secure landing-zone controls before production waves;
include migration, dual-running, training, licensing, and exit costs;
rehearse testing, cutover, recovery, and rollback;
measure reliability, security, adoption, delivery performance, and unit cost;
treat organisational change as a workstream with resources and outcomes; and
review the roadmap continuously as evidence, constraints, and business priorities change.
Chapter Summary
Cloud migration is a portfolio and organisational transformation challenge, not simply a hosting change. Effective assessment combines business value, technical fitness, data characteristics, dependencies, cost, risk, and readiness. Weighted scoring can structure decisions, but professional judgement and evidence remain essential.
The principal strategies are rehost, replatform, refactor, repurchase, retain, retire, and, in some contexts, relocate. Their suitability depends on desired outcomes, constraints, risk tolerance, and the value of architectural change. A roadmap should progress from discovery and assessment through landing-zone design, pilot, migration waves, modernisation, and optimisation, with governance operating throughout.
A target operating model must address accountability, platform engineering, security, resilience, service management, financial management, and skills. Organisational change, privacy, compliance, supplier concentration, sustainability, and ethical effects are central design concerns. Finally, successful programmes validate business outcomes after migration and distinguish genuine transformation from the temporary relocation of legacy systems.
Key Terms
Application portfolio: The set of applications and associated services managed by an organisation.
Cloud migration: Movement or transformation of workloads, data, and capabilities into cloud environments.
Digital transformation: Organisational change that uses digital capabilities to redesign value creation and operations.
Dependency: A relationship in which one component relies on another.
Landing zone: A governed foundational cloud environment containing identity, networking, security, logging, and policy controls.
Migration wave: A planned group of workloads moved and validated together.
Rehost: Moving a workload with minimal application modification.
Replatform: Moving a workload while making limited platform or runtime changes.
Refactor: Redesigning application architecture to improve qualities such as scalability or maintainability.
Repurchase: Replacing an existing capability with a different product, commonly SaaS.
Retain: Keeping a workload in its current environment for a justified reason.
Retire: Removing an obsolete or duplicated application.
Technical debt: Future cost or risk created by earlier design or implementation compromises.
Total cost of ownership: The full cost of acquiring, operating, changing, and retiring a capability over a defined period.
FinOps: A discipline linking cloud financial management with engineering and business accountability.
Operating model: The structure of people, processes, technology, governance, and accountability used to deliver services.
Rollback: Reversing a change to a previous operating state under defined conditions.
Service-level objective: A measurable target for a service characteristic such as availability or latency.
Review Questions
5 Short Answer Questions
Distinguish cloud migration from digital transformation.
What is the purpose of a dependency map?
Define replatforming and give one reason for using it.
Why should dual-running costs be included in a business case?
Name three responsibilities that commonly remain with the cloud customer.
5 Long Answer Questions
Explain how business value, technical fitness, and changeability can be used to assess an application portfolio.
Compare rehost, replatform, and refactor, including the circumstances and risks associated with each.
Describe the stages of a migration roadmap and explain why governance should continue across all stages.
Discuss the components of a cloud target operating model.
Explain how privacy, security, supplier concentration, and organisational change affect migration decisions.
3 Analytical / Application Questions
An organisation has a high-value application with poor scalability, undocumented integrations, and a fixed migration deadline. Recommend a migration strategy and wave approach, stating assumptions and risks.
Design a weighted portfolio assessment model for a university’s student-information applications. Justify your criteria and explain why the resulting score should not be treated as an automatic migration order.
A proposed migration shows lower infrastructure cost but requires expensive retraining, three years of dual running, and extensive data-transfer controls. Analyse whether the business case is complete and identify additional evidence required before approval.
Multiple Choice Questions with Answers
Question 1
Which strategy moves an application with minimal code change?
A. Rehost
B. Refactor
C. Repurchase
D. Retire
Correct Answer: A. Rehost
Question 2
In the weighted portfolio formula, what does wᵢ represent?
A. The application’s downtime
B. The weight assigned to criterion i
C. The migration duration
D. The annual cloud cost
Correct Answer: B. The weight assigned to criterion i
Question 3
Which item is most clearly a hard technical dependency?
A. A service cannot operate without its identity provider
B. A team prefers a particular dashboard
C. A user requests a new feature
D. A supplier publishes a marketing brochure
Correct Answer: A. A service cannot operate without its identity provider
Question 4
What is the primary purpose of a cloud landing zone?
A. To remove all legacy applications immediately
B. To provide governed foundational controls for cloud workloads
C. To calculate employee salaries
D. To replace business ownership
Correct Answer: B. To provide governed foundational controls for cloud workloads
Question 5
Which strategy removes an obsolete or duplicated application?
A. Retain
B. Replatform
C. Retire
D. Rehost
Correct Answer: C. Retire
Question 6
Which cost is often omitted from an unrealistic cloud business case?
A. Dual running during transition
B. The application name
C. The organisation’s logo
D. The number of users’ job titles
Correct Answer: A. Dual running during transition
Question 7
For a 30-day month with a 99.9% availability objective, the approximate permitted unavailability is:
A. 4.32 minutes
B. 43.2 minutes
C. 432 minutes
D. 0.432 minutes
Correct Answer: B. 43.2 minutes
Question 8
What should a rollback plan specify?
A. Only the preferred cloud region
B. The rollback point, conditions, authority, and data implications
C. Only the project logo
D. A guarantee that no testing is required
Correct Answer: B. The rollback point, conditions, authority, and data implications
Question 9
Which statement best describes digital transformation?
A. Changing a server’s physical location only
B. Redesigning organisational value creation and operations through digital capabilities
C. Buying additional storage without process change
D. Deleting all on-premises documentation
Correct Answer: B. Redesigning organisational value creation and operations through digital capabilities
Question 10
Why should AI-generated migration recommendations be human-validated?
A. AI can never process any technical information
B. Inventories may be incomplete and automated recommendations may create risk
C. Cloud services do not support automation
D. Validation prevents all future costs
Correct Answer: B. Inventories may be incomplete and automated recommendations may create risk