14. Migration, Modernization and Multi-Cloud Strategy

Introduction and Context

Cloud adoption is not completed when an application is moved from a data centre to a virtual machine in the cloud. Migration changes the location, operating model, economics, security responsibilities, skills requirements and governance of information systems. Modernization goes further: it changes the way applications are designed, delivered and operated so that the organisation can obtain capabilities such as elasticity, automation, resilience, managed services and faster innovation.

For a postgraduate cloud professional, migration is therefore both a technical programme and a strategic portfolio decision. The central question is not simply “Which cloud should host this workload?” It is “What business outcome should this workload support, what operating model is appropriate, and what level of technological change is justified?”

Large organisations commonly operate a heterogeneous estate: legacy mainframes, packaged enterprise systems, virtual machines, containers, serverless functions, databases, analytics platforms and software-as-a-service products. These workloads differ in business criticality, regulatory sensitivity, architecture, technical debt and readiness for change. A disciplined strategy must evaluate this diversity rather than apply one migration pattern to every system.

This chapter examines assessment frameworks, migration strategies, modernization choices, organisational change, vendor risk, interoperability and portfolio governance. AWS, Microsoft Azure and Google Cloud Platform provide different services and terminology, but the underlying strategic principles are broadly transferable.

Learning Objectives

After studying this chapter, the learner should be able to:

1. Assess workloads using cloud adoption and well-architected principles.

2. Distinguish among rehost, relocate, replatform, refactor, repurchase, retain and retire decisions.

3. Construct a migration roadmap based on value, risk, dependency and organisational readiness.

4. Evaluate the economic, technical, security, regulatory and operational consequences of multi-cloud adoption.

5. Explain how leadership, skills, governance and communication influence migration outcomes.

6. Analyse vendor lock-in, portability, interoperability and exit risks.

7. Apply portfolio thinking to a realistic migration and modernization case.

From Cloud Migration to Digital Transformation

Migration is the movement of applications, data and infrastructure to a new hosting or operating environment. Modernization is the improvement of an existing system’s architecture, platform or delivery practices. Digital transformation is broader still: it reshapes products, processes, decision-making and organisational capabilities through digital technology.

These concepts are related but not identical. A rehosted application may be migrated without being modernized. A refactored application may be modernized without changing its business process. Transformation occurs when technology enables a materially different way of creating value—for example, when a batch-based insurance process becomes an event-driven service that provides near-real-time customer decisions.

A useful strategic distinction is between the technical estate and the business capability map. The technical estate lists servers, applications, databases and interfaces. The capability map describes functions such as payments, order fulfilment, claims processing or customer identity. Migration decisions should be anchored in capabilities because technical components are valuable only insofar as they support business outcomes.

Typical strategic drivers include data-centre exit, improved resilience, faster product delivery, capacity flexibility, reduction of hardware ownership, access to advanced analytics and compliance with geographic requirements. Drivers may conflict. A data-centre exit favours speed, whereas modernization may favour deeper redesign. Cost reduction may favour standardisation, whereas regional resilience may require duplication. Explicitly identifying these tensions prevents unrealistic business cases.

Assessing Workloads Before Choosing a Strategy

A migration assessment should combine business, technical, financial and organisational evidence. Inventory tools can discover hosts, software versions, traffic and dependencies, but automated discovery cannot determine business criticality or contractual obligations. Interviews with product owners, architects, operations staff, security teams and finance specialists remain essential.

For each workload, the assessment should establish:

• business owner, purpose and value;
• users, transaction patterns and service-level objectives;
• application, database, storage and integration dependencies;
• data classification, residency and retention requirements;
• availability, recovery-time and recovery-point objectives;
• performance characteristics and peak-to-average demand;
• licensing, support and contractual constraints;
• current cost, technical debt and operational effort;
• cloud readiness, skills requirements and migration complexity.

A practical assessment separates facts, assumptions and decisions. For example, “the application uses an Oracle database” is a fact; “the workload can operate on a managed PostgreSQL service” is an assumption requiring validation; “the database will be replatformed in phase two” is a decision. This discipline improves governance and makes later changes traceable.

Cloud Adoption and Well-Architected Perspectives

Cloud adoption frameworks generally organise change across several perspectives. These commonly include business strategy, people and skills, governance, platform or technology, security and operations. The exact names vary among providers, but the principle is consistent: a technically successful migration can still fail if operating responsibilities, funding, risk controls or staff capability are absent.

