Migration Assessment Vocabulary

The application portfolio assessment is the foundation of every cloud migration — without it, you're moving blindly.

What the assessment captures for each application:

Dimension	What you capture
Business value	Revenue impact, user count, business criticality
Technical health	Age, architecture quality, test coverage, known tech debt
Dependencies	Upstream/downstream services, databases, integration touchpoints
Cloud readiness	OS compatibility, licensing model, stateless vs stateful
Migration complexity	Estimated effort, risk level, data sensitivity

Discovery approaches:
• Discovery scan — automated tools (AWS Application Discovery Service, Azure Migrate, CloudEndure) that scan the network and collect server configurations, running processes, and network connections
• Dependency mapping — visualising communication paths between applications to understand what must move together (and what can block a migration)
• Stakeholder interviews — business owners and application teams fill in context automated tools can't capture

Output: the migration portfolio matrix
Applications are plotted on a 2×2 grid: • X-axis: business value (low → high) • Y-axis: technical complexity/risk (low → high)
This drives prioritisation: high-value, low-complexity apps migrate first.

In design discussions:
> "Before we commit to any migration timeline, we need to complete the portfolio assessment — we don't know our dependency graph yet."
> "The discovery scan found 47 applications we didn't know existed. We need to reclassify them before planning wave one."

Key vocabulary:
• Application portfolio — the complete set of software applications owned by an organisation
• Discovery scan — automated collection of server and network metadata to populate the portfolio inventory
• Dependency mapping — mapping communication paths between applications to identify tightly coupled groups
• Migration candidate scoring — ranking applications by business value, technical complexity, and cloud readiness

The 6Rs is a decision framework, not just migration tactics — two of the six Rs result in NOT migrating.

The 6Rs explained:

Strategy	Also called	What happens
Rehost	Lift-and-shift	Move VM to cloud with minimal changes. Fast, low risk. Limited cloud-native benefit.
Replatform	Lift-tinker-and-shift	Move with small optimisations (e.g. move Oracle DB → RDS, keep app unchanged). Some cloud benefit without code rewrite.
Refactor	Re-architect	Redesign app to use cloud-native features (containers, serverless, managed services). High effort, high cloud benefit.
Repurchase	Replace / drop-and-shop	Replace app with a SaaS equivalent. Move from on-prem CRM to Salesforce, for example.
Retire	Decommission	Shut down — the app is no longer needed. Typically 10–20% of portfolios when assessed honestly.
Retain	Revisit later	Keep on-premises for now — migration too risky, costly, or the app is near end-of-life.

In design discussions:
> "We're recommending replatform for the billing service — switch the database to a managed RDS instance, but keep the application code unchanged. We get the operational overhead benefit without the rewrite risk."
> "Finance has agreed to retire 23 legacy apps before we even start wave one. That's 23 fewer migrations to plan."

Common error: defaulting everything to rehost ("lift-and-shift") to hit a migration deadline, then paying full cloud costs for an on-premises-optimised architecture with no cloud-native benefits.

Key vocabulary:
• 6Rs — Rehost, Replatform, Refactor, Repurchase, Retire, Retain
• Lift-and-shift — colloquial term for Rehost: move as-is to the cloud
• Lift-tinker-and-shift — colloquial term for Replatform: move with minor optimisations
• Cloud-native benefit — elasticity, managed services, pay-per-use that justify cloud costs

Waves transform a multi-year portfolio migration into a series of manageable, coordinated sprints.

Typical wave structure:
• Wave 0 (Foundation) — cloud foundation setup: landing zone, networking, identity federation, security baseline, monitoring. No application migrations yet.
• Wave 1 (Pathfinder / Pilot) — 2–5 low-risk, low-complexity applications. Dev/test environments, or a simple internal tool. Goal: validate tooling, team skills, and the migration runbook.
• Wave 2+ — progressively more complex, higher-business-value applications. Each wave builds on learnings from the previous.
• Final wave — the most complex, most critical applications (often the monolith core).

Key wave planning vocabulary:
• Cutover window — the scheduled maintenance window when traffic is switched from on-premises to cloud. Often a weekend overnight window for low-risk transitions.
• Parallel run — running on-premises and cloud environments simultaneously for a validation period before cutover. Increases confidence but doubles cost temporarily.
• Rollback plan — the documented procedure to revert to on-premises if the cutover fails. Every migration should have one.
• Hypercare period — an intensive monitoring and support period immediately after cutover (typically 2–4 weeks). The migration team is on-call for issues.
• Migration factory — a dedicated team and process optimised for high-throughput migrations. Used in large programmes with hundreds of applications.

