HCSP-Cloud Migration cheat sheet
HCSP-Cloud Migration · Keep the key ideas within reach.
Cloud Migration Overview and Methodology
The 7 Rs: Retire, Retain, Rehost, Relocate, Replatform, Repurchase, Refactor. Rehost (lift-and-shift) is fastest but yields the least cloud benefit; Refactor yields the most but costs the most time and risk.
The 6 Rs variant (AWS) omits Relocate and treats Replatform/Repurchase/Refactor separately; Relocate means moving to a vendor-managed platform (for example VMware workloads to a native cloud VMware service) without code change.
Migration phases: Assess, Mobilize (pilot), Migrate and Modernize, Operate and Optimize. The Mobilize phase produces the landing zone and the migration factory before wave execution.
A migration factory is a repeatable, standardized execution pipeline (people, tools, runbooks) sized in waves; throughput is measured in applications migrated per wave, not per project.
Prioritization rule: migrate low-risk, high-value workloads first to build pattern reuse; defer high-coupling legacy systems with no business case to Retain or Retire.
Total cost of ownership comparison must include run cost, licensing (BYOL vs. included), egress, support tiers, and staff retraining, not just compute price.
Business case drivers: data center exit, end-of-support hardware or OS, elasticity, disaster recovery improvement, and application modernization; each driver maps to a different target architecture.
Anti-patterns: migrating without an inventory, treating migration as pure infrastructure work, and rehosting everything with no modernization roadmap.
Migration Assessment and Planning
Discovery outputs: application inventory, dependency map (network flows, ports, protocols), performance baselines, and ownership records. Automated discovery agents or network-flow analysis complement stakeholder interviews.
Dependency classes: hard (synchronous, low-latency required), soft (tolerates latency or async), and none. Only hard dependencies constrain a wave's move group.
Right-sizing rule: size from observed peak utilization over a representative window (commonly 4 weeks or more), not from provisioned capacity; add headroom for growth.
A move group is a set of workloads that must migrate together because of hard dependencies; wave planning sequences move groups by risk, value, and shared infrastructure.
A landing zone defines accounts/subscriptions, network topology, identity, logging, guardrails, and connectivity; it must exist before the first wave.
Risk register entries should capture per-application cutover risk, rollback feasibility, data sensitivity, and regulatory constraints, each with an owner and mitigation.
Readiness gates for a wave: landing zone validated, connectivity tested, runbooks approved, rollback proven, and stakeholder sign-off recorded.
TCO and business case models should be validated against a pilot wave's actual costs before committing to full-scale funding.
Application and Workload Migration
Rehost tooling: agent-based replication (block-level, continuous) enables minimal-downtime cutover; test launches run in an isolated network before final cutover.
Replatform candidates: self-managed databases to managed database services, self-managed message brokers to managed queues, and local file shares to object storage, with code changes limited to connection and configuration layers.
Refactor triggers: monolith scaling limits, release cadence bottlenecks, and licensing costs; refactoring should be scoped per service with independent deployability as the goal.
Stateless tiers migrate first and independently; stateful tiers require data synchronization and are sequenced last in a move group.
Session and configuration externalization (to a cache or config service) removes host affinity and is a prerequisite for horizontal scaling after migration.
Hard-coded IPs, hostnames, and local file paths are the most common blockers; resolve via DNS abstraction, service discovery, or parameterized configuration.
Repurchase (SaaS replacement) requires data export, integration rework, and identity federation planning; it is rarely a pure infrastructure task.
Post-migration validation per application: functional smoke tests, integration tests, latency comparison to baseline, and log/error-rate comparison.
Data and Database Migration
Migration methods: offline (backup/restore, downtime equals data size divided by transfer rate), online (change data capture or log shipping, near-zero downtime), and hybrid (bulk load plus CDC catch-up).
CDC replicates ongoing changes after an initial full load; cutover occurs when replication lag reaches zero and the source is quiesced.
Homogeneous vs. heterogeneous migration: heterogeneous requires schema conversion plus data type mapping, and often application SQL rewrites.
Data validation techniques: row counts, checksums or hash totals per table, sampled field-level comparison, and referential integrity checks after load.
Large-object and BLOB migration should use parallel streams and direct-to-storage transfer paths; small-file transfers suffer per-object overhead.
Cutover sequence for databases: enable CDC, validate lag, freeze writes, final sync, validate, repoint connection strings, then open writes on target.
Rollback for data requires either a reverse replication path or a defined point-in-time restore plus a reconciliation window; both must be tested in advance.
Data residency and encryption requirements constrain target region and key management choices, and must be resolved during assessment, not at cutover.
Infrastructure and Platform Migration
Network design: non-overlapping CIDR ranges, hub-and-spoke or transit-gateway topology, and hybrid connectivity via VPN (internet, lower cost) or dedicated interconnect (private, higher bandwidth, longer lead time).
Identity: federate directory services to cloud identity, use role-based access instead of shared credentials, and map existing groups to cloud roles before wave 1.
Landing zone guardrails: organization policies, centralized logging, key management, network segmentation, and budget alerts applied at the account or subscription level.
Compute selection rule: lift-and-shift VMs for legacy OS dependencies; containers for stateless services with steady release cadence; serverless for event-driven, spiky, or low-duty-cycle workloads.
Storage tiering: object storage classes for cold data, block storage tiers by IOPS need, and lifecycle policies to move aging data automatically.
Hybrid extension options: dedicated host or bare-metal services for licensing (BYOL) and latency-sensitive systems that cannot tolerate virtualization overhead.
Infrastructure-as-code for all landing zone and workload provisioning ensures reproducibility and drift detection across waves.
Capacity planning must account for reserved/committed-use discounts and autoscaling behavior; over-provisioning silently erases business case savings.
Migration Implementation, Cutover, and Validation
Cutover runbook contents: ordered task list with owners, timings, verification steps, communication plan, and explicit go/no-go decision points.
Cutover window types: big-bang (single window, all users), phased (cohorts or regions), and parallel run (both systems live, results compared) which is safest and most expensive.
Rollback trigger criteria must be defined numerically before cutover (for example error rate above threshold or replication lag above threshold) to avoid subjective decisions.
DNS cutover uses low TTL values (for example 60 seconds) set days in advance; clients and caches must be flushed and old records retained for rollback.
Validation layers: infrastructure health, application smoke tests, end-to-end business transaction tests, performance against baseline, and security control verification.
Hypercare period (typically 1-4 weeks) with elevated support staffing and daily triage; exit criteria are stable error rates and closed severity-1/2 issues.
Communication cadence: pre-cutover notice, start and completion notices, and a post-cutover summary to stakeholders and service desk.
Freeze windows: no unrelated changes to source or target systems during cutover, enforced by change management.
Operations, Optimization, and Governance After Migration
FinOps cycle: inform (tagging, showback), optimize (rightsizing, commitment discounts, idle cleanup), operate (budgets, anomaly alerts, review cadence).
Tagging policy minimum: owner, application, environment, cost center, and data classification; untagged resources are reported and remediated on a schedule.
Rightsizing rule: sustained CPU and memory utilization below a threshold (commonly 20-40 percent) over a review period indicates downsizing candidates; assess memory before CPU for stateful systems.
Commitment strategy: baseline steady-state load covered by reserved or committed-use purchases; variable load left on-demand; spot or preemptible for fault-tolerant batch.
Observability baseline: centralized logs, metrics, traces, dashboards per application, SLOs with error budgets, and alert routing to on-call.
Governance mechanisms: policy-as-code guardrails, periodic access reviews, drift detection against infrastructure-as-code, and exception approval workflow.
Post-migration optimization backlog: decommission retained legacy systems, retire duplicate tooling, and convert rehosted workloads to managed services where the business case holds.
Periodic migration review compares actual run cost and performance against the original business case and updates the modernization roadmap accordingly.