Application & Workload Migration

A workload migration moves an application and the infrastructure it depends on to a new environment.
Depending on the system, this can include virtual machines, databases, storage, middleware, networking, identity, integrations and operational tooling.
The destination can be public cloud, private cloud, another cloud provider or another supported infrastructure platform.

Rehost moves the workload with minimal architectural change. For example, an application running on virtual machines may move to equivalent cloud virtual machines.
Replatform makes limited changes during the move to use a more suitable target service. For example, a self-managed database may move to a managed database platform.
Microsoft describes rehost as the lower-change option, while replatform introduces selected platform improvements without requiring a full application rewrite.

It depends on the workload and migration objective.
Rehosting is often appropriate when speed, low change and a fixed deadline are the priority.
Replatforming can make sense when a component is outdated, expensive to operate or can move to a managed service with limited application changes.
We avoid replatforming simply because a cloud-native service exists. The expected operational or business benefit should justify the additional migration work.

Yes.
Applications and databases are often tightly connected, so their migration approach and cutover sequence need to be designed together.
Depending on the database and target, we can use replication, backup and restore, native migration tools or continuous data synchronization.
Before cutover, we validate data consistency and confirm that dependent applications can use the target database correctly. AWS also stresses that database synchronization and application dependencies can materially increase cutover complexity.

We group workloads based on technical dependencies, business criticality, complexity, common migration patterns and delivery capacity.
Applications that communicate closely or depend on shared databases and services may need to move in the same wave.
Independent workloads can be migrated separately or in parallel where the risk is acceptable.
Azure’s current wave-planning model follows the same approach, grouping applications around dependencies and business requirements, then sequencing them by criticality, complexity and migration impact.

We validate more than whether the application starts.
Testing can include application functionality, integrations, database access, performance, security, monitoring, backup and operational processes.
Where possible, the target workload is deployed and tested before production traffic is redirected.
Microsoft specifically recommends validating functionality and securing and automating the target workload before production cutover.

Critical workload migrations should have predefined success and rollback criteria.
Before cutover, we document checkpoints, decision owners and the technical steps required to either continue, fix forward or return traffic to the source environment.
For stateful applications, data changes after cutover need special attention because rollback can be more complex once the target has accepted new transactions. AWS recommends defining rollback triggers and data-handling strategy before the cutover starts.

If the workload has fundamental architecture, reliability or maintainability problems, simply moving it can carry those problems into the new environment.
In that case, we may recommend replatforming selected components or separating migration from a later modernization phase.
Microsoft explicitly warns that rehosting does not fix existing performance, reliability or architecture problems, while AWS recommends avoiding large-scale refactoring inside a migration program when it introduces too much delivery complexity.
For deeper redesign, the workload moves into our Legacy Modernization services rather than expanding the migration indefinitely.