The well-architected approach evaluates workloads against recurring quality attributes. These include operational excellence, security, reliability, performance efficiency, cost optimisation and sustainability. The categories are not independent. For example, aggressive cost reduction may reduce redundancy and therefore weaken reliability; stronger encryption and audit controls may increase cost but be necessary for compliance.

Assessment should therefore record trade-offs rather than produce a simplistic score. A workload with low cloud readiness but high business value may deserve investment in platform engineering. A low-value system with high migration complexity may be a candidate for retirement. A high-criticality system with uncertain dependencies should not be used as the first migration experiment merely because it is visible to senior management.

Useful portfolio dimensions include business criticality, change complexity, migration risk, strategic value, regulatory sensitivity and expected financial benefit. A scoring model can support prioritisation, but scores should inform managerial judgement rather than replace it. Weightings must be agreed with stakeholders and reviewed when strategic priorities change.

The Seven Migration Decisions

The commonly used “seven Rs” provide a vocabulary for migration planning. They are not seven rigid technical procedures; they are decision categories that connect business intent to implementation effort.

Rehost

Rehost, often called lift and shift, moves an application with minimal code change, commonly by transferring virtual machines or images to cloud infrastructure. It is suitable when speed, data-centre exit or short-term risk reduction is more important than architectural improvement. It can provide infrastructure flexibility, but it may preserve inefficient licensing, weak automation and assumptions about fixed capacity. Rehosting should not be mistaken for modernization.

Relocate

Relocate moves a workload to a different cloud hosting construct without redesigning its fundamental architecture. Examples include moving virtual machines to a specialised hosted environment or transferring a virtualised estate to a cloud VMware service. Relocation can reduce disruption where application compatibility is important, but it may deliver fewer cloud-native benefits than replatforming.

Replatform

Replatform introduces limited optimisations while preserving the application’s core design. Examples include moving a self-managed database to a managed database service, replacing manually configured virtual machines with a managed container platform, or adopting automated scaling. This strategy can improve operational efficiency without the cost and risk of full redesign. Compatibility, feature differences, performance and exit options must be tested carefully.

Refactor or Re-architect

Refactoring changes internal structure without changing the intended business behaviour; re-architecting may change the system’s fundamental design. A monolith may be decomposed into services, synchronous processing may become event-driven, and a tightly coupled database may be redesigned around domain boundaries. These approaches can improve release speed, resilience and scalability, but require strong product ownership, testing, observability and architectural governance. Refactoring should be justified by measurable business or operational outcomes, not by fashion.

Repurchase

Repurchase replaces an existing system with a different product, often a software-as-a-service solution. It can eliminate maintenance of commodity capabilities such as collaboration, customer support or human-resource administration. The organisation must assess data migration, process redesign, integration, service continuity, privacy, contractual terms and the possibility that customisation will be reduced.

Retain

Retain means keeping a workload in its current environment for a justified period. Reasons include regulatory restrictions, unresolved dependencies, stable economics, hardware-specific requirements or a planned replacement. Retention should be an explicit, reviewed decision rather than the result of inaction. Every retained workload should have an owner, review date and risk treatment.

Retire

Retire removes an application or capability that is duplicated, obsolete, unused or no longer economically justified. Retirement often produces more value than migration because it reduces licences, support effort, vulnerabilities and operational complexity. Evidence is important: apparent inactivity may conceal reporting, legal retention or emergency-use requirements.

These decisions can change over time. A retained legacy system may later be repurchased; a rehosted workload may subsequently be replatformed. Migration planning is therefore iterative rather than a once-only classification exercise.

Designing a Migration Roadmap

A roadmap converts assessment into coordinated action. It should identify waves of work, dependencies, decision gates, funding, owners, measures and rollback arrangements. A common pattern is to establish a landing zone first. A landing zone is a governed cloud foundation containing identity, network connectivity, account or subscription structure, logging, security controls, policy, tagging, backup and baseline automation.

Early migration waves should normally contain representative but manageable workloads. A pilot tests connectivity, identity, deployment pipelines, monitoring, cost controls, security controls and operational support. It should not be selected solely because it is technically easy; it should generate reusable learning. Subsequent waves can group applications by business capability or dependency cluster rather than by server ownership alone.

