Been doing it a long time The only bit that I think I can usefully help with is to propose Best Practice because with experience that is most likely to succeed and/or least likely to cause side effects. The process is not as simple as "just copy over a file" I'm afraid ... and if you are not confident about it / understanding it, then it would be better to fall-back to a simpler process. For example, you might have longer down-time during the upgrade, but maybe for you that is not an issue - e.g. you can do it over a weekend and your users don't work then; most of my APPs are web based and in use 24/7, if we can get cut-over down to a few minutes we don't bother with scheduled maintenance we just put up a holding page explaining that the users need to wait 2 minutes and press RETRY and their session / State etc. will be preserved. We've upgraded database servers at the peak of a client's busiest period (told the client months before that their hardware was inadequate, but can't expect them to listen to good advice when the option is to pay extortionate emergency-fix fees instead!!)
Route 1 : Backup and Restore. This requires that you have enough disk space (preferably locally-ish to the SQL Server) to make a Full backup. You also need enough disk space for the ORIGINAL SIZED Data and Log files (and the backup ) on the new target server.
If your LOG file is wildly large the new server will reserve the same amount of space for it, as the old one did. You can NOT restore a database and specify a "smaller log", you will get the original sized one. So there is merit in shrinking the Log file before migrating the database, provided that the APP does NOT need a log file that big.
You don't need extra disk space to shrink the log - but you may do in order to back it up (but you can target the backup file anywhere that you have access to). If the disk is absolutely full then that may be preventing the database extending the file, but if that is the case no one will be able to access the database using the APP / Whatever.
Sounds like you may not have dedicated experienced folk looking after your database, so chances are probably high that the log is bigger than it needs to be.
It is also possible that you are NOT using FULL Recovery Model (the alternative is usually SIMPLE Recovery Model). It would help to know that. It is set per-database, not per-server. You can check that with this SQL code:
SELECT d.recovery_model_desc, d.name
FROM master.sys.databases AS D
ORDER BY D.[name]
The databases master, model, msdb and tempdb are system databases and you won't be copying those over (the new installation on the new server will create them)
If your database IS in Full Recovery Model AND you do not have scheduled Log Backups (or they are infrequent, such as once a day, then the Log file will grow continuously until a Log backup IS taken - thus it will be big.
If you take regular Log Backups but have a one-off huge transaction (such as deleting a whole load o old, stale, data once a year) then that one "huge" transaction may force the Log file to grow (you can program around that of course, deleting in batches whatever, but even the best managed offices have "huge transactions" (by accident, maybe!) once in a while. So you may have a regular huge transaction, or an infrequent, or even one-off, huge transaction. The answer is to shrink the log file, but you should not do that smaller than it needs to be - so you need tow ork out, reasonably accurately, what size that is.
If you database is running transaction logs and is NOT being backed up regularly, then you won't be able to shrink the file - it will be full already you can only shrink the unused-part on the end of the file. Answer to that is to deliberately take a Log Backup. You will probably have to take a second one before you can successfully shrink the log file (likelihood is that more transactions are added, but not committed, to the end of the file whilst the backup is running ... after the backup finished the front of the log file will be marked "empty" and new transactions will be written at the start of the file, not the end of it. Another backup will clear the stuff at the end of the file (provided that ALL transactions are committed ... leave it a little while maybe ...) and THEN you will be able to shrink the file.
Here's some SQL to see what backups have been made on your database recently.
SELECT MAX(b.backup_finish_date) AS BackupFinished,
d.recovery_model_desc as RecoveryModel
FROM master.sys.databases d
LEFT OUTER JOIN msdb.dbo.backupset b
ON d.name = b.database_name
GROUP BY d.name, b.type, d.recovery_model_desc
If your database is in SIMPLE Recovery Model you are only interested in Full (Type=D) and Differential (Type=I) backups, if it is FULL Recovery Model then Log backups (Type=L) are also important. (I often see Log Backups [on clients' servers] being scheduled for daily, or every hour, but there is very little to be lost by doing them, say, every 10 minutes and your average-worst-case disaster (i.e. a server failure, but not a jumbo jet crashing into the building!) will mean you can recover from your last Log backup - 10 minutes data lost is way better than an hour ... or a day
On my server I see Type=D Full backups on Sunday, a Type=I Differential backup for last night, and a Type=L Log Backup for sometime in the last 10 minutes.
For any database which has RecoveryModel=SIMPLE then you will only see Full and maybe Differential backups. Hopefully you have NO databases where the BackupFinished date is blank - that has never been backed up (or is being backed up by something outside SQL's control)
Letting us know what Recovery Model your database is, when it was last backed up, if you have a Log backup etc. will help us advise on your next steps.