Architecture Design and Migration

Introduction

Cloud architecture is the disciplined design of computing capabilities, data flows, security controls, operational processes, and service relationships delivered through cloud platforms. Migration is the controlled movement of applications, data, and operating responsibilities from an existing environment to a cloud environment. These activities are closely related: a migration without a target architecture may reproduce existing weaknesses, while an architecture without a migration plan may remain only a diagram.

A sound cloud design begins with business and technical requirements, not with a preferred product. The architect must understand the workload, identify constraints, compare service choices, document trade-offs, and select an appropriate migration strategy. At certificate level, the central professional skill is not designing every detail of a large enterprise platform, but being able to reason systematically about common workloads and communicate a defensible design.

Cloud architecture commonly addresses six concerns:

1. Business fit: Does the design support organizational goals and users?
2. Reliability: Can the system continue operating when components fail?
3. Security: Are identities, data, networks, and operations appropriately protected?
4. Performance: Does the system respond within acceptable time and capacity limits?
5. Cost: Is the expected value justified by consumption and operational costs?
6. Operational excellence: Can the system be monitored, changed, recovered, and governed?

Learning Objectives

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

• gather and classify business, functional, non-functional, and compliance requirements;
• assess workload characteristics, dependencies, risks, and readiness for migration;
• distinguish infrastructure, platform, and software service models;
• choose cloud services using explicit evaluation criteria;
• create and interpret a basic cloud architecture diagram;
• explain common architecture trade-offs;
• distinguish rehost, replatform, refactor, retain, retire, and replace;
• propose a phased migration approach and suitable validation controls;
• recognize security, governance, ethical, and regulatory responsibilities in migration projects.

1. Requirements: The Foundation of Architecture

1.1 Business requirements

Business requirements state the outcomes expected by stakeholders. Examples include reducing the time required to launch a customer portal, improving disaster recovery, enabling seasonal scaling, or meeting a contractual data-residency obligation. A requirement should be specific enough to guide a decision. “Improve performance” is weak; “support 10,000 simultaneous users with a 95th-percentile response time below two seconds during the examination period” is more useful.

Requirements normally come from business owners, users, operations teams, security specialists, legal advisers, and finance staff. Interviews, workshops, document reviews, observation, application logs, and service-level agreements are useful evidence sources. Conflicting requirements should be recorded rather than silently resolved. For example, maximum security, minimum cost, and unrestricted global access cannot always be achieved simultaneously.

1.2 Functional and non-functional requirements

A functional requirement describes what a system does: accept an order, authenticate a user, produce an invoice, or export a report. A non-functional requirement describes a quality, constraint, or operating condition: availability, latency, recoverability, privacy, auditability, scalability, or maintainability.

A practical requirements register may use the following fields:

Important non-functional measures include:

• Availability: the proportion of agreed time that a service is usable. A monthly target of 99.9% permits approximately 43.2 minutes of unavailability in a 30-day month, assuming the target is measured continuously and no exclusions apply.
• Recovery point objective (RPO): the maximum acceptable amount of data loss measured in time. An RPO of one hour means that, after a severe failure, the organization may accept losing up to one hour of transactions.
• Recovery time objective (RTO): the maximum acceptable time to restore the service after a disruptive event.
• Latency: elapsed time between a request and a response. Percentiles, such as p95, are often more informative than an average because a small group of very slow requests can affect users significantly.
• Throughput: completed work per unit of time, such as transactions per second.
• Capacity: the workload volume a system can support while meeting its requirements.

Availability percentages should not be treated as guarantees that every request succeeds. They are service-level measures and must be interpreted with their measurement period, exclusions, dependencies, and support conditions.

1.3 Constraints, assumptions, and acceptance criteria

A constraint limits the design. Examples include an existing licensing agreement, a specialist operating system, a fixed migration deadline, a skills shortage, or a prohibition on transferring particular records across borders. An assumption is a statement treated as true for planning purposes, such as “the vendor will provide a compatible database driver.” Assumptions must be validated because an incorrect assumption can invalidate an architecture.

Acceptance criteria convert requirements into tests. For example, “the migrated application is successful” is vague. Better criteria might include successful authentication, correct calculation of invoices, restoration from backup within the agreed RTO, and completion of a security review with no unresolved critical findings.

2. Workload Assessment

A workload is a business capability and the technology components that deliver it. Assessment should cover the application, data, infrastructure, people, processes, and external dependencies.

2.1 Inventory and dependency mapping

Begin with an inventory containing applications, owners, environments, databases, interfaces, servers, operating systems, storage, network connections, certificates, scheduled jobs, licenses, and support contacts. Then map dependencies. An order system may depend on identity services, a payment gateway, a product database, a message queue, a reporting system, and a warehouse interface.