Dependency mapping is especially important. Moving an application without its database, identity provider, message broker, batch scheduler or external interface may create latency, inconsistent data or an unsupported hybrid arrangement. Data migration requires decisions about replication, cutover, reconciliation, encryption, retention and rollback. A migration runbook should define entry criteria, technical steps, validation tests, communication, decision authority and exit criteria.

Migration success should be measured across more than completion volume. Relevant measures include service availability, transaction performance, incident rates, recovery-test results, deployment frequency, lead time, cloud spend against forecast, security findings, user experience and retirement of legacy assets. A workload declared “complete” before it is operated reliably merely transfers risk from the project team to the service team.

Economics and Portfolio Governance

Cloud economics require more than comparing a hardware invoice with a monthly cloud bill. A total-cost model may include compute, storage, network transfer, managed services, licences, support, migration tooling, duplicated environments, training, security controls, refactoring and decommissioning. It should also represent variable demand, reserved or committed-use pricing, data egress and the cost of resilience.

Financial analysis should distinguish run costs from change costs. Migration may require a temporary period in which both old and new environments operate. Benefits may be strategic rather than immediate, such as faster experimentation or reduced operational risk. Conversely, a technically successful move can increase costs if resources are poorly sized, idle environments remain active or architecture creates excessive data transfer.

FinOps practices connect engineering, finance and product teams. They include allocation through tags or accounts, budget alerts, unit-cost measurement, rightsizing, scheduling of non-production resources and review of managed-service consumption. Cost governance must avoid incentives that undermine reliability or security.

At portfolio level, leaders should balance quick wins, foundational investments and high-value transformations. A portfolio board can review dependencies, risk concentration, benefits realisation and capacity for organisational change. Funding models should support products or capabilities rather than encourage projects to optimise isolated infrastructure metrics.

Organisational Change and Operating Model

Migration changes roles. Infrastructure staff may become platform engineers; database administrators may manage cloud database services and data governance; security teams may embed controls into delivery pipelines; developers may become responsible for operational behaviour through DevOps or site reliability practices. These changes can create anxiety, especially when cloud adoption is interpreted as a plan to reduce staff.

Effective change management explains why the organisation is changing, what will change, what will not change and how people will be supported. Skills programmes should combine formal learning with labs, pairing, communities of practice and real migration work. A cloud centre of excellence can provide reusable patterns, guardrails and coaching, but it should not become a bottleneck that approves every technical decision.

The target operating model must clarify ownership. The shared-responsibility model does not mean that the provider operates everything: the customer remains responsible for appropriate configuration, identity, data protection, workload security and service use. RACI matrices, service catalogues, escalation procedures and operational readiness reviews make these responsibilities concrete.

Culture also matters. Teams that are punished for every incident may hide risk; teams without accountability may create uncontrolled cloud sprawl. Blameless post-incident learning, automated policy enforcement and measurable service ownership encourage responsible autonomy.

Multi-Cloud Strategy: Choice, Resilience and Complexity

Multi-cloud means using services from more than one public cloud provider. It may arise from acquisitions, regional availability, customer requirements, regulatory constraints, best-of-breed preferences or a desire to avoid dependence on one provider. It is not automatically more resilient. If teams lack consistent identity, monitoring, skills and recovery procedures, multiple clouds can multiply failure modes.

A strategic decision must distinguish intentional multi-cloud from accidental fragmentation. Intentional multi-cloud defines the business problem, workload placement principles, common controls and operating responsibilities. It may place analytics in one provider, a regulated application in another and commodity collaboration in a SaaS platform. Accidental fragmentation occurs when teams independently select services without shared architecture or governance.

Interoperability has several layers. At the infrastructure layer, networks, identity federation, DNS, encryption and connectivity must work across environments. At the data layer, formats, metadata, replication, consistency and transfer costs matter. At the application layer, APIs, containers, event standards and deployment pipelines influence portability. At the management layer, organisations need unified asset inventory, observability, policy and incident response.

Portability is not free. Designing for every provider can lead to the lowest common denominator and prevent use of valuable managed capabilities. A more realistic approach is portable where strategic, specialised where valuable. For critical workloads, teams should identify exit assumptions, maintain tested data-export mechanisms, document dependencies and periodically rehearse recovery or migration to an alternative environment.

