Investigation: do storageclasses on statefulsets need to be considered during migration?

Question was raised in #forum-mig that could reveal an oversight in how we're handling statefulsets:

"The migration tool was able to migrate the statefulset application successfully and connect it to the new ceph pvc without any issues. However, within the statefulset, the storageclass was still specified as glusterfs block(unexpected?), even though that storage class is non-existent on the target namespace. Could this cause any issues in the future? Is there a way to change the statefulset storage class or do we have to do this manually?"

Definition of done: Let's put together a doc that describes the problems that could arise should the storageclass be left alone during a migration such that it's value points to a storageclass not even present on a target cluster.

When could this cause problems?

Is this something that could/should be handled with crane 2 transform?