HCSP-Cloud Migration study materials
HCSP-Cloud Migration study resources

HCSP-Cloud Migration cheat sheet

HCSP-Cloud Migration · Keep the key ideas within reach.

Quick reference

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.

Quick reference

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.

Quick reference

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.

Quick reference

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.

Quick reference

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.

Quick reference

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.

Quick reference

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.