HCSP-Cloud Migration key terms

The process of moving some or all of an organization's applications, data, and infrastructure from on-premises or legacy environments into a cloud platform, with planned changes to architecture, operations, and cost model.

A documented approach describing which workloads move, in what order, using which technique, and under what constraints such as budget, downtime tolerance, and compliance. It aligns technical work with business outcomes.

A classification of migration approaches: rehost, replatform, refactor or re-architect, repurchase, retain, and retire. Each workload is assigned one approach based on value, cost, risk, and technical fit.

Moving a workload to cloud infrastructure with little or no code change, often called lift-and-shift. It is fast and low-risk but usually delivers limited cloud benefit until later optimization.

Migrating a workload while making targeted changes to use managed cloud services, such as swapping a self-managed database for a managed one. It trades modest effort for reduced operational burden.

Redesigning an application's architecture to take full advantage of cloud characteristics such as elasticity, managed services, and decoupling. It offers the greatest long-term benefit but carries the highest cost and risk.

Replacing an existing application with a different product, typically a SaaS offering, instead of migrating the original. Data export, integration, and license exit terms must be planned carefully.

A deliberate decision to keep a workload in its current environment because migration is blocked by latency, regulation, licensing, or cost. Retained workloads still need a review date.

Decommissioning a workload that is no longer needed, removing it from the migration scope entirely. Retiring first reduces cost and complexity for everything that follows.

A grouped set of workloads scheduled to migrate together in one phase, chosen by dependency, risk, and business calendar. Waves sequence the program and give teams a repeatable unit of delivery.

A structured inventory and analysis of all applications covering business criticality, technology stack, ownership, cost, usage, and technical debt. Its output drives the 6 Rs assignment and wave planning.

Identifying the connections between applications, databases, network flows, and users so migration order and cutover grouping respect real runtime relationships. Missed dependencies are a leading cause of failed cutovers.

The full lifetime cost of running a workload, including compute, storage, network egress, licensing, support, staffing, and tooling. Comparing TCO before and after migration justifies the business case.

The study of how cloud pricing models such as pay-as-you-go, reserved capacity, and spot change cost behavior compared with capital purchase. It underpins sizing, commitment, and architecture decisions.

A review of an organization's technical estate, skills, processes, security posture, and governance against cloud requirements, producing a gap list and remediation plan before migration begins.

A pre-provisioned, governed cloud environment with accounts, networking, identity, logging, security controls, and guardrails that migrated workloads can be deployed into consistently and repeatedly.

A policy or technical control that constrains what can be deployed in a cloud environment, such as region restrictions or required encryption. Guardrails prevent risky configurations without blocking legitimate work.

Defining cloud networks, compute, and policies in version-controlled template files that tools deploy automatically. It makes environments reproducible, reviewable, and consistent across migration waves.

Expressing governance rules as machine-readable definitions that are evaluated automatically during deployment. Violations are detected or blocked before resources exist, replacing manual review.

An informal name for moving workloads to cloud with minimal modification, usually as virtual machines. It is a common first step that later enables optimization once workloads are stable.

An industrialized team and toolchain that migrates workloads in repeatable batches using standard templates, automated runbooks, and shared roles. It trades bespoke handling for speed and consistency.

Moving data from source systems to target cloud storage or databases while preserving integrity, completeness, and acceptable freshness. It includes extraction, transfer, transformation, loading, and reconciliation.

A technique that reads a source database's transaction log and streams only changed rows to the target. It keeps the target current during migration and shortens the final cutover window.

Comparing source and target data after transfer using row counts, checksums, and business totals to prove nothing was lost, duplicated, or corrupted. It is a required gate before cutover.

Translating database objects such as tables, indexes, procedures, and data types from a source engine's dialect to the target engine's. Incompatible constructs must be rewritten or manually remediated.

A migration between different platforms or engines, for example from one database vendor to another or from one hypervisor to another. It requires conversion and typically more testing than a like-for-like move.

The planned event when production traffic and data move from the old environment to the new one and the old system stops serving users. It is scheduled, rehearsed, and reversible.

A documented, tested procedure to return to the source environment if cutover fails or validation thresholds are not met. It defines triggers, decision owners, and time limits.

A step-by-step operational procedure with commands, owners, timings, and checkpoints used to execute a migration or cutover consistently. Runbooks are rehearsed and version-controlled.

Post-migration checks confirming that functionality, performance, security, and data integrity meet agreed acceptance criteria. Results determine whether cutover is declared successful or rolled back.

Measured pre-migration values for latency, throughput, and resource use that serve as the reference for judging whether the migrated workload performs acceptably. It must be captured before changes begin.

Matching provisioned compute, memory, and storage to actual measured demand rather than copying legacy over-provisioning. It is the fastest source of post-migration cost savings.

An operating practice where finance, engineering, and business teams share accountability for cloud spend through visibility, forecasting, and continuous optimization. It makes cost a first-class engineering concern.

Attaching structured key-value metadata to cloud resources to record owner, environment, cost center, and application. Consistent tags enable cost allocation, automation, and governance reporting.

A purchasing commitment to use a defined amount of compute for a term in exchange for a lower rate than on-demand pricing. It suits steady workloads but creates waste if usage drops.

A cross-functional team that defines cloud standards, builds shared platforms and guardrails, and coaches delivery teams. It centralizes expertise without centralizing all delivery work.

An environment combining on-premises or private infrastructure with public cloud, connected by secure networking and consistent identity. It is common during long migrations and for retained workloads.

The capability to restore applications and data after a failure, defined by recovery time and recovery point objectives. Cloud patterns such as pilot light and warm standby reduce recovery cost and time.