Tutorial: Kubernetes-Native Backup and Recovery With Stash

By Gcore

April 11, 2023

7 min read

Tutorial: Kubernetes-Native Backup and Recovery With Stash

Intro

Having a proper backup recovery plan is vital to any organization’s IT operation. However, when you begin to distribute workloads across data centers and regions, that process begins to become more and more complex. Container orchestration platforms such as Kubernetes have begun to ease this burden and enabled the management of distributed workloads in areas that were previously very challenging.

In this post, we are going to introduce you to a Kubernetes-native tool for taking backups of your disks, helping with the crucial recovery plan. Stash is a Restic Operator that accelerates the task of backing up and recovering your Kubernetes infrastructure. You can read more about the Operator Framework via this blog post.

How does Stash work?

Using Stash, you can backup Kubernetes volumes mounted in following types of workloads:

Deployment
DaemonSet
ReplicaSet
ReplicationController
StatefulSet

At the heart of Stash is a Kubernetes controller which uses Custom Resource Definition (CRD) to specify targets and behaviors of the backup and restore process in a Kubernetes native way. A simplified architecture of Stash is shown below:

Installing Stash

Using Helm 3

Stash can be installed via Helm using the chart from AppsCode Charts Repository. To install the chart with the release name stash-operator:

$ helm repo add appscode https://charts.appscode.com/stable/$ helm repo update$ helm search repo appscode/stash --version v0.9.0-rc.6NAME            CHART          VERSION      APP VERSION DESCRIPTIONappscode/stash  v0.9.0-rc.6    v0.9.0-rc.6  Stash by AppsCode - Backup your Kubernetes Volumes$ helm install stash-operator appscode/stash \  --version v0.9.0-rc.6 \  --namespace kube-system

Using YAML

If you prefer to not use Helm, you can generate YAMLs from Stash chart and deploy using kubectl:

$ helm repo add appscode https://charts.appscode.com/stable/$ helm repo update$ helm search repo appscode/stash --version v0.9.0-rc.6NAME            CHART VERSION APP VERSION DESCRIPTIONappscode/stash  v0.9.0-rc.6    v0.9.0-rc.6  Stash by AppsCode - Backup your Kubernetes Volumes$ helm template stash-operator appscode/stash \  --version v0.9.0-rc.6 \  --namespace kube-system \  --no-hooks | kubectl apply -f -

Installing on GKE Cluster

If you are installing Stash on a GKE cluster, you will need cluster admin permissions to install Stash operator. Run the following command to grant admin permission to the cluster.

$ kubectl create clusterrolebinding "cluster-admin-$(whoami)" \  --clusterrole=cluster-admin \  --user="$(gcloud config get-value core/account)"

In addition, if your GKE cluster is a private cluster, you will need to either add an additional firewall rule that allows master nodes access port 8443/tcp on worker nodes, or change the existing rule that allows access to ports 443/tcp and 10250/tcp to also allow access to port 8443/tcp. The procedure to add or modify firewall rules is described in the official GKE documentation for private clusters mentioned above.

Verify installation

To check if Stash operator pods have started, run the following command:

$ kubectl get pods --all-namespaces -l app=stash --watchNAMESPACE     NAME                              READY     STATUS    RESTARTS   AGEkube-system   stash-operator-859d6bdb56-m9br5   2/2       Running   2          5s

Once the operator pods are running, you can cancel the above command by typing Ctrl+C.

Now, to confirm CRD groups have been registered by the operator, run the following command:

$ kubectl get crd -l app=stashNAME                                 AGErecoveries.stash.appscode.com        5srepositories.stash.appscode.com      5srestics.stash.appscode.com           5s

With this, you are ready to take your first backup using Stash.

Configuring Auto Backup for Database

To keep everything isolated, we are going to use a separate namespace called demo throughout this tutorial.

$ kubectl create ns demonamespace/demo created

Prepare Backup Blueprint

We are going to use GCS Backend to store the backed up data. You can use any supported backend you prefer. You just have to configure Storage Secret and spec.backend section of BackupBlueprint to match with your backend. Visit here to learn which backends are supported by Stash and how to configure them.

For GCS backend, if the bucket does not exist, Stash needs Storage Object Admin role permissions to create the bucket. For more details, please check the following guide.

Create Storage Secret:

At first, let’s create a Storage Secret for the GCS backend,

