Migration, Resilience and Disaster Recovery

Introduction

Cloud adoption is not simply the transfer of servers from a data centre to AWS or Google Cloud. It is a controlled change to business services, data, operating processes, security controls and technical dependencies. A migration can improve scalability and availability, but it can also introduce failure modes, compliance problems and unexpected operational costs.

This chapter presents a practical framework for assessing workloads, selecting migration strategies, identifying dependencies and risks, designing highly available architectures, and defining and testing recovery objectives. AWS and Google Cloud use different service names, but the underlying principles—redundancy, isolation, recoverability, observability and tested procedures—are broadly transferable.

Learning Objectives

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

• assess a workload for cloud migration readiness;
• select an appropriate migration strategy;
• map technical, operational and business dependencies;
• identify migration and operational risks;
• design architectures that tolerate component and location failures;
• distinguish high availability, backup, disaster recovery and business continuity;
• define and calculate recovery time objective (RTO) and recovery point objective (RPO);
• select suitable backup, replication and failover mechanisms; and
• plan exercises that validate recovery assumptions.

1. Migration as a Business and Technical Change

A workload is more than an application binary. It includes compute, storage, databases, networks, identities, secrets, monitoring, deployment pipelines, support procedures, vendors, users and data flows. Migration is therefore successful only when the service remains secure, usable and supportable after the transition.

A useful assessment considers four dimensions:

1. Business criticality: What revenue, safety, legal or operational consequences follow from an outage?
2. Technical condition: Is the application documented, supported and compatible with the proposed platform?
3. Data characteristics: What are the volume, growth rate, sensitivity, consistency and locality requirements?
4. Organisational readiness: Are skills, budgets, change controls and on-call capabilities available?

A migration should have explicit entry and exit criteria. Examples include an approved architecture, tested rollback, validated data reconciliation, security approval, performance evidence and an operational handover.

2. The Main Migration Strategies

The commonly used strategies are often called the “seven Rs.” They are not seven universally mandatory categories; they are a decision vocabulary.

The correct strategy can differ by component. An application may be rehosted while its database is replatformed and an obsolete reporting tool is retired. A portfolio decision should therefore avoid treating an entire business system as a single indivisible item.

Decision Considerations

A practical decision matrix scores each option against business value, technical effort, risk, time, compliance and operating cost. Scores should be supported by evidence rather than optimism. Refactoring is not automatically superior: a stable, low-criticality system may obtain little value from a costly redesign. Conversely, rehosting a tightly coupled, fragile system may merely relocate its risks.

3. Dependency and Risk Analysis

Dependency Mapping

Dependency mapping identifies what must be available for a service to function. Record both direct and indirect dependencies:

• users, channels and upstream applications;
• DNS, certificates, identity providers and secrets;
• APIs, queues, scheduled jobs and file transfers;
• databases, caches, object storage and search indexes;
• third-party services, payment providers and software licences;
• monitoring, logging, deployment and incident-management tools; and
• people, suppliers and manual procedures.

For each dependency, document the owner, interface, authentication method, failure behaviour, data classification, latency requirement and recovery method. A dependency map should be validated with application owners and observed through logs and network telemetry; architecture diagrams alone are frequently incomplete.

A critical path is the sequence of dependencies that must succeed for a business transaction to complete. A non-critical reporting service may be unavailable while order processing continues, whereas the identity provider or payment gateway may be essential.

Risk Analysis

Risk is commonly assessed as a combination of likelihood and consequence. A qualitative matrix may classify both on a scale such as low, medium and high. Quantitative estimates can be useful when reliable evidence exists. An illustrative annualised loss estimate is:

Here, ALE is annualised loss expectancy in currency per year, SLE is single-loss expectancy in currency, and ARO is annual rate of occurrence. The expression assumes that the loss estimate and occurrence rate are meaningful and that repeated events can reasonably be represented by an average. It is not a guarantee of future loss and should not obscure low-frequency catastrophic events.

Risk treatment may involve reducing likelihood, reducing impact, transferring risk through contracts or insurance, avoiding the activity, or accepting the residual risk with accountable approval.

Typical migration risks include incomplete dependency discovery, data corruption, incompatible network addressing, inadequate bandwidth, privilege errors, licensing restrictions, untested rollback, vendor outages and staff unfamiliarity with the target platform. Each risk should have an owner, trigger, mitigation, contingency and review date.

4. High Availability and Resilience

Resilience is the ability of a service to withstand, recover from and adapt to adverse conditions. High availability (HA) focuses on maintaining service access despite defined failures. HA is not identical to disaster recovery: an HA design may handle a failed instance automatically, while a disaster recovery plan addresses loss of a site, region, account or major operating capability.

Failure Domains

Cloud designs should identify failure domains, including:

• process or container;
• virtual machine;
• host;
• rack or availability zone;
• region;
• cloud account or project;
• provider; and
• people, software supply chain or control plane.

AWS Availability Zones are separate locations within an AWS Region; Google Cloud zones are deployment areas within regions. Multi-zone design reduces the impact of many infrastructure failures, but it does not protect against every application defect, credential compromise or region-wide event.

Architectural Patterns

A highly available web service commonly uses DNS or a global load-balancing layer, multiple application instances across zones, stateless session handling, replicated data services, health checks and automated replacement. Stateful components require particular care: replication mode, quorum, consistency, failover authority and split-brain prevention must be understood rather than assumed.

Useful patterns include:

• horizontal scaling: adding instances rather than relying on one larger instance;
• active-active: multiple sites serve traffic concurrently;
• active-passive: a standby site takes traffic after failover;
• queue-based decoupling: producers and consumers are separated so temporary failures can be absorbed;
• bulkheads: failure in one component is prevented from exhausting shared resources;
• timeouts, retries and circuit breakers: calls fail predictably rather than creating cascading overload; and
• graceful degradation: non-essential functions are disabled while core service continues.

Retries require bounded attempts, backoff and idempotent operations. Blind retries can multiply load and duplicate transactions. Health checks should test meaningful service readiness, not merely whether a process is running.

5. RTO, RPO and Related Measures

Recovery time objective (RTO) is the maximum targeted duration from service disruption to restoration of an acceptable service level. Recovery point objective (RPO) is the maximum targeted amount of data loss measured in time, such as fifteen minutes of transactions.

RTO and RPO are business requirements, not automatically supplied by a cloud service tier. They should be agreed with process owners and translated into technical controls.

A simple recovery timeline is:

Figure: RTO concerns restoration time, whereas RPO concerns the age of the latest recoverable data.

If an outage begins at 10:00 and the target RTO is two hours, acceptable restoration should occur by 12:00. If the RPO is fifteen minutes, the recovery process should normally restore data to a point no earlier than approximately 09:45, subject to the agreed definition and transaction consistency.

Other useful measures include mean time to detect (MTTD), mean time to acknowledge (MTTA) and mean time to restore (MTTR). These are operational observations, not substitutes for business-defined RTO and RPO.

6. Backup, Replication and Disaster Recovery Patterns

A backup is a recoverable copy of data or configuration. Replication maintains one or more additional copies, often with lower recovery latency but greater exposure to propagating corruption or deletion. High availability keeps a service running; backup enables recovery from logical errors, ransomware or accidental deletion.

A robust backup design addresses:

• scope: databases, objects, volumes, configurations, code, secrets and infrastructure definitions;
• frequency and retention;
• encryption in transit and at rest;
• immutability or write protection;
• separation of backup credentials and accounts/projects;
• cross-zone or cross-region storage;
• cataloguing and restore verification; and
• legal retention and secure deletion.

Common recovery patterns are:

These are broad patterns, not guaranteed service levels. Actual performance depends on data size, replication, automation, quotas, DNS or routing convergence, testing and human decisions.

Recovery must include more than infrastructure. Restore application versions, schema compatibility, queues, certificates, access policies, feature flags, observability and customer communication procedures. Infrastructure as code helps recreate environments, but it does not replace data backups or recovery testing.

7. Business Continuity and Governance

Business continuity (BC) is the broader capability to continue or resume important business processes during disruption. Disaster recovery (DR) is the technology and process capability for restoring services and data. Continuity may require alternate staff, manual workarounds, supplier communication, workspace arrangements and prioritisation of customers.

A continuity plan should define:

• critical business services and minimum acceptable service levels;
• accountable owners and decision authority;
• communication channels, including out-of-band channels;
• regulatory, contractual and evidence requirements;
• manual processing and customer notification procedures; and
• criteria for invoking, escalating and ending the plan.

Cloud governance should address least privilege, separation of duties, logging, encryption, data residency, retention, incident reporting and supplier concentration risk. A cloud provider’s shared-responsibility model does not transfer the customer’s responsibility for configuration, identities, data protection and recovery decisions.

8. Testing Recovery Claims

A recovery plan is an untested hypothesis. Testing should progress from low-risk validation to realistic exercises:

1. Document review: confirm owners, contacts, prerequisites and sequence.
2. Backup restore test: restore selected data into an isolated environment and validate integrity.
3. Component test: fail a service instance, zone or dependency where safe.
4. Simulation or tabletop: rehearse decisions, communications and escalation without changing production.
5. Technical failover: execute controlled failover with measured results.
6. Full exercise: test the business process, technology, suppliers and communications together.

Record start time, detection time, decision time, restoration time, data recovery point, defects, manual actions and unexpected dependencies. Compare measured results with targets. A failed test is valuable evidence if findings are corrected and retested.

