Migration & Modernization

You are moving house, and every object in the house gets its own decision. The sofa you like goes on the van as-is (rehost). The old fridge stays behind because the new kitchen has one built in (repurchase). The boxes of paperwork from 2009 go in the skip (retire). The piano stays because the new place has no ground-floor room and moving it costs more than it's worth (retain). The flat-pack shelving gets rebuilt to fit the new alcove (replatform). And the kitchen itself — the thing you actually use every day, that has annoyed you for a decade — gets redesigned from scratch, which is why you do exactly one of those (refactor).

Nobody sensibly says "I will apply the same treatment to every object in my house."

Mechanically, the R's differ along three independent axes that the patterns catalog separates cleanly, and which are worth holding apart in your head:

• Platform — where it runs: traditional IT or cloud. Changing this is migration.
• Architecture — how it's structured: unstructured monolith, modular monolith, or distributed. Changing this is modernization.
• Packaging — how it's deployed: bare metal, virtual server, or container. Changing this is also modernization, and it's independent of architecture — you can containerise a big ball of mud, and people do.

These vary independently, which is the whole reason the R's exist as separate labels. Rehost changes platform only. Replatform changes platform and packaging. Refactor changes architecture, and usually all three.

Expand each R below for its definition, what it actually costs, and the specific trap that comes with it.

Distribution. A common shape for an enterprise portfolio, reported by practitioners running AWS Migration Acceleration Program engagements, is roughly 40–50% rehost, 20–30% replatform, 10–15% refactor, and the remainder split across retire, retain, repurchase and relocate. If your plan is 80% refactor, you have written a wish; if it's 100% rehost, you have written a relocation invoice.

The R is not permanent. The most useful mental model is that R's compose over time: rehost now to hit the lease date, replatform in year two once the estate is stable, refactor the two applications that actually justify it in year three. AWS Prescriptive Guidance says this explicitly for large migrations — refactor is not recommended during a large migration precisely because it's hard to manage across many applications at once; rehost, relocate or replatform, then modernise afterwards.

Where it breaks. Two failure signatures worth recognising:

• The R was chosen by the wrong person. Architects pick refactor; finance picks rehost; the app owner picks retain. The choice needs all three inputs, and the tiebreaker should be the application's change frequency, because that's what determines whether architectural improvement pays back.
• The R was chosen once and never revisited. Discovery changes the picture. An app you scoped as rehost turns out to depend on a physical licence dongle; that's a retain, and it may drag three dependents with it.

The one honest three-cloud mapping in this session. There is no product for "choose an R," but all three vendors publish a structured adoption/migration framework, and they genuinely differ in emphasis:

Sources: AWS Prescriptive Guidance — migration strategies Microsoft Cloud Adoption Framework Google Cloud — Migration to Google Cloud

Before movers arrive, somebody walks through the house and writes on each box which room it goes to, whether it's fragile, and what it's connected to. Skip that and the movers make the decisions for you — badly, at speed, at 6pm.

Assessment is that walk-through. Its output is not a spreadsheet of servers. Its output is a dependency graph with an R written on every node.

Assessment collects four things, in this order:

Three kinds of dependency edge behave very differently, and mixing them up is the single most common wave-planning error:

Agent versus agentless discovery. Agentless collectors read from the hypervisor or the network and give you inventory and coarse flows with no footprint on the guests. Agents give you process-level detail — which process opened that socket — which is what you actually need to attribute a flow to an application. Agents also require change approval on hundreds of production servers, which in a regulated environment is a months-long conversation. The usual answer is agentless across the estate, agents on the twenty machines you're most worried about.

How long to collect. Two weeks is the common default and it is too short. It catches daily and weekly patterns and misses everything monthly, quarterly, and annual. If your deadline permits, collect for a full quarter. If it doesn't, compensate by reading scheduler configuration directly — crontabs, scheduled tasks, job-scheduler definitions — because those declare the periodic dependencies that flow capture will miss.

The thing assessment can't tell you. Tooling reports what the estate does. It cannot tell you what the business needs, what the maximum tolerable downtime is, or whether an application is strategic. Those come from humans, and they are the inputs that decide the R.