$ echo -n 'changeit' > RESTIC_PASSWORD$ echo -n '<your-project-id>' > GOOGLE_PROJECT_ID$ mv downloaded-sa-json.key > GOOGLE_SERVICE_ACCOUNT_JSON_KEY$ kubectl create secret generic -n demo gcs-secret \    --from-file=./RESTIC_PASSWORD \    --from-file=./GOOGLE_PROJECT_ID \    --from-file=./GOOGLE_SERVICE_ACCOUNT_JSON_KEYsecret/gcs-secret created

Create BackupBlueprint:

Next, we have to create a BackupBlueprint CRD with a blueprint for Repository and BackupConfiguration object.

Below is the YAML of the BackupBlueprint object that we are going to create:

apiVersion: stash.appscode.com/v1beta1kind: BackupBlueprintmetadata:  name: postgres-backup-blueprintspec:  # ============== Blueprint for Repository ==========================  backend:    gcs:      bucket: appscode-qa      prefix: stash-backup/${TARGET_NAMESPACE}/${TARGET_APP_RESOURCE}/${TARGET_NAME}    storageSecretName: gcs-secret  # ============== Blueprint for BackupConfiguration =================  task:    name: postgres-backup-${TARGET_APP_VERSION}  schedule: "*/5 * * * *"  retentionPolicy:    name: 'keep-last-5'    keepLast: 5    prune: true

Note that we have used few variables (format: ${<variable name>}) in the spec.backend.gcs.prefix field. Stash will substitute these variables with values from the respective target. To learn which variables you can use in the prefix field, please visit here.

Let’s create the BackupBlueprint that we have shown above.

$ kubectl apply -f https://github.com/stashed/docs/raw/v0.9.0-rc.6/docs/examples/guides/latest/auto-backup/database/backupblueprint.yamlbackupblueprint.stash.appscode.com/postgres-backup-blueprint created

With this, automatic backup is configured for PostgreSQL database. We just have to add an annotation to the AppBinding of the targeted database.

Required Annotation for Auto-Backup Database:

You have to add the following annotation to the AppBinding CRD of the targeted database to enable backup for it:

stash.appscode.com/backup-blueprint: <BackupBlueprint name>

This annotation specifies the name of the BackupBlueprint object where a blueprint for Repository and BackupConfiguration has been defined.

Prepare Databases

Next, we are going to deploy two sample PostgreSQL databases of two different versions using KubeDB. We are going to backup these two databases using auto-backup.

Deploy First PostgreSQL Sample:

Below is the YAML of the first Postgres CRD:

apiVersion: kubedb.com/v1alpha1kind: Postgresmetadata:  name: sample-postgres-1  namespace: demospec:  version: "11.2"  storageType: Durable  storage:    storageClassName: "standard"    accessModes:    - ReadWriteOnce    resources:      requests:        storage: 1Gi  terminationPolicy: Delete

Let’s create the Postgres we have shown above:

$ kubectl apply -f https://github.com/stashed/docs/raw/v0.9.0-rc.6/docs/examples/guides/latest/auto-backup/database/sample-postgres-1.yamlpostgres.kubedb.com/sample-postgres-1 created

KubeDB will deploy a PostgreSQL database according to the above specification and it will create the necessary secrets and services to access the database. It will also create an AppBinding CRD that holds the necessary information to connect with the database.

Verify that an AppBinding has been created for this PostgreSQL sample:

$ kubectl get appbinding -n demoNAME                AGEsample-postgres-1   47s

If you view the YAML of this AppBinding, you will see it holds service and secret information. Stash uses this information to connect with the database.

$ kubectl get appbinding -n demo sample-postgres-1 -o yaml

apiVersion: appcatalog.appscode.com/v1alpha1kind: AppBindingmetadata:  name: sample-postgres-1  namespace: demo  ...spec:  clientConfig:    service:      name: sample-postgres-1      path: /      port: 5432      query: sslmode=disable      scheme: postgresql  secret:    name: sample-postgres-1-auth  secretTransforms:  - renameKey:      from: POSTGRES_USER      to: username  - renameKey:      from: POSTGRES_PASSWORD      to: password  type: kubedb.com/postgres  version: "11.2"

Deploy Second PostgreSQL Sample:

Below is the YAML of the second Postgres object:

apiVersion: kubedb.com/v1alpha1kind: Postgresmetadata:  name: sample-postgres-2  namespace: demospec:  version: "10.6-v2"  storageType: Durable  storage:    storageClassName: "standard"    accessModes:    - ReadWriteOnce    resources:      requests:        storage: 1Gi  terminationPolicy: Delete