Vendor risk includes price changes, service discontinuation, concentration, support quality, geopolitical exposure, contractual restrictions, data-access barriers and skills scarcity. Contracts should address service levels, audit rights, data return and deletion, security obligations, incident notification, subcontractors, termination assistance and exit costs. Legal review is essential because technical portability cannot overcome an impractical contract.

Security, Governance and Ethical Considerations

Migration may expose sensitive data during discovery, replication and cutover. Data classification should precede design. Encryption in transit and at rest, least-privilege identity, key-management controls, secrets management, segmentation, vulnerability management and centralised logging are baseline expectations. Security controls should be implemented as code where feasible so that environments are reproducible and auditable.

Governance must address residency, privacy, records management, sector regulation, accessibility, intellectual property and cross-border transfers. A workload may be technically deployable in a region but legally unsuitable there. Retention and deletion obligations must survive migration; copying data into temporary environments can create unrecorded compliance exposure.

Modernization also raises ethical issues. Data consolidation may enable analytics that affect individuals, while automated decision systems may reproduce bias or make accountability unclear. Organisations should define purpose limitation, access controls, human oversight, explainability expectations and processes for correcting inaccurate data. Responsible cloud strategy treats trust as an architectural and managerial requirement, not merely a public-relations concern.

Technology, Automation and Emerging Directions

Infrastructure as code enables repeatable environments, peer review and policy checks. Continuous integration and delivery can automate testing, security scanning, infrastructure deployment and controlled rollback. Discovery and dependency tools accelerate inventory, while observability platforms correlate logs, metrics and traces across hybrid estates.

Artificial intelligence is increasingly used to classify applications, identify anomalous spend, suggest rightsizing, map dependencies and assist code conversion. These uses require human validation because automated recommendations may misunderstand undocumented business rules, produce insecure code or expose sensitive information to external systems. AI should support assessment and engineering judgement rather than become an unreviewed migration authority.

Emerging strategies include platform engineering, internal developer platforms, application-aware disaster recovery, confidential computing, sovereign-cloud arrangements and increased use of managed data and AI services. Kubernetes and container standards can improve deployment consistency, but they do not eliminate provider dependence: storage, identity, networking, observability and managed control planes may remain provider-specific. Edge and distributed-cloud architectures also require careful operational design because intermittent connectivity and physical exposure complicate governance.

Illustrative Case Study: Meridian Retail Group

Background

Meridian Retail Group, a fictional regional retailer, operates an online store, warehouse systems, a loyalty platform and several reporting applications. Its data centre contract expires in eighteen months. The estate includes a Java monolith, an Oracle database, virtualised warehouse software, a data warehouse and a collection of unused departmental applications. Sales leadership wants faster digital releases, while finance requires predictable costs and the legal team requires appropriate handling of customer data.

Situation and Analysis

An initial inventory discovers 146 virtual machines, but interviews reveal that only 82 support active business capabilities. Dependency analysis shows that the online store, identity service, payment gateway and inventory system form a critical transaction chain. The reporting environment contains duplicated historical data, and several applications have no identifiable business owner. The Oracle database is heavily customised, making immediate conversion risky.

The assessment scores workloads on criticality, complexity, regulatory sensitivity, technical readiness and expected value. The online store is high value and medium readiness; warehouse control is high criticality and low readiness; departmental reporting is low value and high redundancy. The team concludes that a single “lift and shift” programme would preserve technical debt and fail to improve release speed.

Strategy and Approach

Meridian establishes a landing zone with separate accounts for production, non-production, security and shared services. Central identity, logging, network controls, backup policies and tagging are implemented through infrastructure as code. A cross-functional migration board includes product, operations, security, finance, legal and business representatives.

The first wave rehosts a low-risk internal application and repurchases collaboration software. This tests connectivity, identity, monitoring and cost allocation. The second wave replatforms the reporting database to a managed analytics service after data-quality and reconciliation testing. Duplicate reports are retired rather than migrated.

For the online store, Meridian first relocates compatible virtual machines to meet the data-centre deadline. It then refactors selected order and inventory functions into services behind stable APIs. The Oracle database is retained temporarily because its custom logic is business-critical; a later programme will assess replatforming after application boundaries are better understood. Warehouse control is retained on-site with secure connectivity because its latency and operational dependencies make immediate migration hazardous.

Outcome