Moving a person is easy. Moving a person's library of ten thousand sources is not. So when someone with a huge library relocates, the materials go first and everything else arranges itself around when they arrive — and if the materials genuinely can't move, the person ends up living near the materials.

That's data gravity, a term coined in 2010. Large datasets are slow and expensive to move, so applications and services accumulate around them rather than the reverse. Mass attracts.

Gravity has three separate components, and they don't always point the same way:

The arithmetic is worth having in your head, because it converts an argument into a number. Work in decimal units and remember that 1 TB = 8,000 gigabits:

Rates as published mid-2026; tiers reduce the rate at volume and all three vendors now waive exit egress under specific conditions — see S3 for the fine print.

Gravity is now shaping architecture, not just schedules. The interesting shift over the last couple of years is that at AI scale the old assumption — move data to compute — has inverted for a growing class of workloads. Moving hundreds of terabytes across clouds can cost on the order of the compute itself, sovereignty rules increasingly forbid it outright, and open formats have made compute more portable than data ever was. The pattern that's emerging is the opposite of the one you were taught: put the workload where the data already lives.

Beware fake gravity. Not all bytes are equally heavy. A dataset is only gravitationally significant if it is irreplaceable at the destination. Ten terabytes you can re-derive, re-download from a public source, or regenerate has almost no gravity, however large it looks in the inventory. This distinction matters a great deal for your own workloads and it's the core of the apply-it section below.

The escape hatches. When gravity is genuinely too strong, you have four moves, in increasing order of commitment: (1) don't move the data — put compute next to it via a hybrid link; (2) move it physically on an appliance rather than over the wire; (3) move only the derived/aggregated form and leave the raw data behind; (4) accept a period of dual residency where both copies exist and you pay for both. Option 4 is the most common and the least planned-for.

You don't move a hospital in one night. You move a ward at a time, keeping every patient treated throughout, and you pick the first ward because it's the one where a mistake is survivable — not because it's the most important.

A wave is a batch of applications that move together in one window. A move group is the set of applications that must move together because splitting them would break something. Waves are a planning choice; move groups are a physical fact you discover during assessment.

Wave planning follows six rules, in priority order. When they conflict, the earlier rule wins.

Cutover: the only irreversible hour

Everything up to cutover is reversible at near-zero cost, because the source system is still serving traffic. The technique you can use is decided by exactly one number: how much downtime the application can tolerate.

DNS TTL. A record with a 24-hour TTL means some clients keep hitting the old endpoint for a day after you flip. Drop TTLs to 60 seconds days before the cutover, not during it. And remember that some clients — particularly older JVM configurations — cache DNS resolution for the life of the process regardless of TTL.

The source you left running. If the old system stays up "just in case" and still accepts writes, you now have a split brain and nobody has noticed. Firewall the old system's write path at cutover, keep it readable for comparison, and set a hard deletion date.

Licensing and hardcoded assumptions. Licences keyed to MAC addresses or hostnames. Certificates pinned to old names. IP addresses hardcoded in configuration files that no longer exist in source control. These are discovered at 03:00 on cutover night unless you find them during a test launch — which is precisely what test launches are for.

Wave fatigue. Fixed cadence means the same people run a cutover every fortnight for a year. Rotate the on-call role, keep a written runbook rather than tribal knowledge, and treat the third-to-last wave with the same discipline as the first — the failure rate goes up at the end, not down, because the remaining applications are the ones everybody deferred.

A strangler fig germinates in the canopy of a host tree and sends roots down its trunk. Over years the roots thicken, fuse into a lattice, and take over the job of holding the canopy up. Eventually the host dies and rots away, and what's left is a hollow, self-supporting fig in exactly the shape of the original tree. At no point was there a moment when the forest had no tree standing there.

the refactoring literature borrowed the metaphor for software. You grow a new system around the old one rather than beside it, take over one responsibility at a time, and delete the old code as each responsibility transfers. There is never a day when the system is down, and there is never a version that hasn't been in production.

The patterns catalog adds a useful distinction: strangling is really two activities running in parallel. Abandonment — all new work happens outside the monolith, so it stops growing. Migration — existing functionality is progressively reimplemented outside it, so it starts shrinking. In rare cases where usage patterns change fast enough, abandonment alone finishes the job and the monolith simply becomes irrelevant.

