What you say is correct - if you do a snapmirror initialize, a snapmirror break, then a cifs shares delete on the source and a cifs shares add on the destination, you have migrated the data and the share name is the same. BUT, your data is likely inconsistent, and you will still need to change scripts, etc. to access the new volume at the new host.
Do the snapmirror initialize, wait for it get into a snapmirrored state, remove the share on the source, and do a snapmirror update before the snapmirror break and creating the new share. This will take care of inconsistent data. You can do snapmirror updates without removing the source share, too. What I've done in the past is do an update, then another update as soon as the first finishes - this gives you the amount of time a final sync will take, and the amount of time the share will have to be down. Coming up to the window, keep doing updates so that when your window starts, you know that the final one will be about the same time. Then cifs shares delete, snapmirror update, snapmirror break, cifs shares add.
If your current shares are accessed by the controller hostname, you're going to need to change scripts to point to the new hostname. If you use DNS aliases, you can repoint DNS, but only if you're migrating ALL shares for that alias. You'll also need to set the cifs.netbios_aliases option - but again, only if you're using aliases, and only if you're migrating ALL the shares for that alias. If you're not using aliases, now is a good time to implement them, since you'll be changing all the configs anyways. Then next time you have to migrate, you won't have to worry about it!
Hope that helps
Bill