> ## Documentation Index
> Fetch the complete documentation index at: https://docs.monk.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Workload Migration

> Seamless cross-cloud application migration

## What It Does

Running on AWS but want to switch to DigitalOcean? On GCP but need to move to Azure? Tell Monk to migrate your application. It handles the rest.

## How It Works

### The Migration Process

**Starting point:**

* Your application is running on Cloud A (e.g., AWS)
* Managed by Monk

**Migration steps:**

### 1. Request Migration

Chat with Monk in your [IDE](/features/vscode-integration):

```
You: Migrate this application to DigitalOcean
```

### 2. Provide Credentials

Monk asks for credentials to the target cloud provider:

```
Monk: I'll need DigitalOcean credentials to provision resources.
      Please provide your DigitalOcean API token.

You: [Provides token]

Monk: Credentials received. Analyzing current deployment...
```

<Info>
  Credentials are encrypted at rest in your IDE's secret storage and on your Monk cluster using your cloud provider's KMS. They are never sent to Monk servers and never exposed to the LLM. Monk needs these because everything runs on **your infrastructure** (Bring Your Own Infrastructure - BYOI). See [Security](/features/security) for details.
</Info>

### 3. Resource Provisioning

Monk provisions matching resources on the target cloud:

```
Monk: Current AWS infrastructure:
      - 2x t3.medium instances (API servers)
      - 2x t3.small instances (workers)
      - Application Load Balancer
      - VPC with security groups

Monk: Creating equivalent DigitalOcean resources:
      - 2x 2GB Droplets (API servers)
      - 2x 1GB Droplets (workers)
      - Load Balancer
      - VPC with firewall rules
```

Monk creates infrastructure that matches your current deployment, optimized for the target cloud's instance types and services.

### 4. Workload Transfer

Monk starts your application on the new cloud and stops it on the old one.

**What gets migrated:**

* [Containerized services](/features/containerization) - API servers, workers, background jobs
* Application code and [configuration](/features/configuration-and-wiring)
* [Container images](/features/containerization) - pushed to registry on new cloud
* [Networking configuration](/features/networking) - VPCs, security groups, load balancers
* External service connections - [APIs](/features/apis), [databases](/features/databases), [essential services](/features/essential-services)

<Warning>
  **Data migration is not yet supported.** Monk migrates workloads (containers, configuration, networking) but not database data. Managed services (RDS, Cloud SQL, etc.) remain on the original cloud. Self-hosted databases stay on original infrastructure. Your migrated application connects back to databases on the original cloud. Full data migration is coming soon.
</Warning>

### 5. DNS Switchover

If you're using a DNS provider (Route 53, Cloudflare DNS, etc.):

* Monk automatically updates DNS records to point to new infrastructure
* Traffic seamlessly shifts to new cloud
* Old workloads receive no new requests

If you're not using DNS managed by Monk:

* Monk provides new IP addresses/URLs
* You manually update DNS or load balancer configuration

### 6. Cleanup

After verifying everything works on the new cloud:

```
You: Delete the old AWS resources

Monk: Confirming: Delete all AWS resources for this application?
      - 4 instances
      - Load balancer
      - VPC and security groups

You: Yes

Monk: Deleting AWS resources... Done.
      Migration finished. Running entirely on DigitalOcean.
```

That's it. Your application is now running on the new cloud provider.

## Why Migrate?

**Cost savings:**

* Move from an expensive cloud to a cheaper alternative
* Switching providers often yields significant savings on compute costs

**Better services:**

* Access provider-specific features (AWS SageMaker, Azure OpenAI, GCP BigQuery)
* Use specialized hosting (Netlify, Vercel for frontends)

**Geographic expansion:**

* Add regions available on other cloud providers
* Better latency for global users

**Vendor diversification:**

* Reduce dependency on a single cloud provider
* Increase resilience with multi-cloud architecture

**Compliance:**

* Meet data residency requirements in specific regions
* Switch to providers with required certifications

<img src="https://mintcdn.com/monk-d20f97b6/4uh6xa_xJHKn3irH/assets/migrate_cluster_workload.gif?s=2ad7c05d683070429c1e7a43ff2cffd0" alt="Workload migration inside cluster example" height="200" className="rounded-lg" data-path="assets/migrate_cluster_workload.gif" />

## Related Features

<CardGroup cols={2}>
  <Card title="Multi-Cloud Support" icon="cloud" href="/features/multi-cloud">
    Deploy and manage workloads across multiple clouds at once.
  </Card>

  <Card title="Security" icon="lock" href="/features/security">
    How your credentials and data are protected during migration.
  </Card>
</CardGroup>