Let’s create the Postgres we have shown above.

$ kubectl apply -f https://github.com/stashed/docs/raw/v0.9.0-rc.6/docs/examples/guides/latest/auto-backup/database/sample-postgres-2.yamlpostgres.kubedb.com/sample-postgres-2 created

Verify that an AppBinding has been created for this PostgreSQL database:

$ kubectl get appbinding -n demoNAME                AGEsample-postgres-1   2m49ssample-postgres-2   10s

Here, we can see AppBinding sample-postgres-2 has been created for our second PostgreSQL sample.

Backup

Next, we are going to add auto-backup specific annotation to the AppBinding of our desired database. Stash watches for AppBinding CRD. Once it finds an AppBinding with auto-backup annotation, it will create a Repository and a BackupConfiguration CRD according to respective BackupBlueprint. Then, rest of the backup process will proceed as normal database backup as described here.

Backup First PostgreSQL Sample

Let’s backup our first PostgreSQL sample using auto-backup.

Add Annotations:

At first, add the auto-backup specific annotation to the AppBinding sample-postgres-1:

$ kubectl annotate appbinding sample-postgres-1 -n demo --overwrite \  stash.appscode.com/backup-blueprint=postgres-backup-blueprint

Verify that the annotation has been added successfully:

$ kubectl get appbinding -n demo sample-postgres-1 -o yaml

apiVersion: appcatalog.appscode.com/v1alpha1kind: AppBindingmetadata:  annotations:    stash.appscode.com/backup-blueprint: postgres-backup-blueprint  name: sample-postgres-1  namespace: demo  ...spec:  clientConfig:    service:      name: sample-postgres-1      path: /      port: 5432      query: sslmode=disable      scheme: postgresql  secret:    name: sample-postgres-1-auth  secretTransforms:  - renameKey:      from: POSTGRES_USER      to: username  - renameKey:      from: POSTGRES_PASSWORD      to: password  type: kubedb.com/postgres  version: "11.2"

Following this, Stash will create a Repository and a BackupConfiguration CRD according to the blueprint.

Verify Repository:

Verify that the Repository has been created successfully by the following command:

$ kubectl get repository -n demoNAME                         INTEGRITY   SIZE   SNAPSHOT-COUNT   LAST-SUCCESSFUL-BACKUP   AGEpostgres-sample-postgres-1

If we view the YAML of this Repository, we are going to see that the variables ${TARGET_NAMESPACE}, ${TARGET_APP_RESOURCE} and ${TARGET_NAME} has been replaced by demo, postgres and sample-postgres-1 respectively.

$ kubectl get repository -n demo postgres-sample-postgres-1 -o yaml

apiVersion: stash.appscode.com/v1beta1kind: Repositorymetadata:  creationTimestamp: "2019-08-01T13:54:48Z"  finalizers:  - stash  generation: 1  name: postgres-sample-postgres-1  namespace: demo  resourceVersion: "50171"  selfLink: /apis/stash.appscode.com/v1beta1/namespaces/demo/repositories/postgres-sample-postgres-1  uid: ed49dde4-b463-11e9-a6a0-080027aded7espec:  backend:    gcs:      bucket: appscode-qa      prefix: stash-backup/demo/postgres/sample-postgres-1    storageSecretName: gcs-secret

Verify BackupConfiguration:

Verify that the BackupConfiguration CRD has been created by the following command:

$ kubectl get backupconfiguration -n demoNAME                         TASK                   SCHEDULE      PAUSED   AGEpostgres-sample-postgres-1   postgres-backup-11.2   */5 * * * *            3m39s

Notice the TASK field. It denotes that this backup will be performed using postgres-backup-11.2 task. We had specified postgres-backup-${TARGET_APP_VERSION} as task name in the BackupBlueprint. Here, the variable ${TARGET_APP_VERSION} has been substituted by the database version.

Let’s check the YAML of this BackupConfiguration.

$ kubectl get backupconfiguration -n demo postgres-sample-postgres-1 -o yaml