Mechanically the pattern has exactly one prerequisite and then four repeating phases. The prerequisite is a facade: a routing layer through which all client traffic passes before it reaches either system. Without it you cannot redirect a slice, and without redirection there is no strangler fig — just two systems.

The mechanism itself, in eight lines

The facade is not conceptual — it's a routing rule. Here is what shifting one slice actually looks like, expressed as a weighted split at the proxy. This is the artefact the entire pattern rests on:

# facade: move 5% of one slice to the new service, everything else untouched
location /api/statements/ {
    split_clients "${remote_addr}${request_id}" $slice {
        5%   statement_svc;   # canary share — raise 5 → 25 → 100 over days
        *    monolith;        # default stays legacy until you say otherwise
    }
    proxy_pass http://$slice;
}
# every other path falls through to the monolith, unchanged

Three properties make this the right primitive. It is reversible in one deploy — change 5% to 0% and you are back. It is sticky per client, because the split key includes the client address, so a given user doesn't flip between implementations mid-session. And it is observable: the proxy emits which branch served each request, so your comparison data comes for free. A feature flag inside the monolith gives you none of the first and only some of the third.

You run two systems for a long time. This is the real price, and it is not small: two deployment pipelines, two monitoring stacks, two on-call rotations, two sets of skills, and a technology diversity that raises total cost of ownership for the duration. Teams reject the pattern on these grounds and they are not being stupid — they are just comparing it to a rewrite that finishes on schedule, which is a fictional comparison. Against a rewrite that actually finishes when rewrites actually finish, strangling is cheaper as well as safer.

The benefits arrive late and the costs arrive early. Because it's gradual, you carry the overhead of two systems from month one and only reach a materially better architecture in year two. This is a funding and attention problem more than an engineering one, and it's why the pattern needs an executive sponsor who understands what they've signed up for.

Data is where it genuinely gets hard. A monolith uses a centralised database; services want to own their own stores. Every slice you extract raises the same questions: consistency across two stores, transactions that used to be one commit and now aren't, queries that used to be a join and now need two calls, and reporting that assumed everything lived in one schema. The cross-service transaction that used to be a database transaction typically becomes a saga. Budget for this explicitly — the data work is usually larger than the code work.

When it doesn't apply. The pattern needs a chokepoint. If clients call the system as an in-process library, or link against it, or hit hardcoded addresses you cannot change, there is nowhere to put a facade. Your first job then is not strangling — it's refactoring internal boundaries until a facade becomes possible, which is the patterns catalog's Refactor the Monolith as a precondition rather than a goal.

What the numbers say. Published research on incremental modernization is encouraging but should be read with the usual caution about vendor-adjacent studies: Kyndryl's 2025 research reported an average ROI around 288% for organisations modernizing mainframe applications using incremental approaches, and McKinsey's analysis of programmes completed in 2024–25 reports infrastructure cost reductions in the 30–50% range with 20–30% improvement in development cycle times. Treat those as evidence that the approach works, not as a forecast for your programme.

You've hired a brilliant translator to work with a foreign partner whose contracts use archaic terminology, inconsistent units, and one field that means three different things depending on a flag elsewhere in the document. The translator's job is not to pass the archaic terms through with a footnote. It is to produce a clean document in your language, so that everyone downstream can reason normally without learning the partner's dialect.

That is the anti-corruption layer. Note the name: the thing being prevented is corruption of your model, not corruption of data. Without it, the monolith's ST_FLG column with its values 'A', 'C' and 'X' propagates into your new service, then into its API, then into the next three services that consume it, and five years later somebody is still asking what 'X' means.

Concretely an ACL is a translation function at the service's edge, and the whole discipline is that the legacy vocabulary must not survive the crossing. Nothing past this function knows the monolith exists:

# anti-corruption layer: legacy shapes stop here and go no further
def to_statement(row):                                    # row = raw LEDGER_STMT record
    return Statement(
        id      = StatementId(row["STMT_ID"].strip),     # padded char → typed id
        period  = Period.from_yyyymm(row["PRD"]),         # "202607" → Period
        balance = Money(row["BAL_CENTS"], row["CUR_CD"]),  # int + code → Money
        status  = STATUS_MAP[row["ST_FLG"]],              # 'A'/'C'/'X' → enum
    )                                                    # unknown flag ⇒ raise, don't pass through

