Architecture Patterns
Moving to the cloud is rarely one giant leap — it's a series of well-worn moves that thousands of teams have already figured out and written down. These repeatable moves are called patterns: named, reusable solutions to problems that keep showing up. On this page we'll meet the classics — replacing old systems piece by piece, switching over safely, keeping data in sync, and building the bridge between your old world and the new one.
Imagine moving house without a single day of chaos. Instead of dumping everything into one truck and hoping, you carry one room at a time, keep a working bathroom in BOTH houses until the new one is ready, and test the new kitchen before you cook the big dinner. Architecture patterns are those clever, been-there-done-that tricks for moving without breaking anything.
Why patterns at all?
☺ Like you’re 10: Other movers already learned the hard way. A pattern is their recipe card so you don't have to.
A pattern is a named, tested way to solve a recurring problem. Nobody has to reinvent it — you pick the pattern that fits your situation and follow the recipe. The patterns on this page apply whether you're moving from your own data center to the cloud or from one cloud to another (see cloud-to-cloud migration). They also pair closely with modernization and the choices you make in the 7 R's.
What makes something a "pattern"
Two things: it has a name, and it has a known shape. Because it has a name, a whole team can say "let's do a blue-green cutover" and everyone instantly pictures the same plan — no long explanation needed. Because it has a known shape, its strengths and traps are already documented, so you inherit other people's scar tissue instead of earning your own. The big cloud providers publish whole libraries of these: AWS in its Prescriptive Guidance, Microsoft in the Azure Architecture Center, and Google in its Cloud Architecture Center. Software thinker Martin Fowler is widely credited with describing several of them, including the Strangler Fig and blue-green deployment (he described and popularized them, though such ideas grew from the whole community — not one sole inventor).
The jobs these patterns do
It helps to sort the patterns by the job they perform. We'll group them into four jobs — replacing an old system gradually, verifying the new one is correct, keeping data in sync, and cutting over to the new system safely — and then cover the two supporting pieces every migration leans on: the bridge (hybrid connectivity, plus how you physically move the data) and the foundation (the landing zone). Real migrations almost never use just one; they stack several together, which is exactly what the summary at the end of the page shows.
A pattern isn't a rule you must obey — it's a starting recipe. The skill is picking the right one for the risk you're facing (how bad is downtime? how expensive is a wrong answer? how big is the data?) and then combining a few of them into a plan.
Incremental replacement: swap it out one piece at a time
☺ Like you’re 10: Don't knock the whole treehouse down. Add one new plank, remove one old plank, until the whole thing is new — and you never fall.
The scariest way to replace a system is to build a brand-new one in secret for two years and flip a switch. These patterns avoid that by replacing the old system a little at a time while it keeps running — so at every moment you have a working product and a short path back.
Strangler Fig
What it is. Named by Martin Fowler after a vine that slowly grows around a tree until it replaces it — the tree, in our story, being nervous old Iggy the Iron Server. You put a facade — a traffic router or gateway that sits in front and decides where each request goes — in front of the old system. At first the facade sends every request to the old system. Then you rebuild one feature at a time in the cloud and quietly reroute just that feature to the new code. Over time more routes point to the new system until the old one handles nothing and can be switched off.
When to use it. Large, risky legacy apps you can't rewrite all at once, especially when the business can't tolerate a long freeze while you rebuild. Trade-offs: you run and pay for both systems during the transition, and the facade itself becomes a critical piece you must keep fast and reliable. The payoff is that risk is spread across many tiny, reversible steps instead of one enormous one.
☺ Like you’re 10: It's renovating a house room by room while you still live in it — you always have a working kitchen, even mid-project.
Anti-Corruption Layer (ACL)
What it is. When your shiny new system has to talk to a messy old one, an ACL is a translator that sits between them, so the old system's weird data shapes and quirks don't "corrupt" the clean new design. The new code speaks its own tidy language; the ACL quietly converts to and from the legacy system's oddities.
When to use it. Whenever new and old must coexist during a long migration — which, with a Strangler Fig, is almost always. Trade-offs: it's extra code to build and maintain, but it stops the legacy mess from leaking into and rotting your new design, which is a bargain over the life of the project.
☺ Like you’re 10: It's an interpreter at the border, so neither side has to learn the other's slang.
Branch by Abstraction
What it is. Instead of routing at the network edge, you introduce an abstraction layer (a common interface) inside the code in front of the thing you want to replace. You build the new implementation behind that same interface, switch callers over gradually, then delete the old one and, eventually, the abstraction.
When to use it. Replacing a component deep inside a single codebase where a network facade doesn't fit — for example, swapping a data-access library or a payment module used all over one application. Trade-offs: it requires access to the source code and a bit of up-front design for the interface, but it lets a large refactor ship in small, safe merges instead of one giant branch that never lands.
☺ Like you’re 10: It's swapping a car's engine by first bolting in a standard mount that either engine can attach to.
Verification: prove the new system is right before you trust it
☺ Like you’re 10: Let the new kid do the same homework as the old kid — secretly — and check if the answers match before you fire the old kid.
Replacing a system is only half the job; you also have to be sure the replacement is correct before real customers depend on it. That's what this pattern is for.
Parallel Run (shadowing)
What it is. Also called shadowing or shadow traffic. You run the old and new systems side by side on the same real inputs. The old system's answer is the one customers actually see; the new system's answer is quietly recorded and compared against it. When the two agree often enough, you trust the new one and let it take over.
When to use it. High-stakes systems where a wrong answer is expensive or hard to undo — billing, payroll, pricing, risk scoring, tax. Trade-offs: you pay to run two systems at once and you need a way to compare their outputs and investigate every mismatch, so it's more effort than a plain cutover. But it turns "we think the new system is right" into "we have weeks of evidence that it is," which is priceless for money-moving code.
☺ Like you’re 10: A trainee cashier rings up the same cart as the real cashier, on a second register that doesn't charge anyone, until their totals always match.
Data patterns: keeping two copies in step
☺ Like you’re 10: While you carry your toy box to the new room, you need a way to make sure a toy added to the old box also shows up in the new one.
During a migration the same data often needs to live in two places for a while — the old store is still taking live changes even as you fill up the new one. Ellie the Elephant (our data keeper — see data migration) leans on three moves to keep the copies honest.
Replication
What it is. An ongoing copy that keeps a target database continuously matching a source. You point it at the source once, and it streams changes across so the target stays fresh in the background. When to use it: the steady, low-fuss background sync from Fort Rusty to the cloud while you prepare a cutover. Trade-offs: it's the simplest continuous-sync option, but it usually copies the whole dataset's changes and can lag if the link is slow or the write volume is high.
☺ Like you’re 10: A magic photocopier that keeps the copy updated whenever the original changes.
Change Data Capture (CDC)
What it is. Instead of re-copying the whole database, CDC reads the database's own change log and streams only what changed — each insert, update, and delete — to the new system in near real time. When to use it: large or busy databases where re-copying everything is wasteful, and when you want the target to stay only seconds behind for a smooth, low-downtime cutover. Trade-offs: it's efficient and low-impact on the source, but it needs the source to expose a change log and a bit more plumbing to set up. It is the workhorse behind most "keep it live until the last second" migrations.
☺ Like you’re 10: Instead of re-photocopying the whole ledger every night, you just mail the day's new entries.
Dual-write
What it is. The application itself writes every change to both the old and new stores at the same time. When to use it: occasionally chosen when you control the app code and want both stores populated without extra replication tooling — but treat it with real caution. Trade-offs: it's simple to picture but risky in practice: if one write succeeds and the other fails, the two copies silently drift apart and you may not notice until reconciliation. Many teams prefer CDC precisely because dual-write is so hard to keep perfectly consistent.
☺ Like you’re 10: Writing every diary entry into two notebooks by hand — easy until the day you forget one.
Dual-write looks simple but is a classic trap: if one of the two writes fails, your copies drift apart silently and you may not notice until reconciliation. When you truly need both stores in sync, CDC from a single source of truth is usually safer than writing to both by hand.
Cutover and deployment patterns: how you flip the switch
☺ Like you’re 10: Different ways to say "okay, now use the new one" — from a scary all-at-once jump to a careful toe-in-the-water.
The cutover is the moment traffic moves to the new system. How you do it changes how much risk you take. A wave decides what moves (see wave planning); a cutover pattern decides how the switch happens. Here are the four you'll meet most often, then a table that lines them up side by side.
Big Bang vs Phased
Big Bang moves everyone at once, in one event — like moving the whole house in a single frantic day. It's the fastest to describe and sometimes fits small, simple systems or hard deadlines, but it stacks every risk into one moment with nowhere to retreat, which is why it so often shows up in the anti-patterns. Phased / Incremental is the opposite: move in stages — a few users, features, or apps at a time — so a failure only ever touches a small slice. It's the natural fit for large, complex estates and dovetails directly with wave planning.
☺ Like you’re 10: Big Bang moves the whole house in one day; Phased moves one room per weekend.
Blue-Green
What it is. You keep two identical environments — Blue (the current one) and Green (the new one). When Green is ready and verified, a router flips all traffic from Blue to Green at once. If anything misbehaves, you flip the same router straight back to Blue in seconds. When to use it: when you need near-zero downtime and, above all, instant rollback. Trade-offs: you must run (and pay for) two full environments at once, and stateful things like databases need care so both sides see consistent data — but the reward is the safest, fastest "undo" of any cutover pattern.
☺ Like you’re 10: Two identical stages; move the spotlight from one to the other, and move it right back if the new act flops.
Canary
What it is. You send a tiny slice — say 5% — of real traffic to the new version first, watch it closely, and only increase the slice as your confidence grows. When to use it: when you want an early warning before full exposure, especially for changes whose effects only show up under real user load. Trade-offs: it's gentler than blue-green's all-at-once flip, but the rollout takes longer and you need good monitoring to notice trouble in that small slice before you widen it.
☺ Like you’re 10: A canary in a coal mine — the small test that warns you early, before everyone is at risk.
Rolling
What it is. You replace servers a few at a time — upgrade some, keep the rest on the old version, repeat — until the whole fleet runs the new version. When to use it: fleets of many identical servers where you don't have (or don't want to pay for) a whole spare environment the way blue-green needs. Trade-offs: no duplicate environment to fund, but for a while old and new versions run at the same time, so they must be compatible, and rolling back means rolling the change back out server by server rather than one instant flip.
☺ Like you’re 10: Repaint a fence one plank at a time without ever closing the whole yard.
What actually flips the traffic?
☺ Like you’re 10: The “switch” is real: either the phone book starts listing the new address, or the receptionist starts pointing visitors at a different door.
Every cutover pattern above says “flip the traffic” — here is what that means in practice. Usually it is one of two things. A DNS change: repoint the system’s name at the new environment’s address. Because the old answer is cached across the internet for its TTL (time-to-live), teams lower the TTL to a minute or two days before cutover so stale caches expire fast — otherwise some users keep landing on the old system long after the flip. Or a load balancer / traffic manager: a router you control that spreads requests across targets — retarget it, and the flip is instant, no caches involved. It is also what makes canary percentages possible: send 5% of traffic to the new version by weight, then dial it up. Blue-green’s “instant rollback” is exactly this: the router flips back to Blue in one move.
| Pattern | What it is | Analogy | When to use |
|---|---|---|---|
| Big Bang | Everyone moves at once, in one event. | Move the whole house in a single frantic day. | Small, simple systems; hard deadlines. High risk — see anti-patterns. |
| Phased / Incremental | Move in stages — a few users or features at a time. | Move one room per weekend. | Large, complex estates where you want to limit blast radius. |
| Blue-Green | Two identical environments; flip all traffic from Blue (old) to Green (new), and flip back instantly if it breaks. | Two identical stages; move the spotlight from one to the other. | When you need instant rollback and near-zero downtime. |
| Canary | Send a tiny slice (say 5%) of traffic to the new version first; watch, then increase. | A canary in a coal mine — the small test that warns you early. | When you want early warning before full exposure. |
| Rolling | Replace servers a few at a time until all run the new version. | Repaint a fence one plank at a time without closing the yard. | Fleets of many identical servers; no spare full environment. |
Connecting the two worlds: bridges and bulk moves
☺ Like you’re 10: While half your stuff is in the old house and half in the new, you need a road between them — and a way to actually haul the heavy boxes over.
Every mid-flight migration has to answer two physical questions: how do the two sides talk? and how do we get the data across? These two patterns cover both.
Online vs offline data migration
Online migration moves data over the network while the source keeps running, usually with replication or CDC keeping things fresh until the final cutover. It minimizes downtime but depends on having enough bandwidth. Offline migration copies data to physical media or a shipped storage appliance and transfers it in bulk — used when there's simply too much data to push through the pipe in a reasonable time. Providers offer both (for example bulk transfer appliances like AWS Snowball, Azure Data Box, or Google Transfer Appliance for the offline case). Rule of thumb: if pushing the data over your link would take weeks, the truck is faster than the wire.
☺ Like you’re 10: You can mail your boxes a little at a time while you still live there (online), or pack a whole truck and drive it over (offline). Sometimes the truck is faster.
Hybrid connectivity: VPN vs dedicated links
During a long migration your on-premises data center (Fort Rusty) and the cloud (Cloudville) must exchange data securely. That temporary — or sometimes permanent — link is hybrid connectivity, and Pip the Hummingbird is its keeper. There are two common shapes:
- VPN (Virtual Private Network) — an encrypted tunnel over the ordinary public internet. Quick to set up and cheap, but it shares the internet's crowds and unpredictable speed. Analogy: a private, locked courier bag riding on public roads.
- Dedicated links — a private physical connection between your network and the cloud, giving steadier speed, lower latency, and more predictable throughput. Each big provider brands its own: AWS Direct Connect, Azure ExpressRoute, and Google Cloud Interconnect. Analogy: a private toll road built just for your trucks — no public traffic.
Rule of thumb: a VPN gets you moving today; a dedicated link is worth it when you're shipping lots of data or need reliable performance for a long transition.
The foundation: the landing zone
☺ Like you’re 10: Before you carry in any furniture, you build the house — floors, locks, wiring, house rules — so everything you move in lands somewhere safe and tidy.
Every pattern above assumes there's already a safe, organized place in the cloud for things to land. Building that place is itself a pattern — the one you do first.
What a landing zone is
A landing zone is the pre-built, secure, well-organized cloud foundation you set up before migrating workloads. It defines your account/subscription structure, network layout, identity and access rules, logging, and guardrails — all as Infrastructure as Code (IaC) so it's repeatable. Benny builds it first so every workload "lands" into a consistent, governed space instead of a free-for-all. Providers ship blueprints for this (AWS Landing Zone / Control Tower, Azure landing zones in the Cloud Adoption Framework, Google's landing zone guidance). See best practices and provisions.
☺ Like you’re 10: You wouldn't move furniture into a house with no floors or locks. The landing zone is finishing the house first.
Why it comes first: the pattern that makes the others safe
The landing zone is what lets every other pattern work without chaos. A Strangler Fig facade needs a governed network to sit in; a blue-green cutover needs two consistent environments; CDC needs secure connectivity and logging. Skip the landing zone and each team improvises its own accounts, networks, and permissions — the exact sprawl that turns a tidy migration into a mess nobody can audit. Building it first, once, as code, is why it's called the foundation.
Almost every safe migration combines patterns: build the landing zone first, connect the two worlds with a bridge, keep data in sync with CDC, replace the app with the Strangler Fig, parallel-run to verify, then cut over with blue-green or canary. Small, reversible steps beat one big leap.
Foxy: Professor, the app is huge and scary. Can't we just build the new one and flip everything over Saturday night?
Gizmo: Yesss! Big bang! One glorious switch! What could possibly go wrong?
Professor Owl: Everything, usually. We wrap the old app in a facade and strangle it — reroute one feature at a time. That's the Strangler Fig.
Benny: And for the cutover I'll build blue-green. Green goes live, Blue waits on standby. If Green wobbles, I flip back in seconds — no frantic Saturday.
Timmy: Fact-check: before Green ever serves a customer, we run it in parallel and compare answers. Trust, then switch.
Gizmo: Ugh, so responsible. My big bang sounded so much more exciting.
Pick a familiar app (say, an online store). Sketch a Strangler Fig plan: draw a facade in front, then list three features (login, product search, checkout) and decide the order you'd migrate them one at a time. For your cutover, choose blue-green OR canary and write one sentence on why. Bonus: mark where you'd add a parallel run to double-check the checkout math.
1. In the Strangler Fig pattern, what is the job of the facade? 2. What's the main difference between a canary deployment and a blue-green deployment? 3. Why do many teams prefer CDC over dual-write? 4. When would you choose an offline (appliance) data migration over an online one, and what's a dedicated link like Direct Connect or ExpressRoute for?
Check your answers
- The facade is a router/gateway that sits in front of the old system and decides, per request, whether to send it to the old system or the newly rebuilt cloud version — letting you reroute one feature at a time.
- Canary sends a small slice of traffic to the new version first and gradually increases it; blue-green keeps two full environments and flips all traffic at once (with instant rollback by flipping back).
- Because dual-write must succeed in both stores every time — if one write fails the copies drift apart silently. CDC streams changes from a single source of truth, which is more consistent and lower-impact.
- Choose offline/appliance transfer when there's too much data to push through the network in a reasonable time. A dedicated link (Direct Connect, ExpressRoute, Cloud Interconnect) is a private, steady, low-latency connection between your data center and the cloud during the transition.