That's right, you might just be trying to move the volumes in an SVM to a different node. You can do that non-disruptively with the volume move start command, or by right-clicking in System Manager and choosing Move. The only disruption would be a brief one for volumes used in a CIFS server during cutover.
There aren't any special considerations per se for the root volume other than availability and proximity to your data volumes. If you have a aggregate that's prone to going inconsistent or in danger of filling up, you probably don't want to put your SVM root there because your namespace/junction path for the SVM will go offline when you lose access to the aggregate. Figure out what node/aggregate is going to store the data volumes and co-locate your root with them. Then you can retire the nodes/aggregates that currently host the SVM root volume without disruption.
There's lots of healthy debate out there about indirect I/O (i.e. the LIF serving the data isn't on the node/aggregate hosting the data - data traffic crosses the cluster network) but rather than getting into that whole can of worms, make sure you relocate your data LIF off to the node/aggregate you're moving the data to as well. Don't want to get everything migrated over to other nodes in your cluster and then shut down the HA pair that hosts your LIF. All operations have proven to be non-disruptive for us (pay attention to the previous poster concerning CIFS).
NFS LIFs would need to be migrated, ISCSI LIFs cannot be migrated - you will need to take them offline, but access should continue over the new LIFs due to ALUA.
If you have not tested this functionality inside your environment, I cannot give you assurances that this will be non-disruptive, as it requires network connectivity to be correct, but it usually is - your best course of action would be to setup a test SVM, with new LIFs on both the old and new nodes, create a new datastore and map it, then test the activity with that.
Yes, SVM root volumes will need to be moved to surviving nodes, and this will be non-disruptive.