Four things that small function is doing, each of which is a boundary you'd otherwise leak: normalising a padded fixed-width identifier into a typed one; converting an encoded date into a real domain concept; combining two columns that only mean something together into a single value object; and turning an opaque flag into a named enumeration. And the last line matters most — an unmapped flag raises rather than falling through, so unknown legacy states surface as errors during the shadow phase instead of as silent nulls in production.

Facade versus monolith-to-microservice proxy — when to use which

The patterns catalog separates these carefully and the distinction is practical. A facade intercepts traffic arriving from outside. It cannot intercept calls made inside the monolith, because those are in-process method calls that never touch the network. So when you extract a component that other monolith code calls, you have two options:

In practice most teams use both: the proxy first, to get the extraction shipped, then rewrite call sites opportunistically whenever they're touching that code anyway. And note the proxy can be asynchronous — the old synchronous method can publish to a queue that the new service consumes, which is exactly how the retail example in the patterns catalog fixed a Black Friday thread-pool collapse by decoupling order capture from order writing.

The ACL has an expiry date, and you should write it down. While the monolith exists, the ACL earns its keep. Once the legacy source is gone, an ACL that survives is just an extra mapping layer nobody remembers the reason for. Tag these classes so that "delete the ACL" is a visible item on the decommissioning checklist, not an archaeological discovery in 2031.

Facades accumulate responsibilities. A facade is an attractive place to put things: routing, protocol translation, authentication, rate limiting, caching, circuit breaking. Each is defensible; collectively they turn your routing layer into a second monolith that every team must change and nobody owns. Keep policy in the facade and keep business logic out of it. The test: if changing a business rule requires a facade deploy, the rule is in the wrong place.

Every hop is a new failure mode. An in-process call that could not fail is now a network call that can time out, retry, and partially succeed. Adding a proxy hop to a call path that was previously a method invocation changes its reliability characteristics, and the code around it was written assuming it couldn't fail. Timeouts and circuit breakers at these boundaries are not optional polish.

A stonemason splitting a block doesn't hit it in the middle. They look for the fracture plane — the line along which the material already wants to separate — and apply force there. Hit the wrong place and you get rubble.

Monoliths have fracture planes too. The patterns catalog calls them hairline cracks: places where functionality is already more cohesive internally than it is coupled externally. Finding them is most of the skill; the extraction itself is comparatively mechanical.

Three categories of crack are easy to spot, in decreasing order of luck:

Once you've found a crack, exactly three moves are available. Which one you use is determined by how coupled the target is, not by preference:

A useful diagnostic for locating candidates that the material recommends and that costs almost nothing: look at your commit history and your issue tracker. The parts of the monolith that change most often and break most often are, almost by definition, the parts where extraction pays back fastest. Static analysis tools that surface coupling and code smells help, but change frequency is the better signal because it's about cost, not aesthetics.

Macro services are a feature, not a compromise. There is real pressure to extract "proper" microservices immediately. Resist it. Pulling out one large, internally-tangled component is a genuine win — it is now independently deployable and independently scalable — and you can split it later with far better information, because you'll have watched it run. The patterns catalog's airline example did exactly this: the ticket purchase process came out as one large service with messy internal switches, and was refined over several later releases.

Two orderings, both valid. Bottom-up means starting with the obvious low-hanging fruit — fast wins, good for morale and learning, but the resulting service boundaries may not follow the domain. Top-down means starting from business capabilities and carving downward — better boundaries, much slower start. Most successful programmes are bottom-up for the first few slices to build capability and credibility, then switch to top-down once the team understands the domain well enough to model it.

Right-size against the domain, not against a line count. Whichever move you use, the boundary should follow a bounded context from C6. A service split along a technical seam that cuts through a domain concept will need chatty coordination with its neighbour forever, and that chattiness is permanent.

Changing banks. For a while you keep both accounts open. New income goes into both — well, you can't actually do that with money, which is precisely why this is hard in software too. What you can do is: run both accounts, move the historical statements across, check the balances match for a couple of months, and only then close the old one. Nobody sensible closes the old account the day the new one opens.

