Flashcards

The planned, managed process of moving digital assets — applications, data/databases, virtual machines, and workloads — from one computing environment (the source) to another (the target) while keeping them working. It's a project, not a single copy.

Any five of: cost reduction, scalability/elasticity, agility/speed, innovation and managed services, security and compliance, aging/end-of-life hardware, data-center exit or lease expiry, mergers and acquisitions, disaster recovery, sustainability, and the talent shortage for old systems.

Downtime, cost overruns, a skills gap on the team, data loss, vendor lock-in (hard to leave a provider), and overall complexity.

Hybrid cloud combines private/on-premises infrastructure WITH public cloud as one connected system. Multi-cloud means using two or more PUBLIC cloud providers at once. They solve different problems and are often used together.

Moving applications, data, or workloads BACK from public cloud to private cloud or on-premises — usually for cost, performance, data-control, or compliance reasons. It's a deliberate, growing trend, not a sign of failure.

Applications (the programs people use), data and databases (records and files), virtual machines/VMs (a whole computer packaged as a software file), and workloads (a unit of work like a website or batch job).

Retire, Retain, Rehost, Relocate, Repurchase, Replatform, and Refactor (also called Re-architect).

Gartner published the original 5 Rs in 2011; Stephen Orban of AWS reframed them into the 6 Rs in 2016; AWS later added Relocate, giving the modern 7 Rs.

Rehost — you move an application to the cloud as-is, making no changes to it. Fast and low-risk, but you gain few cloud benefits.

Replatform — you move the app but make a few small optimizations along the way (e.g., swapping a self-managed database for a managed one like Amazon RDS).

Repurchase — you retire your existing application and replace it with a ready-made product, usually a SaaS subscription (e.g., moving to Salesforce or Workday).

Refactor / Re-architect. AWS recommends NOT refactoring during a large migration — rehost or replatform first, then modernize after you're in the cloud.

Assess, Mobilize, and Migrate & Modernize. Many teams add a fourth idea, Operate & Optimize, for ongoing tuning after the move.

Business, People, Governance, Platform, Security, and Operations. They help you judge how ready your whole organization is, not just the technology.

Strategy, Plan, Ready, Adopt (Migrate & Innovate), then the operational trio Govern, Secure, and Manage.

Assess, Plan, Deploy, and Optimize.

A pre-configured, secure, well-governed cloud foundation (accounts, identity, networking, security guardrails) that you build BEFORE migrating any workloads into it — like setting up the new apartment before moving day.

Grouping applications into batches ('waves') and migrating one batch at a time, based on dependencies and risk, instead of moving everything in one risky night.

Migration changes WHERE an application runs (e.g., data center to cloud) with little or no change to the app itself. Modernization changes HOW the application is built and operated so it becomes more cloud-native — more agile, scalable, resilient, and cost-efficient.

Pure migration (little/no change): Rehost (lift-and-shift) and Relocate (hypervisor/container-level move). Light modernization: Replatform. Deep modernization: Refactor/Re-architect. Replace-with-SaaS: Repurchase. Retire and Retain are portfolio decisions, not moves.

No. Modernization can happen DURING migration (change the app as you move it) OR AFTER migration. A common pattern is 'move first, then improve': rehost quickly to escape a failing data center, then refactor to cloud-native once you're safely in the cloud.

Containerization (Docker) packages an app plus its dependencies into a lightweight, portable container that runs consistently anywhere. Orchestration (Kubernetes) manages many containers at scale — scheduling, scaling, healing, and networking them across a cluster of machines. Docker makes one box; Kubernetes runs thousands of them.

A monolith is a single application where all logic runs as one deployable unit/process. Microservices split that into small, independently deployable services that each own one capability and communicate over the network (often APIs or events).

An execution model where the cloud provider runs your code on demand in response to events, automatically provisioning and scaling the compute, and you pay only for actual execution time. Examples: AWS Lambda (launched 2014), Azure Functions, Google Cloud Functions. 'Serverless' means no servers for YOU to manage — servers still exist.

An incremental modernization pattern (named by Martin Fowler after the strangler fig vine he saw in Australia) where you build new functionality around a legacy system and gradually redirect features to it — routing calls through a facade — until the old system can be safely retired. It avoids the risky 'big rewrite.'

It is a translation/adapter layer placed between a new system and a legacy one. It converts requests and data between the two models so the legacy system's outdated semantics don't 'corrupt' or leak into the clean new design. Comes from Domain-Driven Design and is documented in Azure's Architecture Center.

