Cloud Migration Glossary

The broader work of updating legacy applications-via refactor, replatform, or replacement-to exploit cloud capabilities and reduce technical debt.

Intentionally limiting migration traffic so it doesn’t saturate links and degrade business-critical network use.

Migrating and modernizing within the constraints of existing systems, integrations, and processes, often in complex enterprise estates.

The key reasons for migrating-such as data-center exit, cost reduction, agility, resilience, or AI/analytics-which shape priorities and strategy.

Reusing existing software licenses in the cloud under approved terms instead of buying entirely new subscriptions.

Sending a small percentage of traffic to the new cloud environment first, watching metrics, and then ramping up if everything looks healthy.

Capturing inserts, updates, and deletes on the source and applying them to the target, enabling near-real-time sync during migration.

Allocating cloud costs to teams or products based on usage, often introduced after migration so business owners see and manage their consumption.

The broader shift where an organization standardizes on cloud for new and existing workloads, including changes to tooling, processes, skills, and governance-not just “moving servers.”

A prescriptive set of best practices and phases (strategy, plan, ready, adopt, govern, manage) for structuring migration and ongoing cloud operations (AWS, Azure, and GCP all publish one).

A central team that sets standards, builds shared tooling, and supports other teams through migration and ongoing cloud adoption.

Moving applications, data, and IT infrastructure from on-premises or another provider into a target cloud, with or without changing the architecture. For example, taking a legacy ERP stack from a data center to AWS or Azure.

How teams, processes, and tools are organized to run workloads in cloud-covering operations, security, cost, and platform ownership-once migration is complete.

Evaluating technical, organizational, and compliance factors to determine how easily each workload can move to cloud and what changes it will need.

Replacing self-managed components with managed cloud services (databases, queues, object stores, monitoring) during or after migration to reduce ops overhead.

A phase where some components remain on-prem while others run in the cloud, connected through network links or integration services.

Checking how regulations like GDPR, HIPAA, or PCI DSS apply when workloads move to cloud and mapping those requirements to specific cloud controls.

Packaging applications and their dependencies into containers (e.g., Docker) so they can be moved and run consistently across environments, often as a modernization step during migration.

The point at which you switch users and traffic from the old environment to the new cloud environment, often during a controlled maintenance window.

The time slot allocated to execute migration changes and validation, during which the system may be partially or fully unavailable.

Moving data from existing systems into cloud storage and databases, often with transformation and validation along the way.

Legal and policy requirements that certain data remain within specific countries or regions, which drive region selection and tool choices during migration.

Comparing counts, checksums, and sampled records between source and target to confirm completeness and correctness after migration.

A private, high-bandwidth connection from your data center to the cloud (e.g., Direct Connect, ExpressRoute, Cloud Interconnect) used for large-scale or latency-sensitive migrations.

Visualizing how servers, apps, and databases talk to each other so you can group them into sensible migration waves and avoid breaking hidden integrations.

The complete inventory of applications, servers, databases, and services an organization runs today; the starting point for migration planning.

Scanning and analyzing environments to identify workloads, dependencies, usage patterns, and readiness for cloud, often using tools like Azure Migrate or AWS Migration Hub.

Charges for data leaving a cloud region or provider, which matter for analytics, DR, multi-cloud, and potential future repatriation.

Pipelines that extract data from source systems, transform it where needed, and load it into cloud data platforms; ELT pushes more of the transformation into the target.

The initial set of policies and standards (naming, tagging, security controls, quotas) applied across landing zones to keep migrations consistent and under control.

Building a brand-new cloud-native solution instead of migrating the existing system, then gradually moving users and data across.

Moving between different database engines (e.g., Oracle to PostgreSQL), often involving schema conversion, query rewrite, and thorough testing.

Moving a database to the same engine in the cloud (e.g., SQL Server on-prem to SQL Server in Azure) with largely compatible schema and features.

Secure, persistent network connections between on-premises and cloud (VPN, private circuits), enabling phased migrations and hybrid architectures.

A short, focused support period immediately after go-live where a dedicated team watches the migrated workload closely and fixes issues quickly.

Linking on-prem identity systems (e.g., AD, SSO) with cloud IAM so users can access migrated workloads with a single identity and consistent permissions.

Defining infrastructure (networks, VMs, databases, policies) in code so environments can be reproducibly built and modified in the cloud.

Moving workloads into Kubernetes clusters-either new or existing-often combining replatforming (containers) with refactoring over time.

A pre-designed, secure cloud foundation-covering accounts, networking, IAM, logging, and guardrails-that serves as the “home” for migrated workloads.