Three separate activities hide in that story. Dual-write — new events land in both places. Backfill — the history the new place never saw gets copied across. Reconciliation — you prove the two agree before you commit to one.

The full sequence for moving one slice's data, with the source of truth marked at every stage. The whole design principle is that exactly one store is authoritative at any moment, and the switch of authority is a single explicit step — never an emergent property of routing weights.

What each stage is actually for

Playback testing: how you validate a rewrite with no specification

When you Replace as Microservice you are reimplementing behaviour that nobody fully understands, in a system with inadequate tests, where some of the bugs are load-bearing. The patterns source's answer is playback testing — also called a parallel run. Capture a set of real inputs and actions against the original system, replay the identical sequence against the new implementation, and compare the results.

Two practical forms. The simplest: run both against equivalent databases and diff the resulting state — feasible when the new schema is similar, harder when it isn't, in which case you write extraction scripts that normalise both sides before comparing. The richer form: capture live transactions as events over a period, transform them to the new service's API, and replay. If you're using CQRS, capturing calls to the write model gives you this almost for free.

The decision that catches people out is how often you compare. Comparing only final state at the end of a long replay is cheap and tells you little about where a divergence started. Step-by-step comparison after each transaction localises failures immediately and costs far more to build. Start with end-state comparison plus periodic summaries; add step-by-step only for the slices where you're finding divergences.

Dual-write is not atomic, and pretending otherwise is the classic bug. The monolith commits, then the write to the new store fails. If your code treats that as a transaction and rolls back, you've made a working system fail because of a system that isn't live yet. The correct behaviour is: commit to the materialitative store, attempt the secondary write, log failures to a repair queue, and let reconciliation catch what the queue misses. Your divergence count will be non-zero for a while. That's the design working, not a defect.

Backfill races live writes. While you're copying 2019's rows, 2026's rows are arriving. Chunk by a stable key, make every write an upsert keyed on identity, and never let backfill overwrite a newer value with an older one. Getting this wrong produces the worst class of bug in the whole pattern: silent, historical, and discovered months later during an audit.

Reporting is the slice everyone forgets. Reports join across everything. The moment one slice's data lives elsewhere, every report touching it breaks or silently under-reports. Plan for reporting explicitly — usually by keeping a consolidated read model fed from both sides for the duration, which is more work than it sounds and is never in the original estimate.

Deciding when to stop reconciling. There is no formula. What works is a written criterion agreed in advance — for example, zero unexplained differences across two consecutive month-end cycles — recorded before you start, so the decision isn't made under deadline pressure by whoever is most tired.

A removals company doesn't sell you one product. There's the surveyor who walks the house and quotes (discovery and assessment). There's the van for furniture (VM migration). There's the specialist who dismantles and rebuilds the piano (containerisation). There's the separate service for the wine cellar, because bottles need temperature control and can't just go in a box (database migration). And there's the shipping container for the twenty tonnes of stuff going by sea because it won't fit in the van (bulk data transfer).

Then there's the storage unit you keep renting because some things aren't moving yet (hybrid). Every cloud sells all six. They differ in emphasis, not in the shape of the problem.

Layer 1 — Discovery and assessment

Sources: What's new in Azure Migrate GCP Migration Center — migration tools AWS Transform

Layer 2 — VM and server replication (the rehost engine)

All three work the same way, and knowing the mechanism means you can reason about any of them: install a lightweight agent on the source machine; it replicates disk blocks continuously over an encrypted channel into a staging area in the target account; you launch test instances into an isolated network as often as you like without touching the source; and when you're satisfied you cut over, which stops the source and launches the real target from the latest replicated state. Because replication is continuous, the downtime at cutover is only the final delta — typically well under an hour.

Sources: AWS Transform MGN product page (page updated 15 Jul 2026) AWS — sunsetting CloudEndure and SMS Azure Migrate release notes GCP migration tools

Layer 3 — Containerisation (the replatform engine)

Source: Migrate to Containers and its release notes; AWS migration tool landscape 2026

Layer 4 — Database migration