Dependency mapping prevents a common migration failure: moving one component while leaving an essential dependency behind without adequate connectivity or performance. Application discovery tools can assist, but interviews and log analysis remain important because undocumented processes and manual workarounds are common.

2.2 Workload characteristics

Assess each workload using questions such as:

• Is demand steady, seasonal, bursty, or unpredictable?
• Is the workload compute-intensive, memory-intensive, storage-intensive, or network-intensive?
• Is it stateful or largely stateless?
• Does it require a relational database, document store, file system, or object storage?
• What are its consistency, transaction, and ordering requirements?
• Does it run continuously, periodically, or only when triggered?
• Can it tolerate interruption or delayed processing?
• Is its software supported on a cloud-compatible operating system?
• Does it contain personal, confidential, regulated, or sensitive data?

A workload with variable demand may benefit from elastic services. A stable workload may be cheaper or simpler on reserved capacity, although actual pricing must be evaluated using current provider terms. A highly stateful legacy system may require more analysis than a stateless web tier because data consistency and session handling complicate movement.

2.3 Readiness and risk scoring

A simple qualitative score can support prioritization. For example, rate technical complexity, business criticality, compliance sensitivity, dependency uncertainty, and change effort as low, medium, or high. This is not a scientific probability model; it is a transparent decision aid. Scores should be accompanied by evidence and reviewed by responsible stakeholders.

A pilot candidate is often a workload with moderate business impact, well-understood dependencies, and measurable success criteria. The first migration should not usually be the organization’s most critical and least understood system.

3. Cloud Service Models and Service Selection

3.1 Service models

Infrastructure as a Service (IaaS) provides virtual machines, networks, and storage. The customer generally manages the operating system and more of the software stack. IaaS offers control and compatibility but creates greater patching and operational responsibility.

Platform as a Service (PaaS) provides a managed runtime, database, messaging system, or application platform. The provider manages more underlying infrastructure. PaaS can improve developer productivity and reduce maintenance, but it may impose platform constraints and create portability considerations.

Software as a Service (SaaS) provides a complete application managed largely by the provider. The customer configures users, data, policies, and integration. SaaS can reduce infrastructure work, but customization, data export, identity integration, and contractual terms require careful review.

These categories are conceptual rather than perfectly separate. A managed database may be PaaS-like while offering several levels of customer control.

3.2 Selecting a service

Service selection should follow requirements and workload analysis. Useful criteria include:

A decision matrix can make assumptions visible. Assign weights to criteria, rate candidate services consistently, and document why a high score is credible. Numerical scoring does not remove judgment; it makes judgment reviewable.

4. Basic Architecture Design

4.1 Architectural layers

A basic application architecture can be described in layers:

1. Users and clients: browsers, mobile applications, partner systems, or administrators.
2. Edge and access: DNS, content delivery, web application firewall, and load balancing.
3. Application: web servers, APIs, containers, serverless functions, or business services.
4. Data: relational databases, caches, queues, object storage, and search services.
5. Operations and governance: identity, monitoring, logging, backup, configuration, policy, and cost management.

The layers are conceptual. A provider may implement several of them through one managed service, and a real system may contain multiple instances of each layer.

Figure: A conceptual cloud application architecture with cross-cutting operational and governance controls.

A diagram should show boundaries, trust relationships, data flows, dependencies, and control points. It should not imply that a box is automatically secure or highly available. The accompanying design description should identify which party manages each component, how traffic is authenticated, where data is encrypted, and how failure is handled.

4.2 Security by design

Security is a property of the complete system, not a single security product. Basic controls include least-privilege identity, multifactor authentication for privileged users, separation of duties, private network paths where appropriate, encryption in transit and at rest, secrets management, vulnerability management, centralized logs, and tested backups.

The shared responsibility model must be made explicit. The provider secures the cloud infrastructure to the extent defined by its service model; the customer remains responsible for suitable configuration, identities, data, access policies, and compliance. Responsibility varies between IaaS, PaaS, and SaaS and should be confirmed in provider documentation and contracts.

4.3 Resilience and failure design

A resilient architecture anticipates failure of instances, zones, networks, credentials, software releases, and human procedures. Techniques include redundancy, health checks, automated replacement, graceful degradation, queues, retries with limits, idempotent operations, backups, and tested restoration. Replication is not equivalent to backup: replicated corruption or accidental deletion may be copied to another location. Recovery procedures must therefore be exercised.

5. Architecture Trade-offs

Architecture is a process of choosing among imperfect alternatives. Common trade-offs include:

• Cost versus resilience: additional replicas and independent failure domains usually increase cost, though the appropriate level depends on business impact.
• Control versus operational simplicity: IaaS may support unusual software, while managed services reduce routine administration.
• Performance versus portability: provider-specific features may improve performance but make future migration more difficult.
• Consistency versus availability and latency: distributed systems may require design choices about stale reads, synchronization, and behavior during network partitions.
• Speed versus governance: rapid delivery is valuable, but unreviewed changes can create security, compliance, and operational risk.
• Centralization versus autonomy: shared platforms improve standardization, whereas team autonomy may accelerate delivery.

Trade-offs should be recorded in architecture decision records. Each record states the context, alternatives considered, decision, consequences, and conditions that would trigger review. This creates institutional memory and prevents later teams from mistaking a contextual decision for a universal rule.

6. Migration Strategies: The Six Rs

The six Rs describe common disposition choices. They are not mutually exclusive across an organization; different components of one portfolio may follow different paths.

6.1 Rehost

Rehosting, often called “lift and shift,” moves servers or application packages with minimal modification. It can reduce data-centre dependency and provide a rapid first step. However, it may preserve inefficient licensing, manual deployment, poor scaling, and operating-system vulnerabilities. Rehosting is not automatically cheap after migration; cloud consumption must be measured and optimized.

6.2 Replatform

Replatforming makes bounded changes, such as moving a self-managed database to a managed database service, changing a virtual machine deployment to a managed container platform, or using a managed queue. It can reduce patching and improve operations while avoiding a full rewrite. Compatibility, performance, backup semantics, and operational skills must still be tested.

6.3 Refactor

Refactoring changes the application architecture, perhaps decomposing a monolith, introducing APIs and asynchronous messaging, making services stateless, or redesigning data storage. It can improve elasticity and release speed but introduces substantial design and testing work. Refactoring should be justified by measurable business value rather than by the belief that cloud-native is always superior.

6.4 Retain, retire, and replace

Retaining is a valid decision when a workload is stable, regulated, tightly coupled, or scheduled for later replacement. Retiring removes unnecessary cost and risk, but teams must verify ownership, retention obligations, hidden users, and interfaces. Replacing an application with SaaS can provide rapid capability, yet the organization must examine data export, integration, identity, service levels, configuration limits, accessibility, and exit arrangements.

7. A Controlled Migration Lifecycle

A practical migration lifecycle contains the following stages:

1. Discover: inventory assets, owners, dependencies, data, contracts, and current performance.
2. Assess: classify criticality, readiness, risk, compliance, and likely migration strategy.
3. Design: define the target architecture, security controls, operating model, and acceptance criteria.
4. Plan: sequence workloads, prepare landing zones, establish connectivity, train staff, and define rollback.
5. Pilot: migrate a representative but manageable workload and collect evidence.
6. Migrate: execute waves with rehearsed procedures, communication, validation, and change control.
7. Operate and optimize: monitor reliability, security, performance, and cost; remove obsolete resources.

A landing zone is a prepared cloud foundation containing accounts or subscriptions, identity integration, network structure, logging, security policies, budgets, and baseline controls. Building it before large-scale migration reduces inconsistent configuration.

Migration methods vary by data and downtime requirements. A batch transfer may suit static data. Replication followed by a controlled cutover may reduce downtime for an active database. A dual-running period can increase confidence but also increases cost and complexity. Rollback must be technically feasible and time-bounded; simply keeping the old system powered on is not a complete rollback plan.

Validation should include functional tests, data reconciliation, security tests, performance tests, backup restoration, monitoring checks, user acceptance, and operational handover. After cutover, teams should observe error rates, latency, capacity, costs, and user feedback before decommissioning the source environment.

8. Worked Application: Illustrative University Enrolment Portal

Background

This illustrative case concerns a university enrolment portal used heavily during a two-week registration period. The existing system runs on three virtual machines in a local data centre, uses a relational database, sends email through an external service, and exchanges student status with a legacy records system. Demand is low for most of the year but rises sharply during registration. The university reports slow response times and has limited disaster-recovery capability.

Problem and requirements

The portal must protect student personal data, support 8,000 concurrent users during peak registration, maintain accurate enrolment transactions, and recover within four hours after a major infrastructure failure. The university requires an RPO of 30 minutes, centralized audit logging, multifactor authentication for administrators, and a controlled migration during a vacation period.

Analysis

The web tier is relatively stateless and has variable demand, making load balancing and elastic application capacity attractive. The relational database contains transactional records and cannot simply be replaced by an eventually consistent store without changing business behavior. The legacy records system is a major dependency and may require private connectivity or a controlled integration interface. Data classification identifies student records as sensitive, requiring restricted access, encryption, retention controls, and auditability.

