It will be sufficient most of the time, but it is a good idea to open mydrupalsite.sql in text editor and scan it for old configurations. Especially if domain name also changes. Even if not, some modules needs may save things like local network addresses to data import sources et cetera.
And of course don't forget to truncate all cache tables and session table before data export. Best would be to disable cache and css/js aggregation on site before export, truncate tables, and re-enable these performance options on new site.
Alternatively, simply omit data from these tables when exporting with Backup and Migrate module or your favourite SQL client you use for export (for example, phpMyAdmin can do that, too). Of course disabling aggregation to have proper variables exported still needs to be done.
Safety note:
Truncating cache and session tables is only safe if you have put your site in maintenance mode. If you want to avoid it, you can't really truncate them, as they will be instantly re-populated and only effect will be performance hit and users logged out. In that case you need to omit that data, and make sure no one will change anything in the time of server switching, for the sake of consistency. Read only mode can help with that.
When talking about migration security - more modules equals more risk. My experience tells me that if your site is complicated one, you need to assume something will go wrong. So plan for it. Make sure you have time and manpower to fix it, no matter what exactly it is. Make sure you have enough old server paid for at least month after planned migration, so you can postpone and retry it. And make sure hosting company you are migrating away from will keep backups for you for at least 3 months.