You insert an abstraction layer between callers and the code you want to change, build the new implementation behind that abstraction (old and new can coexist), switch callers over, then remove the old code. It lets you make a large change gradually while still releasing regularly — no long-lived branch.

Parallel Run calls BOTH old and new implementations on the same input and compares the results to verify equivalence; only one (usually the old one) is the source of truth. A Canary instead sends a small subset of real users to the new version. Parallel Run verifies correctness; Canary limits blast radius.

CDC reads a database's change log and streams row-level inserts/updates/deletes to a target in near real time. Dual-write means the application code writes each change to both the old and new store. Replication uses the database engine to keep a synchronized copy. All three keep source and target in sync during migration.

Big Bang moves everything and cuts over in one event — fast and simple but high-risk with a hard rollback. Phased/Incremental moves in smaller slices over time — lower risk and easier rollback, but the migration runs longer and old and new must coexist.

Homogeneous keeps the same database engine (e.g., MySQL→MySQL); heterogeneous changes engines (e.g., Oracle→PostgreSQL) and requires schema conversion of tables, data types, and code. Heterogeneous is more complex and harder to automate fully.

CDC reads a database's transaction log to capture every change after an initial bulk load and continuously applies it to the target, keeping source and target in sync. It enables near-zero-downtime cutovers for live systems.

Coined by engineer Dave McCrory in 2010, it describes how large datasets pull applications, services, and more data toward them — and the bigger the pile, the harder it is to move. It's a key reason data is the hardest thing to migrate.

Egress fees are per-gigabyte charges for moving data OUT of a cloud (to the internet or another provider). Inbound is usually free, so it's cheap to move in but costly to move out — a core driver of lock-in.

Choose offline (ship a physical device like an AWS Snowball Edge) when the dataset is very large or bandwidth is poor, so online transfer would take weeks or months. Online is better for smaller data, good bandwidth, or continuous syncing.

Validate and reconcile: prove the data is complete and correct by comparing row counts, checksums/hashes, referential integrity, and sample records between source and target before trusting or cutting over.