Understanding how added distance or extra network hops will affect response times when some components move to cloud but others stay on-prem.

A pragmatic approach where you first rehost to meet deadlines, then iteratively optimize and modernize once the workload is stable in the cloud.

Breaking a monolithic application into smaller, independently deployable services as part of a refactor-style migration.

A repeatable, “assembly-line” model for running many migrations in parallel using standard tools, templates, and teams (assessment, data, cutover, etc.), rather than treating each migration as a snowflake.

Credits, discounts, and professional services that cloud providers and partners offer to reduce upfront migration cost and de-risk large moves.

The end-to-end initiative covering strategy, assessment, planning, execution, and post-migration optimization across many applications, usually run as a multi-year program rather than a one-off project.

A detailed, step-by-step playbook for moving a specific workload, including preparation, data sync, cutover actions, validation, and rollback steps.

The chosen approach for each workload: rehost, relocate, replatform, refactor, repurchase, retire, or retain. Each trades speed, cost, and long-term benefits differently.

A planned group of workloads that are assessed, migrated, and cut over together, often chosen because they share dependencies or business owners.

Switching routing and DNS so that traffic flows to the new cloud environment instead of the old one.

Exporting data to physical devices provided by the cloud provider, shipping them, and having the provider load the data into cloud storage-useful for very large datasets or slow links.

Copying data over the network while systems stay mostly online, usually combined with ongoing sync to minimize outages.

A period where old and new environments run side-by-side so you can compare behavior and reduce cutover risk.

A team that builds and operates shared cloud platforms (landing zones, CI/CD, observability) so product teams can focus on business features rather than raw infrastructure.

The phase where you fix performance issues, modernize components, and tune costs after workloads have been successfully cut over.

Recreating an application from scratch with new technology-often as a modern, cloud-native replacement for heavily constrained legacy systems.

Restructuring or rewriting an application to use cloud-native patterns (microservices, containers, serverless) for scalability, resilience, or speed of delivery.

Moving an application to cloud VMs with minimal changes, mostly recreating the server layout “as is.” It’s fast and lower risk, but doesn’t fully exploit cloud-native services.

Moving VMs at the hypervisor level into a managed virtualization stack in the cloud (e.g., VMware on AWS/Azure/GCP), keeping OS and apps the same.

Moving workloads to cloud while making small changes to use managed services or newer runtimes (e.g., managed databases, app services) without fully redesigning the app.

Swapping an existing application for a SaaS product or new platform—for example, replacing an on-prem CRM with Salesforce.

Leaving a workload in its current environment for now, often due to regulatory, latency, licensing, or timing constraints.

Decommissioning applications or servers that are no longer needed, simplifying the estate and freeing budget.

The financial gain realized from migration (savings, new revenue, faster delivery) relative to the cost of migrating and running in the cloud.

Adjusting instance sizes, storage, and service tiers in the target cloud to reflect actual usage rather than lifting on-prem overprovisioning.

Iteratively tuning instance types, storage classes, and pricing models (committed use, reserved instances) to reduce cloud run-rate once workloads are stable.

The controlled return of a workload to its original environment when a migration or cutover exposes unacceptable issues.

The transfer of responsibility from the migration project team to the steady-state operations or platform team, with documentation, dashboards, and SLIs in place.

Translating database objects and types from the source engine to the target engine, sometimes with automated tooling plus manual fixes.

The minimum set of security controls-identity, network segmentation, logging, encryption-that must be present in cloud before migrated workloads are allowed in.

Tightening access, patching, and enabling monitoring in the new cloud environment before exposing it to production traffic.

Shifting some logic or batch jobs into functions and managed workflows, reducing infrastructure management while migrating.

The principle that the cloud provider secures the underlying platform, while customers are responsible for securing their workloads, configuration, and data; migration plans must respect this split.

An encrypted tunnel over the internet linking on-prem networks with cloud VPCs/VNets, often used in early migration stages or smaller sites.

Gradually routing specific capabilities from a legacy system to new cloud services until the old system can be fully switched off.

Paying recurring fees for software or platforms delivered as a service, often replacing perpetual licenses used on-prem.

Comparing long-term cost of running workloads on-prem vs. in the cloud, including hardware, licenses, people, and migration effort.

A logical unit of business functionality (app + data + integrations) that can be planned, migrated, and operated as a group-for example, an e-commerce site or billing platform.

A migration approach that keeps the application available throughout by combining continuous data sync, parallel environments, and a very brief or transparent cutover.