Two distinct jobs hide under one heading. Homogeneous migration — Oracle to Oracle, PostgreSQL to PostgreSQL — is mostly a data-movement problem. Heterogeneous — Oracle to PostgreSQL, SQL Server to Aurora — additionally requires schema and code conversion, and that second part is where the effort actually is. A heterogeneous database migration is a refactor wearing a replatform's clothes: stored procedures, triggers, proprietary SQL dialects and application data-access code all need changing.

Sources: Microsoft — SQL migration to Azure VMs GA, July 2026 Accelerate SQL Server migration with Azure Arc GCP Database Migration Service docs

Layer 5 — Bulk data transfer, and the death of the appliance

Sources: AWS Snowball — end of support notice (page updated 27 Jul 2026) AWS Data Transfer Terminal — six new locations, Feb 2026 GCP Transfer Appliance guidance Azure Data Box

Agents are the hidden cost, in two senses. Financially, replication agents and replication tasks bill continuously while they exist — including for source servers you cut over weeks ago and forgot to disconnect. Organisationally, installing an agent on several hundred production servers is a change-management project in its own right, which is why agentless discovery exists and why most programmes use agentless broadly with agents only where they need process-level attribution.

Free tool, expensive migration. Every VM-replication and containerisation tool here is free or free-for-a-window. That is not generosity; it's the correct commercial strategy for a switching cost. What you pay for is the staging storage during replication, the target compute from the moment you launch a test instance, the data transfer, and — on the source side — egress if you're coming from another cloud. Budget the migration, not the tool.

The 90/180-day clocks are per source server, and they start at first replication. A programme that begins replicating in wave 1 and cuts over in wave 6 can quietly exhaust a free window on machines that sat replicating for months. Start replication close to the wave that needs it.

Tool coverage is not uniform, and the gaps are where the schedule slips. Every vendor's tooling is strongest for the mainstream case — a Linux or Windows VM running a common runtime — and thins out fast at the edges: unusual operating systems, appliances you don't control, licence-bound software, and anything with a kernel module. Assume the last 10% of the estate needs a bespoke approach and price it separately, because it will consume a disproportionate share of the calendar.

You've retained some applications on-premises. You still want one way of operating everything. Three companies have solved this and — unusually for cloud comparisons — they have solved it in three genuinely different ways, not three brands of the same thing.

AWS ships you their hardware. A rack arrives, it runs AWS services, you use the same APIs. Microsoft extends their control plane over your hardware. Nothing arrives; your existing servers get projected into Azure's management model and you govern them from there. Google gives you a Kubernetes fleet. Clusters anywhere — their cloud, your data centre, someone else's cloud — managed as one fleet with consistent config and policy.

Which is right depends entirely on what you're trying to make consistent: the infrastructure, the governance, or the workload.

Sources: Google Distributed Cloud software-only docs (naming history) GKE Enterprise release notes Azure Arc documentation

Hybrid is a destination for some workloads and a phase for most. Applications you genuinely retained — sovereignty, physical dependency — are permanently hybrid, and a control plane is worth buying for them. But most hybrid connectivity exists because a migration is in progress, and that is a temporary condition you should be actively trying to end. A hybrid link that was supposed to last eighteen months and is still there at year five is a sign that the migration stalled — the infrastructure equivalent of the strangler fig that never finished.

Latency is the constraint nobody models. Splitting an application across the hybrid boundary is fine for an API edge and catastrophic for a chatty one, which is exactly the third component of data gravity from Session 1. A page render doing 200 database queries at 0.5 ms locally becomes 200 queries at 15 ms across a link — three seconds instead of a tenth of one. Measure the query count per request before you plan to split anything across the gap.

Consistency has three meanings and vendors conflate them. Consistent APIs (Outposts), consistent governance (Arc), and consistent runtime (GKE Enterprise) are different products solving different problems. Ask which one you actually need. Most enterprises discover they need governance consistency far more urgently than API consistency, which is a good part of why Arc has done as well as it has.

Hybrid is not multi-cloud, and multi-cloud is not portability. Running things on two clouds gives you redundancy and negotiating leverage and costs you a second set of everything. Actual portability requires designing for it — containers, open formats, no proprietary managed services in the critical path — and that design costs you the leverage of the managed services you didn't use. There is no free version of this trade-off; there is only being deliberate about which side you're on.