Approach and solution

The university chooses a phased approach:

• Replatform the web servers onto a managed application platform with automated health checks and scaling.
• Replatform the database to a managed relational service with automated backups and a tested point-in-time recovery process.
• Retain the legacy records system initially while establishing secure connectivity and monitoring the interface.
• Use a web application firewall, centralized identity, administrator multifactor authentication, private database access, encryption, and centralized logs.
• Introduce a queue for non-critical email notifications so that temporary email-provider delays do not block enrolment transactions.
• Perform a pilot with staff users, then conduct a peak-load test and a recovery exercise.

The design does not immediately refactor the whole application because the registration deadline and data integrity requirements make a large rewrite risky. After stabilization, selected functions may be refactored where evidence shows a benefit.

Outcome

The migration is accepted only after transaction totals and sample student records reconcile, the measured response time meets the agreed target under a representative load, and restoration meets the RTO and RPO objectives. The old environment is retained temporarily for rollback, then decommissioned after the agreed observation period and records review.

Learning points

The case demonstrates that migration strategy should be selected per workload component. It also shows why requirements, dependencies, testing, security controls, and operations are as important as the choice of cloud product. A managed service reduces some administration but does not remove the university’s responsibility for correct configuration, data governance, access control, and recovery testing.

9. Governance, Ethics, and Contemporary Practice

Migration can expose personal data, alter employment responsibilities, and affect access to essential services. Ethical practice requires data minimization, legitimate use, transparency, accessibility, and protection against inappropriate surveillance or discriminatory automation. Personal data should not be copied into test environments without appropriate masking or authorization.

Governance should address data residency, retention and deletion, incident reporting, audit evidence, subcontractors, business continuity, procurement, licensing, and exit planning. Contracts should clarify service levels, breach notification, data ownership, portability, and responsibilities after termination. Regulatory requirements vary by jurisdiction and sector; architects should involve qualified legal and compliance professionals rather than treating a generic cloud checklist as legal advice.

Automation and AI can assist discovery, dependency classification, log analysis, infrastructure generation, and anomaly detection. However, generated architecture or code requires human review. AI tools may expose confidential architecture or personal data through prompts, and automated recommendations may reflect incomplete inventories or biased cost assumptions. Approval, testing, access control, and audit trails remain necessary.

Current practice increasingly emphasizes platform engineering, infrastructure as code, policy as code, observability, zero-trust principles, confidential computing, sustainability measurement, and FinOps. These are not substitutes for fundamentals. A well-governed inventory, clear ownership, tested recovery, and accurate requirements remain essential regardless of technology trends.

10. Best Practices and Common Failure Modes

Effective practice includes:

• start with measurable outcomes and workload evidence;
• maintain an authoritative inventory and dependency map;
• separate must-have requirements from preferences;
• design identity, logging, backup, and monitoring before migration waves;
• use small pilots and progressive waves;
• automate repeatable provisioning and configuration;
• test performance, security, data integrity, and recovery;
• record decisions, assumptions, risks, and owners;
• measure actual cloud consumption after migration;
• define decommissioning and exit criteria.

Common failures include treating cloud as merely a new data centre, choosing services before gathering requirements, ignoring licensing and data transfer charges, migrating undocumented dependencies, assuming replication equals backup, accepting default permissions, and decommissioning the source before validation. Another failure is selecting refactoring because it sounds modern when replatforming would meet the business need with lower risk.

Chapter Summary

Cloud architecture and migration begin with business outcomes and measurable requirements. Architects classify functional and non-functional needs, identify constraints and assumptions, assess workload characteristics and dependencies, and select services using criteria such as security, reliability, performance, cost, operations, portability, compliance, and skills. Basic architectures commonly include users, edge access, application services, data services, and cross-cutting governance and operations.

Every design involves trade-offs among cost, control, resilience, portability, performance, speed, and governance. The six migration strategies are rehost, replatform, refactor, retain, retire, and replace. A controlled lifecycle moves from discovery and assessment through design, planning, pilot, migration, validation, operation, and optimization. Security, privacy, recovery, auditability, contracts, ethical data use, and human oversight must be designed into the process rather than added at the end.

Key Terms

Requirement: A needed capability, quality, or constraint that guides design.

Functional requirement: A description of what a system must do.

Non-functional requirement: A quality or operating constraint such as security, latency, or availability.

Workload: A business capability and the technology components that deliver it.

Dependency: A service, system, data source, or process required by a workload.