In planning discussions:
> "Wave 3 has a dependency problem — the payments service can't migrate until the identity service in wave 2 is stable and live."
> "We always plan a parallel run for tier-1 applications — the three weeks of dual-hosting cost is worth the confidence before we pull the plug on on-prem."

Key vocabulary:
• Migration wave — a cohort of applications migrated together in a coordinated batch
• Cutover — the moment traffic is switched from the old system to the new cloud environment
• Parallel run — running both environments simultaneously before committing to cutover
• Hypercare — intensive post-cutover support period; not all migrations need it, but tier-1 systems always do

The landing zone is the cloud foundation that everything else builds on — migrations can't start without it.

What a landing zone includes:
• Multi-account structure — separate accounts/subscriptions for production, staging, development, shared services, and security/audit. "Account per workload" reduces blast radius.
• Network foundation — hub-and-spoke or transit gateway topology; private connectivity back to on-premises (VPN or Direct Connect/ExpressRoute); shared services VPC
• Identity and access — federated identity (SSO from corporate IdP), permission boundaries, privileged access management, break-glass accounts
• Security guardrails — preventive controls (SCPs/Azure Policies preventing insecure configurations) and detective controls (CloudTrail/Security Command Center enabled everywhere)
• Centralised logging — all accounts ship logs to a dedicated, immutable log archive account
• Cost management — tagging standards, budget alerts, cost allocation

Cloud Adoption Framework (CAF):
The CAF is the structured methodology (AWS CAF, Azure Adoption Framework, Google Cloud Adoption Framework) that guides the full migration lifecycle:
• Envision phase — align on cloud strategy, business outcomes, migration scope
• Align phase — readiness assessments, skill gaps, operating model design
• Launch phase — build the landing zone, pilot migrations, refine the factory
• Scale phase — wave migrations, optimisation, cloud-native modernisation

Operating model transformation — the shift from managing physical hardware to managing cloud platforms: new skills (cloud certifications), new processes (cloud governance), and new teams (Cloud Centre of Excellence).

In design discussions:
> "We can't start wave 1 migrations until the landing zone is in place and the security review is signed off."
> "The landing zone is owned by the cloud foundation team — application teams land into it; they don't design it."

Key vocabulary:
• Landing zone — the pre-built, secure cloud environment that migrated applications deploy into
• Cloud Adoption Framework (CAF) — vendor-provided methodology for structured cloud adoption
• Guardrail — a preventive or detective control enforced at the landing zone level
• Cloud Centre of Excellence (CCoE) — the internal team that owns cloud standards, the landing zone, and cloud governance

TCO analysis makes the business case for migration by comparing apples to apples — all costs, both sides.

On-premises costs often hidden in business cases:
• Hardware refresh cycle — servers depreciate over 3–5 years; replacement cost must be amortised
• Data centre overhead — floor space, power, cooling, physical security, fire suppression
• Support contracts — hardware maintenance, OS licences, storage array support
• Staff time for toil — patching, hardware swap-outs, capacity planning, on-call for hardware failures
• Stranded capacity — servers provisioned for peak load, idle at 15% average utilisation

Cloud cost concepts:
• On-Demand pricing — pay-as-you-go, highest rate, maximum flexibility
• Reserved Instances / Committed Use — commit to 1 or 3 years for 40–60% discount
• Savings Plans — flexible commitment (spend X/hour for 1–3 years) for similar savings with more instance-type flexibility
• Spot / Preemptible instances — up to 90% cheaper, but can be reclaimed; suitable for batch/stateless workloads
• Rightsizing — matching instance size to actual workload requirements vs over-provisioned on-prem servers

CapEx vs OpEx framing:
On-premises: heavy upfront CapEx (buy hardware), lower ongoing OpEx
Cloud: zero CapEx, ongoing OpEx (pay for what you use)
This shift matters for budget cycles, tax treatment, and cash flow — CFOs often prefer OpEx.

In financial discussions:
> "Our current data centre costs $4.2M/year once you include hardware refresh, facilities, and staff time. The cloud equivalent with reserved instances and rightsizing is $2.8M — a 33% saving. But migration cost is $600K, so payback is 18 months."

Key vocabulary:
• TCO (Total Cost of Ownership) — the full cost comparison between on-premises and cloud options
• CapEx — Capital expenditure: upfront asset purchase (on-premises servers)
• OpEx — Operating expenditure: recurring costs (cloud bills)
• Rightsizing — matching cloud instance type/size to actual workload requirements
• Reserved Instances / Savings Plans — commitment-based pricing discounts (40–60% vs on-demand)