Rollback and failback deserve equal attention. Returning traffic to the primary environment can cause data divergence, duplicate processing or another outage. Define the authoritative data source, synchronisation process, validation checks and approval criteria before failback.

9. Illustrative Case: Migrating an Online Retail Platform

Background

A fictional retailer operates an online store in one data centre. Its web tier is virtualised, the order database is relational, payments use an external provider and nightly backups are copied to removable media. The business plans to migrate to a cloud platform and requires an RTO of four hours and an RPO of fifteen minutes for order processing.

Problem

The initial proposal is a rapid rehost of all servers. Assessment reveals that the payment integration uses fixed source addresses, the application stores sessions locally, backups have never been restored, and the warehouse system imports files once daily. A single database server and undocumented batch job are major risks.

Analysis

The team maps users, DNS, identity, payment services, order database, warehouse integration, email, monitoring and deployment tools. It classifies catalogue browsing as important but less critical than checkout and order fulfilment. It also identifies personal and payment-related data requiring access control, encryption and retention decisions.

Approach

The web tier is rehosted initially but redesigned to be stateless, with sessions stored in a managed data service. Instances run across multiple availability zones behind a load balancer. The database is replatformed to a managed relational service with multi-zone high availability and point-in-time recovery. Transaction logs are copied to a separate recovery location at intervals supporting the fifteen-minute RPO.

The warehouse interface is decoupled through a durable queue. If the warehouse is temporarily unavailable, orders remain queued rather than being lost. A pilot-light recovery environment is created in a second region. Infrastructure is defined as code, backups are encrypted and protected from ordinary production credentials, and restoration is tested monthly.

A staged migration uses replication and a controlled cutover. Orders are placed in a brief maintenance mode during final synchronisation, checksums and record counts are compared, and the old platform remains available for rollback until reconciliation and business approval are complete.

Outcome

Testing records restoration in ninety minutes and recovery of data to a point eight minutes before simulated failure, meeting the stated targets in the test conditions. A later exercise discovers that the payment provider’s allow-list was absent from the recovery runbook. The issue is corrected before production reliance on the plan.

Learning Points

The case demonstrates that migration strategy must be selected per component; dependency discovery is essential; HA does not replace backup; queues can protect business transactions from temporary dependency failure; and measured exercises reveal omissions that architecture diagrams do not.

10. Practical Design and Operating Checklist

Before migration, confirm ownership, data classification, dependency mapping, target architecture, rollback, security approvals, cost estimates and success criteria. During migration, monitor performance, errors, data reconciliation, security events and customer impact. After migration, remove obsolete access, update diagrams and runbooks, validate backup restoration, review costs and conduct a post-implementation review.

For resilience, remove single points of failure where justified, distribute components across failure domains, control retry storms, protect management access, use independent monitoring and ensure that recovery credentials remain available during a production-account compromise.

Challenges and Limitations

No architecture eliminates all risk. Multi-region designs increase cost, operational complexity, data-consistency challenges and compliance questions. Replication may preserve corruption; immutable backups may still be unusable if encryption keys are lost; automated failover may activate incorrectly; and cloud control-plane or provider dependencies may affect several services at once. RTO and RPO are targets under defined conditions, not universal promises.

Cost optimisation must therefore be risk-based. A low-cost backup-only design may be appropriate for a non-critical workload but unacceptable for a safety-critical or high-revenue service. Conversely, active-active deployment may create more operational risk than it removes if the organisation cannot test and operate it competently.

Contemporary Developments

Managed databases, serverless platforms, policy-as-code, cross-region object replication and automated resilience testing reduce some operational effort. Observability platforms increasingly correlate traces, logs and metrics to identify dependency failures. AI-assisted operations can summarise incidents or suggest likely causes, but recommendations require human verification, controlled permissions and auditability. Generative systems should not be granted unrestricted authority to change failover or deletion policies.

Chapter Summary

Cloud migration is a business, data and operational transformation rather than a server-copying exercise. Workloads should be assessed for criticality, technical condition, dependencies, data characteristics and organisational readiness. The seven migration strategies provide a vocabulary for selecting an appropriate treatment for each component.

Resilient architectures distribute components across failure domains, reduce coupling, use controlled retries and provide graceful degradation. HA, backup, disaster recovery and business continuity solve related but different problems. RTO defines acceptable restoration time, while RPO defines acceptable data currency. Backup and replication must be protected, independently accessible and regularly restored in tests.

Effective recovery plans include people, communications, governance, security and business procedures. Tabletop exercises, technical failover and full continuity tests convert assumptions into evidence. Results should be measured against targets, documented and used to improve both technology and operating practice.

Key Terms

Migration strategy: A selected approach for changing, replacing or retaining a workload.