RPO: Recovery point objective; the maximum acceptable amount of data loss measured in time.

RTO: Recovery time objective; the maximum acceptable time to restore service.

IaaS: Infrastructure as a Service, providing configurable compute, network, and storage resources.

PaaS: Platform as a Service, providing managed application or infrastructure capabilities.

SaaS: Software as a Service, providing a complete provider-managed application.

Landing zone: A governed cloud foundation prepared for workloads.

Rehost: Migrating with minimal application modification.

Replatform: Making limited changes to use managed or improved platform capabilities.

Refactor: Substantially redesigning or rewriting an application.

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

Retire: Decommissioning a workload that is unnecessary or obsolete.

Replace: Substituting an existing capability with another product or service.

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

Architecture decision record: A documented decision, its context, alternatives, and consequences.

Observability: The ability to understand system behavior through metrics, logs, traces, and related evidence.

Review Questions

Short Answer Questions

1. Distinguish a functional requirement from a non-functional requirement and give one example of each.
2. What do RPO and RTO measure?
3. State two differences between IaaS and PaaS.
4. Why is dependency mapping important before migration?
5. Define replatforming and identify one possible benefit.

Long Answer Questions

1. Explain a structured process for gathering and validating cloud architecture requirements.
2. Discuss the criteria an architect should use when selecting between cloud services.
3. Explain the six Rs of migration and the circumstances in which each may be appropriate.
4. Describe the major layers and cross-cutting controls in a basic cloud application architecture.
5. Explain how security, governance, backup, and recovery should be incorporated into a migration lifecycle.

Analytical / Application Questions

1. A stable internal reporting application has low usage, a proprietary operating system, and no immediate modernization budget. Recommend a migration disposition and justify it using technical and business evidence.
2. An online ticketing service experiences extreme demand for two hours each year, stores transactions in a relational database, and cannot lose more than five minutes of data. Propose a high-level architecture and migration approach, including key tests.
3. A team proposes refactoring a critical legacy application into many microservices solely because the organization is moving to the cloud. Evaluate this proposal and recommend the information and trade-offs that should be examined first.

Multiple Choice Questions with Answers

Question 1

Which item is a non-functional requirement?

A. The system generates an invoice

B. The system supports administrator multifactor authentication

C. The system allows a customer to submit an order

D. The system exports a monthly report

Correct Answer: B. The system supports administrator multifactor authentication

Question 2

What does an RPO of 30 minutes indicate?

A. The service must be restored within 30 minutes

B. The system must respond within 30 minutes

C. The organization accepts losing no more than approximately 30 minutes of data

D. The system must remain available for 30 minutes after failure

Correct Answer: C. The organization accepts losing no more than approximately 30 minutes of data

Question 3

Which strategy makes the fewest application changes during migration?

A. Rehost

B. Refactor

C. Replace

D. Retire

Correct Answer: A. Rehost

Question 4

Which service model generally gives the customer the least responsibility for maintaining the application software?

A. IaaS

B. PaaS

C. SaaS

D. Colocation

Correct Answer: C. SaaS

Question 5

Why is dependency mapping performed before migration?

A. To eliminate the need for testing

B. To identify systems and services required by the workload

C. To guarantee that the workload will be cheaper in the cloud

D. To replace all legacy applications automatically

Correct Answer: B. To identify systems and services required by the workload

Question 6

Which statement about replication and backup is correct?

A. Replication always prevents accidental deletion

B. Replication and backup have exactly the same purpose

C. Replicated corruption may be copied, so independent recovery protection may still be needed

D. A backup cannot support recovery after data loss

Correct Answer: C. Replicated corruption may be copied, so independent recovery protection may still be needed

Question 7

A workload is unused, has no retention obligation, and duplicates another system. Which disposition is most appropriate?

A. Retain

B. Retire

C. Rehost

D. Refactor

Correct Answer: B. Retire

Question 8

Which control is most directly associated with limiting administrator privileges?

A. Least privilege

B. Content delivery caching

C. Data compression

D. Load balancing

Correct Answer: A. Least privilege

Question 9

What is a landing zone?

A. A temporary user interface for migration staff

B. A prepared and governed cloud foundation for workloads

C. A database backup stored on a laptop

D. A replacement for application testing

Correct Answer: B. A prepared and governed cloud foundation for workloads

Question 10

Why should a migration pilot usually avoid being the organization’s most critical and least understood workload?

A. Critical workloads never require migration

B. A pilot should provide learning with manageable business and technical risk

C. Critical workloads cannot use cloud services

D. The first workload must always be a SaaS application

Correct Answer: B. A pilot should provide learning with manageable business and technical risk