The organisation exits the data centre on schedule without treating all systems identically. The first waves establish reusable controls and reveal that untagged development environments were creating avoidable cost. The online store gains automated deployment and improved observability, while the retained warehouse system receives a documented review date and tested connectivity. Meridian does not claim that multi-cloud is required; it uses a primary provider and permits a second provider only where a documented regulatory or business rationale exists.

Learning Points

The case illustrates that migration sequencing should follow dependency and risk logic, not server counts. Retirement and repurchase can create value quickly. Temporary rehosting may be rational when paired with a modernization path. Finally, governance, operational readiness and ownership are as important as the target architecture.

Challenges and Common Mistakes

Common failures include beginning migration without a reliable inventory, treating cloud as a cheaper data centre, selecting a provider before clarifying requirements, underestimating data transfer and licensing, ignoring non-production environments, and declaring success at cutover rather than after stable operations. Other mistakes include refactoring too much at once, retaining undocumented interfaces, assuming containers guarantee portability, and adopting multi-cloud as a slogan.

Migration programmes also suffer from weak decision rights. If no person can resolve a conflict between security, delivery speed and cost, work stalls or bypasses governance. Excessive central control creates another problem: delivery teams wait for approval and invent unsanctioned workarounds. Guardrails, reference architectures and automated controls are usually more effective than manual approval of every resource.

A final risk is benefit illusion. A programme may report hundreds of migrated servers while business outcomes remain unchanged. Benefits should be tied to measurable improvements such as reduced recovery time, shorter release lead time, lower unit cost, improved availability or retirement of obsolete capability.

Best-Practice Principles

1. Begin with business capabilities and outcomes, then map technology dependencies.

2. Establish a governed landing zone before scaling migration waves.

3. Use the seven Rs as decision categories, not as automatic prescriptions.

4. Separate migration, modernization and transformation benefits in the business case.

5. Pilot representative workloads and turn lessons into reusable patterns.

6. Treat security, resilience, cost and observability as design requirements.

7. Make retain and retire decisions explicit, owned and time-bounded.

8. Design multi-cloud only where its benefits justify additional complexity.

9. Maintain documented exit assumptions, contractual protections and tested recovery procedures.

10. Measure operational and business outcomes after migration, not only project completion.

Chapter Summary

Migration and modernization are strategic choices concerning business capabilities, operating models and risk, not merely the relocation of servers. Workloads should be assessed through business value, dependency, readiness, security, resilience, cost and organisational capability. The seven Rs—rehost, relocate, replatform, refactor, repurchase, retain and retire—provide a structured vocabulary for selecting an appropriate level of change.

A successful roadmap establishes governance and a landing zone, sequences dependency-aware waves, validates data and operations, and measures benefits after cutover. Organisational change, skills, ownership and communication determine whether technology improvements become sustainable capabilities. Multi-cloud can provide choice or satisfy genuine regulatory and resilience needs, but it introduces interoperability, governance, skills and exit challenges. The strongest strategies are evidence-based, explicit about trade-offs and designed for continuous review.

Key Terms

Cloud migration: Movement of workloads, data or services to a different hosting or operating environment.

Modernization: Improvement of an application’s architecture, platform or delivery practices.

Digital transformation: Organisational change that uses digital capabilities to reshape value creation and operations.

Workload: An application, service, data platform or related set of components operated to perform a business function.

Landing zone: A governed cloud foundation containing baseline identity, networking, security, logging and policy controls.

Well-architected framework: A structured method for evaluating quality attributes such as security, reliability, performance and cost.

Rehost: Migration with minimal application modification.

Relocate: Movement to another hosting construct while preserving the fundamental architecture.

Replatform: Limited optimisation using managed or improved platform services.

Refactor: Modification of internal application structure to improve maintainability or delivery.

Repurchase: Replacement of an existing system with a different product or SaaS service.

Retain: Deliberate continuation of a workload in its existing environment.

Retire: Removal of an obsolete, duplicated or unjustified workload.

Interoperability: Ability of systems, data and processes in different environments to work together.

Portability: Ability to move a workload or its data between environments with acceptable effort.

Vendor lock-in: Dependence that makes changing providers difficult or costly.

FinOps: Collaborative financial management of cloud consumption and value.

Recovery-time objective: Target maximum duration for restoring a service after disruption.

