Migrating PersistentVolume data in Kubernetes is one of those tasks that looks simple in theory and gets complicated fast in practice. Kubernetes storage migration is the process of moving PVC data from one StorageClass, storage backend, or provisioner to another — ideally without application downtime or data loss. Teams face this task when replacing a legacy CSI driver, moving from HDD-backed storage to NVMe, converting from in-tree provisioners to CSI, or adopting a disaggregated storage platform.
There is no kubectl migrate-pvc command. Every Kubernetes storage migration is a custom procedure assembled from available primitives: volume clones, snapshots, backup tools like Velero, or low-level rsync between mounted volumes. The absence of a built-in migration path is a recurring source of operational risk, especially when teams need to migrate databases or message queues under tight RTO requirements.
Why Kubernetes Storage Migration Happens
Teams trigger storage migrations for several recurring reasons:
CSI driver replacement. Moving from a deprecated in-tree provisioner (such as kubernetes.io/aws-ebs) to the CSI equivalent requires re-binding existing PVCs to the new provisioner. In some cases the underlying volume can be re-imported; in others the data must be copied.
Backend replacement. Replacing a slow or operationally expensive storage backend — Ceph, NFS, or a legacy SAN — with a higher-performance or simpler system requires full data movement.
Performance tier upgrade. Moving from HDD-backed storage to NVMe-backed StorageClasses to reduce latency for a database workload.
Topology change. Migrating from a single-zone deployment to a multi-zone setup, or from hyperconverged to disaggregated storage for Kubernetes.
Storage Migration Approaches Compared
| Method | Downtime required | Data safety | Complexity | Best for |
|---|---|---|---|---|
| PVC volume clone | Brief — pause app, clone, re-point | High — CSI-native copy | Low | Same-provisioner migrations, test env copies |
| Velero backup + restore | Varies — backup window required | High — snapshot-based | Medium | Cross-cluster, cross-region, DR migrations |
| rsync between volumes | Low — live sync possible | Medium — app must be quiesced at cutover | Medium-high | Cross-provisioner when clone is unavailable |
| Storage replication + cutover | Near-zero — async sync then flip | Highest — no data movement during cutover | High | Large volumes, zero-downtime requirements |
Table 1: Kubernetes storage migration method comparison
Migrating to NVMe-backed storage in Kubernetes? Simplyblock supports CSI-native PVC cloning for zero-copy volume copies, enabling low-risk storage migrations with a snapshot-before-cutover workflow. Learn about simplyblock PVC cloning →
PVC Cloning as a Migration Path
PVC cloning is the cleanest path when the source and destination provisioner are the same, or when the CSI driver explicitly supports cross-StorageClass cloning. A clone creates a new PVC that is an independent copy of the source at the moment the clone request is submitted.
The migration workflow with cloning:
- Quiesce or snapshot the source application
- Submit a clone PVC pointing to the new StorageClass
- Verify data integrity on the clone
- Update the Deployment or StatefulSet to reference the new PVC
- Delete the original PVC after confirming success
The key advantage is that the clone operation happens at the storage layer — no data traverses the Kubernetes node’s CPU or network stack. This makes it fast and low-overhead compared to rsync approaches.
Velero and Snapshot-Based Migration
Velero is the most widely adopted tool for Kubernetes backup and migration. For storage migration, it works by taking a VolumeSnapshot of the source PVC, storing the snapshot in an object store, and restoring it to a new cluster or namespace with a different StorageClass.
This approach is particularly useful for cross-cluster and cross-region migrations. Its downside is that the restore creates the volume from the most recent snapshot, so any writes between the last snapshot and the cutover point are lost unless the application is stopped before the final snapshot.
For databases, Velero is often combined with an application-consistent snapshot hook that flushes writes before the volume snapshot is taken.
Migrating from In-Tree Provisioners to CSI
Kubernetes deprecated in-tree volume plugins (e.g., kubernetes.io/gce-pd, kubernetes.io/aws-ebs) in favor of out-of-tree CSI drivers. The in-tree to CSI migration feature, enabled by CSIMigration feature gates, transparently redirects existing PVs to the corresponding CSI driver without data movement.
This is the safest migration type because no data copying is required — the underlying storage object is the same, only the Kubernetes control path changes. Teams should verify that the feature gate is enabled for their specific provisioner and that the CSI driver version matches the expected API.
How Simplyblock Supports Storage Migrations
Simplyblock’s CSI driver supports PVC volume cloning via the standard dataSource field, enabling zero-copy clones within the simplyblock storage pool. Clones are created at the storage layer using copy-on-write semantics, so the operation completes quickly even for large volumes.
For teams migrating to simplyblock from another backend, the recommended path is:
- Take a CSI snapshot of the source PVC
- Use rsync or a Velero restore to populate a simplyblock-backed PVC
- Validate data integrity
- Update workload references to the new PVC
Simplyblock’s instant snapshot capability means the pre-migration snapshot step adds minimal overhead and provides a safe rollback point throughout the migration process.
Related Terms
These glossary pages cover the storage primitives and tools used in Kubernetes storage migration workflows.
- Zero-Copy Clone
- CSI Snapshot Architecture
- StorageClass
- PersistentVolumeClaim
- Disaggregated Storage for Kubernetes
Questions and Answers
How do you migrate PersistentVolume data in Kubernetes?
Kubernetes has no built-in migration command, so the approach depends on what the CSI driver supports and how much downtime is acceptable. The cleanest path for same-provisioner migrations is PVC cloning via the dataSource field, which creates a storage-layer copy without copying data through the node. For cross-provisioner migrations, teams typically use rsync between two mounted PVCs (with the application quiesced at cutover) or a Velero backup-and-restore workflow. For zero-downtime requirements, storage-level replication with a flip-and-cut approach has the lowest RTO.
Can you change the StorageClass of an existing PVC?
Not directly. The storageClassName field of a PVC is immutable after creation. To change a PVC’s StorageClass, you must create a new PVC with the desired class, copy the data, and update the workload to reference the new PVC. For StatefulSets, this means deleting and recreating the StatefulSet with updated volumeClaimTemplates, or patching the StatefulSet spec after manually creating the new PVCs.
What tools support Kubernetes storage migration?
The main tools are: Velero (backup/restore with VolumeSnapshot integration), the Kubernetes PVC cloning API (dataSource in PVC spec for CSI drivers that support it), manual rsync jobs run as Kubernetes Jobs with both PVCs mounted, and storage-native replication features offered by some CSI drivers. For in-tree to CSI migrations specifically, the CSIMigration feature gates handle the transition without data movement.
How do you migrate storage without downtime in Kubernetes?
Zero-downtime migration requires either PVC cloning (fast, CSI-native, brief quiesce for cutover) or storage-level replication with a cutover step. The general pattern is: snapshot the source for safety, begin async replication or initiate a clone, verify integrity on the destination, quiesce the application for the minimum time needed to flush writes, flip the workload to the new PVC, and resume. The quiesce window is typically seconds to low minutes for most workloads. Databases may require an application-consistent flush step before the final cutover snapshot.