You shouldn't need to go through the trouble to back up and restore the site collection. There is a Powershell function called 'Move-SPSite' which will do that as well. It will also automatically writelock the site collection in question while it's moving it.
The biggest issue with this is that the Powershell functions start to fail when your site collections get extra-large (I think ~75GB is the absolute upper limit but because you need IIRC 2-3 times the memory available for the site in your RAM and pagefile, more than ~20GB is a more practical limit). The only way I know of to get around that is to split off some of the subwebs in a given site collection into their own site collections, which requires you to do the following:
Export-SPWeb on the subsite in question and save the .cmp files somewhere.
- Create a brand new site collection named whatever you want.
- If the site collection in question has an esoteric web template (like an Access Services template) you may need to create a leaf that utilizes that as well, as
Export-SPWeb will not export to a different template.
Import-SPWeb on the subsite and bring it into the site collection.
- Perform the
Move-SPSite as you would have before.
- Once you're 100% positive everything is running correctly, delete the subsite from the original (since the whole point of this exercise is to lower the size of the site collection).
The downside to this is that URLs are going to change. You can always put them back when you're done, but you want to make 100% sure that you have everything you need in that exported SPWeb object because there's no going back (save pulling old DBs from your archive, assuming you have SQL backups).
ETA: To your follow-up comment: If they're still a lot of separate site collections, you can still run the backup/restore deal I mentioned above. One thing you might want to do beforehand is run this command:
stsadm -o enumsites -url http://yourwebapp.com >> d:\siteinfo.xml
This should pop out an XML file which will contain a lot of data about each site collection: its size, site collection owners, and so on. You can then open that file in, say, Excel, and devise a plan to move those collections out to their own content DBs. Keeping the new content DBs below 100GB and maybe ideally around 75GB is a good rule of thumb.
This whole process can take some time to do as well so you may need to deploy it in stages.