A tempting approach that looks like a good solution but reliably backfires — a predictable trap (Gizmo's specialty), the opposite of a best practice.

Everything can fail at once, there's no learning between steps, and rollback is nearly impossible because too much changed simultaneously. Fix: phased waves with parallel run.

Sorting each app into keep/retire/replace/rework before the move. It stops you paying cloud rent to store and secure junk (zombie and idle apps).

Rehosting apps unchanged (fine as a first step) but never optimizing them, so old inefficiencies are now billed by the hour. Fix: plan modernization after the move.

Services split into pieces that are still so coupled they must deploy together — you pay distributed-system complexity but get no independent deployment or scaling.

Start with a well-structured monolith and split into microservices only after real, stable boundaries emerge; systems built as microservices from scratch often end up in serious trouble.

To inventory every application and server, map their dependencies, and decide each one's fate using the 7 Rs (e.g., Retire, Retain, Rehost, Replatform, Refactor) instead of blindly moving everything. Retire reminds us that the cheapest thing to migrate is something you throw away first.

TCO adds up the full cost of running a workload — hardware, software licenses, power, cooling, staff, and cloud fees — so you can fairly compare running it at Fort Rusty (on-prem) versus Cloudville (cloud) and build an honest business case.

A pilot is a small, low-risk app you migrate first to learn safely; waves are small batches of related workloads moved in short iterations. This limits blast radius, builds skills, and lets you improve each round. Doing the whole estate in one risky night is exactly the anti-pattern Gizmo the Gremlin wants.

Operational excellence, security, reliability, performance efficiency, cost optimization, and sustainability. Sustainability was the sixth pillar added in 2021.

A pre-configured, well-architected, secure and scalable multi-account cloud environment — with identity, networking, logging, and governance guardrails already set up — that workloads 'land' in. Think of it as cleaning, wiring, and furnishing the new house before the moving trucks arrive.

RTO (Recovery Time Objective) is the maximum acceptable time to restore service after an outage — how long you can be down. RPO (Recovery Point Objective) is the maximum acceptable amount of data loss, measured in time — how much recent data you can afford to lose. Lower targets cost more.

On-demand for spiky or short-lived workloads (flexible, priciest). Reserved instances / savings plans / committed-use discounts for steady, predictable always-on workloads (1–3 year commitment, big discount). Spot/preemptible for fault-tolerant, interruptible jobs (cheapest, can be reclaimed anytime).

Backup & restore (restore from backups, RTO in hours), pilot light (minimal core kept warm), warm standby (scaled-down running copy), and multi-site/active-active (full capacity running everywhere, near-zero RTO/RPO). Lower RTO/RPO costs more — match the strategy to each workload's business criticality.

Object storage (S3/Blob/GCS) holds data as objects via HTTP APIs — scalable and cheap, great for files, backups, and data lakes. Block storage (EBS/managed disks) provides raw low-latency volumes for OS disks and databases attached to one server. File storage (EFS/Azure Files/Filestore) is a shared network file system many servers can mount at once.

A cross-functional team that sets cloud standards, security guardrails, and reusable patterns (like landing zones) and spreads best practices across the organization — the group that makes migrations consistent, governed, and repeatable rather than ad hoc.

They constrain WHERE data can live (data residency/sovereignty, e.g., GDPR), WHICH services and encryption you must use (e.g., HIPAA for health data, PCI DSS for card data), and can force some workloads to Retain on-prem or land only in specific compliant regions. SOC 2 is the audit report showing a provider meets security controls.

Bandwidth is how much data you can move per second (throughput) — it drives how long a bulk data transfer takes (and whether you need an offline appliance). Latency is the delay for a single request — it drives app responsiveness and is why apps should sit close to their data (data gravity).

Discovery & assessment. It inventories your servers, apps, and dependencies and estimates cost/readiness so you don't migrate junk or break hidden connections. Tools: AWS Application Discovery Service + Migration Evaluator, Azure Migrate, Google Cloud Migration Center, plus Device42 and Flexera.

It is the successor to CloudEndure Migration (AWS acquired CloudEndure in 2019). In June 2026 it was rebranded 'AWS Transform MGN.' It still does continuous replication and rehosting (lift-and-shift) of servers into EC2.

Homogeneous = same engine (Oracle→Oracle), moved by DMS alone. Heterogeneous = different engine (Oracle→PostgreSQL), which needs the AWS Schema Conversion Tool (or web-based DMS Schema Conversion) to translate the schema/code first, then DMS copies the data.

When the dataset is so large (tens of TB to petabytes) that a network copy would take many weeks, or when bandwidth is poor/metered/costly. Otherwise use online transfer (DataSync, Azure Storage Mover, Google Storage Transfer Service).

Azure = Azure Data Box; Google Cloud = Transfer Appliance; AWS = Snow Family (Snowball) — but AWS is retiring it (existing-customers-only since Nov 2025), steering new customers to DataSync, the AWS Data Transfer Terminal, or partners.

Defining cloud infrastructure as version-controlled, re-runnable text files instead of clicking a console. Terraform (multi-cloud; OpenTofu is its open-source cousin), AWS CloudFormation (AWS-only), and Azure Bicep (Azure-only).

A batch of related applications and their data moved to the cloud together and validated before the next batch begins — each wave has its own plan, cutover, and rollback.

A pilot: the smallest, least-connected, lowest-risk, non-critical app. Its job is to prove the landing zone, tools, and runbook while the stakes are near zero.

If you split them, their constant chatter has to cross the link between on-prem and cloud during the gap — adding latency and egress cost. Coupled apps move together.

The precise, step-by-step checklist for executing one wave’s cutover — every command, every check, every go/no-go decision, and the exact steps to reverse it.

Prepare & replicate → rehearse the cutover → cut over → validate against RTO/RPO → hypercare → roll back if it fails.

Each wave ends with a retro whose lessons roll into the tooling and runbooks — so later waves move faster and cheaper than the first. The move becomes a production line.

Assess, Mobilize, and Migrate & Modernize — with ongoing Operate & Optimize once workloads land.

AWS Application Migration Service (MGN) — the successor to CloudEndure Migration.

Azure Migrate — alongside Database Migration Service and Data Migration Assistant for databases, and Data Box for offline transfer.

Strategy, Plan, Ready (build the landing zone), Adopt (Migrate & Modernize) — then the continuous Govern and Manage.

Assess → Plan → Deploy → Optimize, with Migration Center as the discovery/assessment/TCO hub.

AWS Snowball (the Snow family), Azure Data Box, and Google Transfer Appliance — for when shipping a box beats the internet.