Rehost: Moving a workload with minimal modification.

Replatform: Moving a workload while making limited platform optimisations.

Refactor: Redesigning an application to improve architectural or business characteristics.

Dependency: A component, service, person or supplier required for operation.

Critical path: The dependencies that must succeed for a transaction or service to complete.

Resilience: The ability to withstand, recover from and adapt to disruption.

High availability: Continued service access despite defined component failures.

Failure domain: A boundary within which a common failure may occur.

Active-active: Multiple environments serve production traffic concurrently.

Active-passive: A primary environment serves traffic while a standby takes over after failure.

RTO: Target maximum time to restore an acceptable service level.

RPO: Target maximum age of recoverable data after disruption.

Backup: A recoverable copy of data or configuration.

Replication: Maintaining additional copies of data or service state.

Disaster recovery: Processes and technology for restoring services after major disruption.

Business continuity: The broader capability to continue important business processes during disruption.

Failover: Switching service operation to an alternate component or environment.

Failback: Returning operation to the preferred environment after recovery.

Immutable backup: A backup protected against alteration or deletion for a defined period.

Review Questions

Short Answer Questions

1. What is the difference between rehosting and refactoring?
2. Why is dependency mapping important before migration?
3. Define RTO and RPO.
4. How does a backup differ from replication?
5. Why must recovery procedures be tested?

Long Answer Questions

1. Explain the seven migration strategies and discuss factors that influence selection.
2. Describe how a multi-zone cloud architecture can improve availability, including its limitations.
3. Explain the relationship between high availability, disaster recovery and business continuity.
4. Design a backup and recovery approach for a business-critical relational database.
5. Discuss governance, security and compliance considerations in a multi-region recovery design.

Analytical / Application Questions

1. A payment application has an RTO of one hour and an RPO of five minutes. Propose an architecture and justify its replication, backup and testing choices.
2. During a failover exercise, the application recovers in forty minutes but loses twenty minutes of transactions. Diagnose which objective failed and propose corrective actions.
3. A company proposes active-active multi-region deployment for a low-revenue internal reporting system. Evaluate whether the proposal is justified and recommend an alternative if appropriate.

Multiple Choice Questions with Answers

Question 1

Which migration strategy moves a workload with minimal application modification?

A. Refactor

B. Rehost

C. Repurchase

D. Retire

Correct Answer: B. Rehost

Question 2

What does RPO primarily specify?

A. Maximum acceptable service restoration time

B. Maximum acceptable data loss measured in time

C. Required number of availability zones

D. Maximum monthly infrastructure cost

Correct Answer: B. Maximum acceptable data loss measured in time

Question 3

Which design most directly reduces the impact of a single virtual-machine failure?

A. Running one larger virtual machine

B. Using multiple instances across failure domains

C. Disabling health checks

D. Storing credentials in application code

Correct Answer: B. Using multiple instances across failure domains

Question 4

Why can replication fail to protect against accidental deletion?

A. Replication never copies data

B. The deletion may be propagated to replicas

C. Replicas cannot be encrypted

D. Replication only works for static files

Correct Answer: B. The deletion may be propagated to replicas

Question 5

A service has an RTO of two hours. An outage begins at 09:00. By what target time should acceptable service be restored?

A. 09:15

B. 10:00

C. 11:00

D. 12:00

Correct Answer: C. 11:00

Question 6

Which recovery pattern normally keeps a reduced-capacity environment running and scales it during recovery?

A. Backup and restore

B. Pilot light

C. Warm standby

D. Retire and replace

Correct Answer: C. Warm standby

Question 7

Which practice best validates that backups are usable?

A. Checking only that backup jobs report success

B. Increasing backup retention without restoration

C. Performing isolated restoration tests and validating integrity

D. Deleting older backups immediately

Correct Answer: C. Performing isolated restoration tests and validating integrity

Question 8

What is a major purpose of a queue between an order service and a warehouse service?

A. To eliminate the need for data validation

B. To absorb temporary downstream unavailability

C. To guarantee zero cost

D. To make all operations synchronous

Correct Answer: B. To absorb temporary downstream unavailability

Question 9

Which statement best distinguishes business continuity from disaster recovery?

A. Business continuity includes broader business processes and people; disaster recovery focuses on restoring technology and data

B. Business continuity applies only to databases

C. Disaster recovery never includes procedures

D. They are always identical terms

Correct Answer: A. Business continuity includes broader business processes and people; disaster recovery focuses on restoring technology and data

Question 10

Which action is most appropriate after a recovery test misses its RPO?

A. Ignore the result because the service recovered

B. Delete the recovery plan

C. Investigate data-protection gaps, improve controls and retest

D. Disable monitoring during future tests

Correct Answer: C. Investigate data-protection gaps, improve controls and retest