working and archive volumes

Nerrad_Bbew,

With virtual pools, all disk groups will have to be added to either pool A or pool B. If you have two different disk classes in a pool, tiering will be enabled.  With tiering, the data will write in at the lower speed tier disks and background tasks can migrate data to the performance tier based on some factors.

Your options would be;

First option: If you add the non-ssd disk group to a pool that has the ssd disk group they will then be tiering for volumes in that disk group.
You can set a preference per volume for tier affinity so if you want to make sure specific volumes never migrate up to performance tier then you can set the archive affinity on the volume.
 
Second option (I would recommend): If you instead want to migrate things so you have a performance only pool A and an archive tier only pool B that will remove tiering and simplify things where you will assign your volumes to your pools based on which disk speed you want.  Assuming you have enough space on the new disks you could create a second disk group in pool B that can fit all the data currently residing on that pools SSD disk group, then delete the SSD disk group. This will migrate the data off to the other disk group before the operation completes.  At that point you can use the now freed up SSDs to expand the SSD ADAPT in pool A or create a second SSD DG in pool A.
You cannot shrink an adapt, and instead would have to delete and recreate with a smaller size, so make sure you are committed to this design if you opt to put all the SSDs into one large adapt on pool A rather than creating a second adapt in the pool. Also, if you prefer you could hold back two of the SSDs from pool A and make an SSD read cache on pool B if you want to somewhat enhance the slower pool with the SSD read caching.  This does not help with writes though, just reads. 
 
3rd option is to delete all the disk groups (all data will be lost so must backup > reconfig > restore) you can re-configure with linear style which will make it so that each disk group is its own pool. Linear is very simplified so it cannot do tiering, snapshots, replication, and the performance monitoring is gone from the GUI. Just so you are aware, most people do not opt for linear. 

Let me know if this helps.

Nerrad_Bbew,

If you already had volumes on Pool A and added SAS drives as a second disk group to Pool A, it is likely that you already have data on the SAS drives because any new writes to any volumes on that pool would go to SAS. If you delete the SAS disk group from the pool, the system will automatically migrate the data from the disk group you are deleting to the remaining disk groups on the pool.

Regarding the second point, you can clone a volume from one pool to another within the ME (Management Engine), but this requires placing the volume offline, causing downtime. Due to this, cloning is typically used in very limited scenarios. Instead, if you need to migrate VMs or other things while keeping them up, it is recommended to create a new volume on the other pool and use OS tools to migrate the data from a volume on one pool to a volume on another pool. For example, in VMware, if you have the licensing for the feature, you can perform live migration of storage from one datastore to another. Similarly, other operating systems like Hyper-V should have similar functionality available.