apiVersion: stash.appscode.com/v1beta1kind: BackupConfigurationmetadata:  creationTimestamp: "2019-08-01T13:54:48Z"  finalizers:  - stash.appscode.com  generation: 1  name: postgres-sample-postgres-1  namespace: demo  ownerReferences:  - apiVersion: v1    blockOwnerDeletion: false    kind: AppBinding    name: sample-postgres-1    uid: a799156e-b463-11e9-a6a0-080027aded7e  resourceVersion: "50170"  selfLink: /apis/stash.appscode.com/v1beta1/namespaces/demo/backupconfigurations/postgres-sample-postgres-1  uid: ed4bd257-b463-11e9-a6a0-080027aded7espec:  repository:    name: postgres-sample-postgres-1  retentionPolicy:    keepLast: 5    name: keep-last-5    prune: true  runtimeSettings: {}  schedule: '*/5 * * * *'  target:    ref:      apiVersion: v1      kind: AppBinding      name: sample-postgres-1  task:    name: postgres-backup-11.2  tempDir: {}

Notice that the spec.target.ref is pointing to the AppBinding sample-postgres-1 that we have just annotated with auto-backup annotation.

Wait for BackupSession:

Now, wait for the next backup schedule. Run the following command to watch BackupSession CRD:

$ watch -n 1 kubectl get backupsession -n demo -l=stash.appscode.com/backup-configuration=postgres-sample-postgres-1Every 1.0s: kubectl get backupsession -n demo -l=stash.appscode.com/backup-configuration=postgres-sample-postgres-1  workstation: Thu Aug  1 20:35:43 2019NAME                                    INVOKER-TYPE          INVOKER-NAME                 PHASE       AGEpostgres-sample-postgres-1-1564670101   BackupConfiguration   postgres-sample-postgres-1   Succeeded   42s

Note: Backup CronJob creates BackupSession CRD with the following label stash.appscode.com/backup-configuration=<BackupConfiguration crd name>. We can use this label to watch only the BackupSession of our desired BackupConfiguration.

Verify Backup:

When backup session is completed, Stash will update the respective Repository to reflect the latest state of backed up data.

Run the following command to check if a snapshot has been sent to the backend:

$ kubectl get repository -n demo postgres-sample-postgres-1NAME                         INTEGRITY   SIZE        SNAPSHOT-COUNT   LAST-SUCCESSFUL-BACKUP   AGEpostgres-sample-postgres-1   true        1.324 KiB   1                73s                      6m7s

If we navigate to stash-backup/demo/postgres/sample-postgres-1 directory of our GCS bucket, we are going to see that the snapshot has been stored there.

Backup Second Sample PostgreSQL

Now, lets backup our second PostgreSQL sample using the same BackupBlueprint we have used to backup the first PostgreSQL sample.

Add Annotations:

Add the auto backup specific annotation to AppBinding sample-postgres-2.

$ kubectl annotate appbinding sample-postgres-2 -n demo --overwrite \  stash.appscode.com/backup-blueprint=postgres-backup-blueprint

Verify Repository:

Verify that the Repository has been created successfully by the following command:

$ kubectl get repository -n demoNAME                         INTEGRITY   SIZE        SNAPSHOT-COUNT   LAST-SUCCESSFUL-BACKUP   AGEpostgres-sample-postgres-1   true        1.324 KiB   1                2m3s                     6m57spostgres-sample-postgres-2                                                                     15s

Here, repository postgres-sample-postgres-2 has been created for the second PostgreSQL sample.

If we view the YAML of this Repository, we will see that the variables ${TARGET_NAMESPACE}, ${TARGET_APP_RESOURCE} and ${TARGET_NAME} have been replaced by demo, postgres and sample-postgres-2 respectively.

$ kubectl get repository -n demo postgres-sample-postgres-2 -o yaml

apiVersion: stash.appscode.com/v1beta1kind: Repositorymetadata:  creationTimestamp: "2019-08-01T14:37:22Z"  finalizers:  - stash  generation: 1  name: postgres-sample-postgres-2  namespace: demo  resourceVersion: "56103"  selfLink: /apis/stash.appscode.com/v1beta1/namespaces/demo/repositories/postgres-sample-postgres-2  uid: df58523c-b469-11e9-a6a0-080027aded7espec:  backend:    gcs:      bucket: appscode-qa      prefix: stash-backup/demo/postgres/sample-postgres-2    storageSecretName: gcs-secret

Verify BackupConfiguration:

Verify that the BackupConfiguration CRD has been created by the following command:

$ kubectl get backupconfiguration -n demoNAME                         TASK                   SCHEDULE      PAUSED   AGEpostgres-sample-postgres-1   postgres-backup-11.2   */5 * * * *            7m52spostgres-sample-postgres-2   postgres-backup-10.6   */5 * * * *            70s

