I just got through a migration from SP2007 to SP2010 to SP2013.
Here's a few tips:
1) The recommended max size for a content DB on an average SQL DB Server is no more than 200 GB. If you're over, it may work, but expect it to take a long time.
a. Definitely consider splitting your content database up into smaller ones if it is larger than 200 GB. Each site collection should probably have its own content database. If you have one massive site collection, you will need to look at a way to split them up.
I've seen the web backup and restore method to a site collection with the same base site template and even a suggestion to copy the site collection and delete portions of it on one copy. Haven't tried those methods out yet to verify they work myself. However, I'm thinking about splitting up some content dbs I have that are well over 200 Gigabytes.
During my migration, the largest database migrated was 400 GB and it took several tries. On the final successful try, it took a few hours to run.
If you have smaller content databases, migrate your smaller content databases first. You can probably do up to three simultaneously from different powershell prompt windows with little issue if the databases are under 100 GigaBytes.
2) The percentage complete indicator provides no indication of how much time it will take to complete. For larger content databases, the percentage complete will tend to sit there and it will appear that your migration is stuck. However, there are ways to check whether it is really stuck.
a. The logs: c:\program files\common files\microsoft shared\web server extensions\14\logs (Substitute 14 with 15 for SP2013).
Unfortunately, when the migration script is busy running a script it stops writing to the logs for quite a while.
b. SQL Activity Monitor and SQL Profiler. These two tools that come with MS SQL 2012 and MS SQL 2014 are awesome for seeing what your migration is doing behind the scenes.
c. The migration script will run under the login name of the account that your command prompt or powershell prompt is running as, so you can filter for your user name.
d. From the SQL Activity Monitor, you'll be able to see all the processes that are connected to your SQL server. If you notice a lot of extraneous processes other than your Mount-SPContentDatabase, you probably should look at ways to reduce the connections to give more resources to the migration. Consider disabling the SP Timer service and IIS service while migrating. (Run a test on a smaller content db to see if migration works while these services are off to be sure.)
3) If possible you'll want to run your migration on an SQL server with plenty of RAM, CPUs, and HD space. When you upgrade a content database it will cause the db to grow and increase the size of you T-Log quite a bit. If you run out of HD space, your migration will fail or be corrupted.
a. Also note, that if you have a live SharePoint farm that you are trying to migrate to then your DB server is probably gonna be busy processing www requests. You can migrate your SharePoint databases to a standalone dedicated migration DB server if you have one.
Mount-SPContentDatabase -Name [Name] -WebApplication [Url to web app] -DatabaseServer [DBServer]
4) Beware of any Host Intrusion Protection system (HIPS) or Antivirus programs running on your SQL server or front end server. Those programs could inadvertently sabotage your migration. HIPS kept blocking some of the migration script queries on my SQL server incorrectly thinking they were an SQL injection attack.
5) Definitely do a rehearsal run of a few of your databases before doing the full migration if you've got a lot of content databases to migrate over.
Hope this helps!