CloudCasa Kubernetes Migration Guide

CloudCasa migration jobs allow you to make a one-shot copy of a Kubernetes cluster, or part of a cluster. Typically, they might be used for migrating an application from one cluster to another, or a whole cluster from one cloud account to another, one cloud to another, or from on-prem to cloud or vice versa. They can also be used for migrating locally to a cluster with a new configuration.

Step 1 - Create an Account

First, create a CloudCasa account if you haven’t done so already. Just go to and select “Sign Up”. No payment information is required for the Free service plan. Once you’ve signed in, you can invite other people to join your organization under Configuration/Users.

Step 2 - Configure your AWS, Azure, and GCP accounts (optional)

If any of your Kubernetes clusters are running in AWS, Azure, or GCP, or if you intend to migrate to EKS, AKS, or GKE clusters, we recommend adding your cloud accounts under Configuration/Cloud Accounts. This allows CloudCasa to auto-discover your EKS, AKS, and GKE clusters, save EKS, AKS, and GKE cluster parameters, and auto-create migration target clusters. For some configurations, it also gives you the option of auto-installing the agent.

See also

For more information on adding cloud accounts, see Cloud Accounts.

Step 3 - Add your cluster(s)

You’ll need to add each cluster you wish to migrate to CloudCasa, if they haven’t been added already. Note that for migration you’ll need to add the clusters as CloudCasa Pro clusters, i.e. answer no to “Do you want to manage an existing Velero instance?”. If your clusters were auto-discovered, you’ll just need to find them in the Clusters list under your cloud account in Configuration/Cloud Accounts and click on the install icon for each one. If not, you can add them manually by clicking “Add cluster” under Clusters/Overview. Then enter your cluster name and description and click “Register cluster”. Either way, you will see a cluster ID and a kubectl command to run that will install a lightweight agent on the cluster. If you are installing the agent via our Helm chart or via a partner marketplace instead, make a note of the Cluster ID and follow the instructions specific to your preferred installation method. Once installed, the agent will connect to and register itself with the CloudCasa service, completing the process.

If you don’t wish to have CloudCasa auto-create a destination cluster for you, you will also need to add your destination cluster to CloudCasa.

See also

For more information on adding clusters to CloudCasa, see Adding a CloudCasa Pro cluster.

Step 4 - Define a migration job

Go to the Clusters/Migration page and click “Define Migration”. The cluster migration wizard will open. It has several steps. First, select the cluster you wish to migrate.

Next, choose what you wish to migrate. Various options are available to select resources by namespace, resource type, or label, and to include or exclude persistent volumes. The default is to migrate the full cluster, and either this or selected namespaces is what you should normally choose for migrations. The Advanced options section allows you to choose the location for temporary storage for the migration job, and to set several less commonly needed performance-related options.

Next select the destination cluster for the migration. You can choose a pre-existing cluster, or you can choose to create a new EKS, AKS, or GKE cluster.

See also

For more information on creating clusters with CloudCasa, see: Creating Clusters With CloudCasa.

Next choose any required restore transforms. For migration jobs, changing storage classes and preserving automatically assigned node ports are typically the most important.

Next you can select application hooks to execute before and after the migration. These are generally only needed for special applications, like databases, that need to be put in a specific state for backup.

See also

For more information on application hooks see App Hooks.

Finally, you will be presented with a summary of your selections and prompted to enter a name for the migration job. You can also enter optional tags to help identify it. Leave the “Run now” option enabled to start the migration job right away, or toggle it off so you can run it later.

See also

For more information on migration job creation, see Cluster Migration Wizard.

While the migration job is running, you can watch its progress on the dashboard status page.