Skip to main content

​
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: 
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...
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 for details.

​
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:
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.

​
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
Workload migration inside cluster example

Multi-Cloud Support

Deploy and manage workloads across multiple clouds at once.

Security

How your credentials and data are protected during migration.