Again, notice the TASK field. This time, ${TARGET_APP_VERSION} has been replaced with 10.6 which is the database version of our second sample.

Wait for BackupSession:

Now, wait for the next backup schedule. Run the following command to watch BackupSession CRD:

$ watch -n 1 kubectl get backupsession -n demo -l=stash.appscode.com/backup-configuration=postgres-sample-postgres-2Every 1.0s: kubectl get backupsession -n demo -l=stash.appscode.com/backup-configuration=postgres-sample-postgres-2  workstation: Thu Aug  1 20:55:40 2019NAME                                    INVOKER-TYPE          INVOKER-NAME                 PHASE       AGEpostgres-sample-postgres-2-1564671303   BackupConfiguration   postgres-sample-postgres-2   Succeeded   37s

Verify Backup:

Run the following command to check if a snapshot has been sent to the backend:

$ kubectl get repository -n demo postgres-sample-postgres-2NAME                         INTEGRITY   SIZE        SNAPSHOT-COUNT   LAST-SUCCESSFUL-BACKUP   AGEpostgres-sample-postgres-2   true        1.324 KiB   1                52s                      19m

If we navigate to stash-backup/demo/postgres/sample-postgres-2 directory of our GCS bucket, we are going to see that the snapshot has been stored there.

Cleanup

To cleanup the Kubernetes resources created by this tutorial, run:

kubectl delete -n demo pg/sample-postgres-1kubectl delete -n demo pg/sample-postgres-2kubectl delete -n demo repository/postgres-sample-postgres-1kubectl delete -n demo repository/postgres-sample-postgres-2kubectl delete -n demo backupblueprint/postgres-backup-blueprint

Final thoughts

You’ve now gotten a deep dive into setting up a Kubernetes-native disaster recovery and backup solution with Stash. You can find a lot of really helpful information on their documentation site here. I hope you gained some educational knowledge from this post and will stay tuned for future tutorials!

What is cloud migration? Benefits, strategy, and best practices

