Introduction

Kubernetes does not have a built-in "move this PVC to another storage class" command. The practical solution is to create a new PVC with the target storage class, mount both the source and destination into a helper pod, copy the data, verify it, and then cut the workload over to the new claim.

Create the Destination PVC First

Start by creating a new PVC that uses the target storage class and has enough capacity:

1apiVersion: v1
2kind: PersistentVolumeClaim
3metadata:
4  name: target-pvc
5spec:
6  accessModes:
7    - ReadWriteOnce
8  storageClassName: fast-ssd
9  resources:
10    requests:
11      storage: 20Gi

This new claim is the destination volume. It does not migrate anything by itself.

Use a Helper Pod That Mounts Both PVCs

The common migration pattern is a pod with both claims mounted:

1apiVersion: v1
2kind: Pod
3metadata:
4  name: pvc-copy
5spec:
6  restartPolicy: Never
7  containers:
8    - name: copier
9      image: alpine:3.20
10      command: ["/bin/sh", "-c", "sleep 3600"]
11      volumeMounts:
12        - name: source
13          mountPath: /source
14        - name: target
15          mountPath: /target
16  volumes:
17    - name: source
18      persistentVolumeClaim:
19        claimName: source-pvc
20    - name: target
21      persistentVolumeClaim:
22        claimName: target-pvc

Once the pod is running, you can exec into it and copy the data.

Copy the Data Safely

A simple copy can be enough:

kubectl exec -it pvc-copy -- sh
cp -a /source/. /target/

For larger or more sensitive migrations, rsync is often better because it preserves metadata more clearly and can be rerun incrementally:

rsync -aHAX /source/ /target/

The exact tool depends on what is available in the helper image and what metadata fidelity you need.

Think About Consistency Before Copying

The storage copy is easy. Application consistency is the harder part. If the source volume is still being written to while you copy it, the destination may be inconsistent.

Typical ways to handle this are:

• stop or scale down the writer workload
• put the application in maintenance mode
• use a snapshot-based workflow if the storage system supports it

If the data matters, consistency planning matters more than the copy command itself.

Verify Before Cutover

Do not switch the application immediately after copying without checking the result. At minimum:

• confirm file counts or directory structure
• spot-check important files
• verify ownership and permissions
• test the application against the new PVC

Only after verification should you update the workload to mount the new claim instead of the old one.

Cut Over the Workload

Once the new PVC is ready, change the deployment, StatefulSet, or other workload manifest to use target-pvc. Then bring the application back up and confirm it behaves correctly.

After that, keep the old PVC around until you are confident the migration succeeded. Deleting it immediately removes your easiest rollback path.

Common Pitfalls

• Expecting Kubernetes to migrate data automatically just because a new PVC uses a different storage class.
• Copying live data while the application is still writing to the source volume.
• Forgetting to verify permissions and ownership after the copy.
• Deleting the source PVC before testing the workload on the destination PVC.
• Ignoring access-mode and capacity differences between the old and new storage classes.

Summary

• Moving data between storage classes is usually a copy-and-cutover process, not an in-place PVC conversion.
• Create a destination PVC in the new storage class first.
• Mount both claims into a helper pod and copy the data.
• Plan for consistency before copying and verify before cutover.
• Keep the original PVC until the new one has been tested successfully.