Recovery-point objective: Target maximum tolerable amount of data loss measured in time.

Shared responsibility model: Allocation of security and operational duties between provider and customer.

Review Questions

Short Answer Questions

1. Distinguish migration, modernization and digital transformation.

2. What information should be collected during a workload assessment?

3. Why is a landing zone important in a migration programme?

4. Explain the difference between rehost and replatform.

5. What is accidental multi-cloud fragmentation?

Long Answer Questions

1. Explain how the seven migration decisions support strategic workload planning.

2. Discuss how well-architected principles can reveal trade-offs rather than simply produce scores.

3. Describe the major stages of a dependency-aware migration roadmap.

4. Analyse the organisational changes required for cloud operating-model adoption.

5. Evaluate the benefits and risks of a deliberate multi-cloud strategy.

Analytical / Application Questions

1. A regulated payment application has high business criticality, undocumented interfaces and strict latency requirements. Which migration decision would you initially recommend, and what evidence would be needed before changing it?

2. An organisation reports that cloud costs increased after migration although server numbers declined. Analyse possible causes and propose a FinOps investigation.

3. A company wants to use three cloud providers solely to avoid vendor lock-in. Develop criteria for deciding whether this strategy is justified.

22. Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes modernization from simple migration?

A. Modernization always means moving to a different public cloud provider.

B. Modernization improves architecture, platform or delivery practices to achieve better capabilities.

C. Modernization is limited to purchasing new hardware.

D. Modernization eliminates the need for governance.

Correct Answer: B. Modernization improves architecture, platform or delivery practices to achieve better capabilities.

Question 2

A legacy application must be moved quickly for a data-centre closure, but its code will remain substantially unchanged. Which strategy is most appropriate initially?

A. Rehost

B. Repurchase

C. Retire

D. Refactor

Correct Answer: A. Rehost

Question 3

Why should a retained workload have a review date and named owner?

A. To ensure every workload is eventually refactored.

B. To prevent an explicit temporary decision from becoming unmanaged inaction.

C. To guarantee that its cloud cost is zero.

D. To make the workload portable across all providers.

Correct Answer: B. To prevent an explicit temporary decision from becoming unmanaged inaction.

Question 4

Which activity most directly supports a dependency-aware migration wave?

A. Counting only the virtual machines owned by the infrastructure team.

B. Mapping databases, identity services, schedulers and external interfaces used by the application.

C. Selecting the provider with the largest service catalogue.

D. Migrating the highest-profile application first.

Correct Answer: B. Mapping databases, identity services, schedulers and external interfaces used by the application.

Question 5

Which statement about multi-cloud is most accurate?

A. Using multiple providers automatically produces higher resilience.

B. Multi-cloud removes all forms of vendor lock-in.

C. Multi-cloud can satisfy genuine business needs but adds operational and governance complexity.

D. Multi-cloud means using multiple availability zones in one provider.

Correct Answer: C. Multi-cloud can satisfy genuine business needs but adds operational and governance complexity.

Question 6

A company replaces an internally operated HR system with a SaaS product. Which migration decision does this represent?

A. Replatform

B. Repurchase

C. Relocate

D. Retain

Correct Answer: B. Repurchase

Question 7

Which item is primarily a benefit-realisation measure rather than a migration-volume measure?

A. Number of servers copied

B. Number of accounts created

C. Reduction in release lead time

D. Number of migration meetings

Correct Answer: C. Reduction in release lead time

Question 8

What is a significant limitation of designing every workload for maximum portability?

A. It may force use of a lowest-common-denominator architecture and forgo valuable managed services.

B. It makes data classification unnecessary.

C. It guarantees lower operating costs.

D. It prevents the use of infrastructure as code.

Correct Answer: A. It may force use of a lowest-common-denominator architecture and forgo valuable managed services.

Question 9

Which practice best addresses organisational change during migration?

A. Restricting cloud knowledge to a central architecture team.

B. Combining training, practical migration work, communities of practice and clear ownership.

C. Avoiding communication until the migration is complete.

D. Measuring success only by staff reduction.

Correct Answer: B. Combining training, practical migration work, communities of practice and clear ownership.

Question 10

A reporting application has no active users, duplicates another system and has no legal retention requirement. Which decision is most defensible?

A. Retain

B. Rehost

C. Retire

D. Refactor

Correct Answer: C. Retire