Cloud migration is the process of transferring digital assets, such as data, applications, and IT resources, from on-premises data centers to cloud platforms, including public, private, hybrid, or multi-cloud environments. Organizations can reduce IT infrastructure costs by up to 30% through cloud migration, making this transition a critical business priority.The migration process involves six distinct approaches that organizations can choose based on their specific needs and technical requirements. These include rehosting (lift-and-shift), replatforming (making small changes), refactoring (redesigning applications for the cloud), repurchasing (switching to new cloud-based software), retiring (decommissioning old systems), and retaining (keeping some systems on-premises).Each approach offers different levels of complexity and potential benefits.Cloud migration follows a structured approach divided into key phases that ensure a successful transition. These phases typically involve planning and assessment, selecting cloud service providers, designing the target cloud architecture, migrating workloads, testing and validation, and optimization post-migration. Proper execution of these phases helps reduce risks and downtime during the migration process.The business advantages of cloud migration extend beyond simple cost reduction to include increased flexibility, improved performance, and enhanced security capabilities.Cloud environments also enable faster development cycles and provide better support for remote work and global collaboration.Understanding cloud migration is crucial for modern businesses, as downtime during migration can result in revenue losses averaging $5,600 per minute. Conversely, successful migrations can drive a competitive advantage through improved operational effectiveness and enhanced technological capabilities.What is cloud migration?Cloud migration is the process of moving digital assets, applications, data, and IT resources from on-premises infrastructure to cloud-based environments, which can include public, private, hybrid, or multi-cloud platforms. This planned shift allows organizations to replace traditional physical servers and data centers with flexible, internet-accessible computing resources hosted by cloud service providers. The migration process involves careful planning, assessment of existing systems, and systematic transfer of workloads to improve performance, reduce costs, and improve operational flexibility in modern IT environments.What are the types of cloud migration?Types of cloud migration refer to the different strategies and approaches organizations use to move their digital assets, applications, and data from on-premises infrastructure to cloud environments. The types of cloud migration are listed below.Rehosting: This approach moves applications to the cloud without making any changes to the code or architecture. Also known as "lift-and-shift," it's the fastest migration method and works well for applications that don't require immediate optimization.Replatforming: This plan involves making minor changes to applications during migration to take advantage of cloud benefits. Organizations might upgrade database versions or modify configurations while keeping the core architecture intact.Refactoring: This approach redesigns applications specifically for cloud-native architectures to increase cloud benefits. While more time-intensive, refactoring can improve performance by up to 50% and enable better flexibility and cost effectiveness.Repurchasing: This method replaces existing applications with cloud-based software-as-a-service (SaaS) solutions. Organizations switch from licensed software to subscription-based cloud alternatives that offer similar functionality.Retiring: This plan involves decommissioning applications that are no longer needed or useful. Organizations identify redundant or outdated systems and shut them down instead of migrating them to reduce costs and complexity.Retaining: This approach keeps certain applications on-premises due to compliance requirements, technical limitations, or business needs. Organizations maintain hybrid environments where some workloads remain in traditional data centers, while others migrate to the cloud.What are the phases of cloud migration?The phases of cloud migration refer to the structured stages organizations follow when moving their digital assets, applications, and IT resources from on-premises infrastructure to cloud environments. The phases of cloud migration are listed below.Planning and assessment: Organizations evaluate their current IT infrastructure, applications, and data to determine what can be migrated to the cloud. This phase includes identifying dependencies, assessing security requirements, and creating a detailed migration roadmap with timelines and resource allocation.Cloud provider selection: Teams research and compare different cloud service providers based on their specific technical requirements, compliance needs, and budget constraints. The selection process involves evaluating service offerings, pricing models, geographic availability, and support capabilities.Architecture design: IT teams design the target cloud environment, including network configurations, security controls, and resource allocation strategies. This phase involves creating detailed technical specifications for how applications and data will operate in the new cloud infrastructure.Migration execution: The actual transfer of applications, data, and workloads from on-premises systems to the cloud takes place during this phase. Organizations often migrate in phases, starting with less critical systems to reduce business disruption and risk.Testing and validation: Migrated systems undergo complete testing to ensure they function correctly in the cloud environment and meet performance requirements. This phase includes user acceptance testing, security validation, and performance benchmarking against pre-migration baselines.Optimization and monitoring: After successful migration, teams fine-tune cloud resources for cost-effectiveness and performance while establishing ongoing monitoring processes. This final phase focuses on right-sizing resources, using automated growing, and setting up alerting systems for continuous improvement.What are the benefits of cloud migration?The benefits of cloud migration refer to the advantages organizations gain when moving their digital assets, applications, and IT infrastructure from on-premises data centers to cloud environments. The benefits of cloud migration are listed below.Cost reduction: Organizations can reduce IT infrastructure costs by up to 30% through cloud migration by eliminating the need for physical hardware maintenance, cooling systems, and dedicated IT staff. The pay-as-you-use model means companies only pay for resources they actually consume, avoiding overprovisioning expenses.Improved flexibility: Cloud platforms enable businesses to scale resources up or down instantly in response to demand, eliminating the need for additional hardware purchases. This flexibility is particularly valuable during peak seasons or unexpected traffic spikes when traditional infrastructure would require weeks or months to expand.Enhanced performance: Applications often run faster in cloud environments due to optimized infrastructure and global content delivery networks. Refactoring applications for the cloud can improve performance by up to 50% compared to legacy on-premises systems.Better security: Cloud providers invest billions in security infrastructure, offering advanced threat detection, encryption, and compliance certifications that most organizations can't afford independently. Multi-layered security protocols and automatic updates protect against emerging threats more effectively than traditional IT setups.Increased accessibility: Cloud migration enables remote work and global collaboration by making applications and data accessible from anywhere with an internet connection. Teams can work on the same projects simultaneously, regardless of their physical location.Faster new idea: Cloud environments provide access to advanced technologies such as artificial intelligence, machine learning, and advanced analytics without requiring specialized hardware investments. Development teams can use new features and applications much faster than with traditional infrastructure.Automatic updates: Cloud platforms handle software updates, security patches, and system maintenance automatically, reducing the burden on internal IT teams. This ensures systems stay current with the latest features and security improvements without manual intervention.What are the challenges of cloud migration?Cloud migration challenges refer to the obstacles and difficulties organizations face when moving their digital assets, applications, and IT infrastructure from on-premises environments to cloud platforms. The challenges of cloud migration are listed below.Security and compliance risks: Moving sensitive data to cloud environments creates new security vulnerabilities and regulatory compliance concerns. Organizations must ensure that data protection standards are maintained throughout the migration process and that cloud configurations meet industry-specific requirements, such as HIPAA or GDPR.Legacy application compatibility: Older applications often weren't designed for cloud environments and may require significant modifications or complete rebuilds. This compatibility gap can lead to unexpected technical issues, extended timelines, and increased costs during the migration process.Downtime and business disruption: Migration activities can cause service interruptions that impact business operations and customer experience. Even brief outages can result in revenue losses, with downtime during cloud migration causing financial impacts averaging $5,600 per minute.Cost overruns and budget management: Initial cost estimates often fall short due to unexpected technical requirements, data transfer fees, and extended migration timelines. Organizations frequently underestimate the resources needed for testing, training, and post-migration optimization activities.Data transfer complexity: Moving large volumes of data to the cloud can be time-consuming and expensive, especially when dealing with bandwidth limitations. Network constraints and data transfer costs can greatly impact migration schedules and budgets.Skills and knowledge gaps: Cloud migration requires specialized expertise that many internal IT teams lack. Organizations often struggle to find qualified personnel or need to invest heavily in training existing staff on cloud technologies and best practices.Vendor lock-in concerns: Choosing specific cloud platforms can create dependencies that make future migrations difficult and expensive. Organizations worry about losing flexibility and negotiating power once their systems are deeply integrated with a particular cloud provider's services.How to create a cloud migration strategyYou create a cloud migration plan by assessing your current infrastructure, defining clear objectives, choosing the right migration approach, and planning the execution in phases with proper risk management.First, conduct a complete inventory of your current IT infrastructure, including applications, databases, storage systems, and network configurations. Document dependencies between systems, performance requirements, and compliance needs to understand what you're working with.Next, define your business objectives for the migration, such as cost reduction targets, performance improvements, or flexibility requirements. Set specific, measurable goals, such as reducing infrastructure costs by 25% or improving application response times by 40%.Then, evaluate and select your target cloud environment based on your requirements. Consider factors such as data residency rules, integration capabilities with existing systems, and whether a public, private, or hybrid cloud model best suits your needs.Choose the appropriate migration plan for each workload. Use lift-and-shift for simple applications that require quick migration, replatforming for applications that benefit from minor cloud optimizations, or refactoring for applications that can achieve significant performance improvements through cloud-native redesign.Create a detailed migration timeline with phases, starting with less critical applications as pilots. Plan for testing periods, rollback procedures, and staff training to ensure smooth transitions without disrupting business operations.Establish security and compliance frameworks for your cloud environment before migration begins. Set up identity management, data encryption, network security controls, and monitoring systems that meet your industry's regulatory requirements.Finally, develop a complete testing and validation plan that includes performance benchmarks, security assessments, and user acceptance criteria.Plan for post-migration optimization to fine-tune performance and costs once systems are running in the cloud. Start with a pilot migration of non-critical applications to validate your plan and identify potential issues before moving mission-critical systems.What are cloud migration tools and services?Cloud migration tools and services refer to the software platforms, applications, and professional services that help organizations move their digital assets from on-premises infrastructure to cloud environments. The cloud migration tools and services are listed below.Assessment and discovery tools: These tools scan existing IT infrastructure to identify applications, dependencies, and migration readiness. They create detailed inventories of current systems and recommend the best migration approach for each workload.Data migration services: Specialized platforms that transfer large volumes of data from on-premises storage to cloud environments with minimal downtime. These services often include data validation, encryption, and progress monitoring to ensure secure and complete transfers.Application migration platforms: Tools that help move applications to the cloud through automated lift-and-shift processes or guided refactoring. They handle compatibility issues and provide testing environments to validate application performance before going live.Database migration tools: Services designed to move databases between different environments while maintaining data integrity and reducing service interruptions. They support various database types and can handle schema conversions when moving between different database systems.Network migration solutions: Tools that establish secure connections between on-premises and cloud environments during the migration process. They manage bandwidth optimization, traffic routing, and ensure consistent network performance throughout the transition.Backup and disaster recovery services: Solutions that create secure copies of critical data and applications before migration begins. These services provide rollback capabilities and ensure business continuity if issues arise during the migration process.Migration management platforms: End-to-end orchestration tools that coordinate key factors of cloud migration projects. They provide project tracking, resource allocation, timeline management, and reporting capabilities for complex enterprise migrations.How long does cloud migration take?Cloud migration doesn't have a fixed timeline and can range from weeks to several years, depending on the complexity of your infrastructure and the migration plan. Simple lift-and-shift migrations of small applications might complete in 2-4 weeks, while complex enterprise transformations involving application refactoring can take 12-24 months or longer. The timeline depends on several key factors.Your chosen migration plan plays the biggest role. Rehosting existing applications takes much less time than refactoring them for cloud-native architectures. The size and complexity of your current infrastructure also matter greatly, as does the amount of data you're moving and the number of applications that need migration.Organizations typically see faster results when they break large migrations into smaller phases rather than attempting everything at once. This phased approach reduces risk and allows teams to learn from early migrations to improve later ones.Planning and assessment phases alone can take 2-8 weeks for enterprise environments, while the actual migration work varies widely based on your specific requirements and available resources.What are cloud migration best practices?Cloud migration best practices refer to the proven methods and strategies organizations follow to successfully move their digital assets from on-premises infrastructure to cloud environments. The cloud migration best practices are listed below.Assessment and planning: Conduct a complete inventory of your current IT infrastructure, applications, and data before starting migration. This assessment helps identify dependencies, security requirements, and the best migration plan for each workload.Choose the right migration plan: Select from six main approaches: rehosting (lift-and-shift), replatforming, refactoring, repurchasing, retiring, or retaining systems. Match each application to the most appropriate plan based on complexity, business value, and technical requirements.Start with low-risk workloads: Begin migration with non-critical applications and data that have minimal dependencies. This approach allows your team to gain experience and refine processes before moving mission-critical systems.Test thoroughly before going live: Run comprehensive testing in the cloud environment, including performance, security, and integration tests. Create rollback plans for each workload in case issues arise during or after migration.Monitor costs continuously: Set up cost monitoring and alerts from day one to avoid unexpected expenses. Cloud costs can escalate quickly without proper governance and resource management.Train your team: Provide cloud skills training for IT staff before and during migration. Teams need new expertise in cloud-native tools, security models, and cost optimization techniques.Plan for minimal downtime: Schedule migrations during low-usage periods and use techniques like blue-green deployments to reduce service interruptions. Downtime during cloud migration can cause revenue losses averaging $5,600 per minute.Use security from the start: Apply cloud security best practices, including encryption, access controls, and compliance frameworks appropriate for your industry. Cloud security models differ greatly from on-premises approaches.How does Gcore support cloud migration?When planning your cloud migration plan, having the right infrastructure foundation becomes critical for success. Gcore's global cloud infrastructure supports migration with 210+ points of presence worldwide and 30ms average latency, ensuring your applications maintain peak performance throughout the transition process.Our edge cloud services are designed to handle the complex demands of modern migration projects, from lift-and-shift operations to complete application refactoring beyond infrastructure reliability. Gcore addresses common migration challenges such as downtime risks and cost overruns by providing flexible resources that adapt to your specific migration timeline and requirements.With integrated CDN, edge computing, and AI infrastructure services, you can modernize your applications while maintaining the flexibility to use hybrid or multi-cloud strategies as your business needs evolve. Discover how Gcore's cloud infrastructure can support your migration plan. Frequently asked questionsCan I migrate to multiple clouds simultaneously?Yes, you can migrate to multiple clouds simultaneously using parallel migration strategies and multi-cloud management tools. This approach requires careful coordination to avoid resource conflicts and ensure consistent security policies across all target platforms.What happens to my data during cloud migration?Your data moves from your current servers to cloud infrastructure through secure, encrypted transfer protocols. During migration, data typically gets copied (not moved) first, so your original files remain intact until you verify the transfer completed successfully.Do I need to migrate everything to the cloud?No, you don't need to migrate everything to the cloud. Most successful organizations adopt a hybrid approach, keeping critical legacy systems on-premises while moving suitable workloads to cloud platforms. Only 45% of enterprise workloads are expected to be in the cloud by 2025, with many companies retaining key applications in their existing infrastructure.How do I minimize downtime during migration?Yes, you can reduce downtime during migration to under four hours using phased migration strategies, automated failover systems, and parallel environment testing. Plan migrations during low-traffic periods and maintain rollback procedures to ensure a quick recovery in the event of issues.Should I use a migration service provider?Yes, migration service providers reduce project complexity and risk by handling technical challenges that cause 70% of DIY migrations to exceed budget or timeline. These providers bring specialized expertise in cloud architecture, security compliance, and automated migration tools that most internal teams lack for large-scale enterprise migrations.