Whenever possible set SQL services (source and destination) to use a domain account that has local admin permission to all servers involved.

Check for disk space, and verify that the migrated MAS_System files are where you expect.

We have domain admin rights.  Funny thing is we've been in testing mode for a month and everything was working fine until we tried to remigrate.

What does this mean?

Yes - and we did not use the "Default" SQL instance...created one called "Sage".

"Yes" does not describe what you meant by those words.

Name of the instance doesn't matter.

Does that database exist on the new instance already?  Removing it manually before the migration can help (in case there is an open connection, which would block the restore).

Sorry...misread your response.  The Sage company databased did not exist in the new instance.  Our testing consisted of 1 company (main company), but we are migrating more during our go-live.  The "cannot drop database" message appeared on the first company in the list "MAS_ARK".   

What does your reference to "local system" mean?

Did you check the disk space (and where MAS_System data files were stored)?

What does your reference to "local system" mean?

Did you check the disk space (and where MAS_System data files were stored)?

"Local System" - SQL Service of the new installation in running the instance as Local System Account.  Looks like that's the suggestion from the KB article 106142.

Plenty of disk space on all servers.  We are going to make another attempt with a clean install late afternoon today with some help from Sage.  Thanks for your help, Kevin.  Will let you know what comes up.

The migration tool works by copying the backup file to the hidden Admin shares (C$...), and restoring from there, so running the SQL Services using domain accounts having admin permissions to both machines helps for sure.  Running the migration program using a domain admin account is great, for the MAS90 folder copy... but the SQL databases are not copied between machines using those credentials.

If your server has multiple partitions, there used to be an issue where the migration tool might restore databases to the wrong one.  (When the SQL default data path was changed after the initial SQL install).  I don't know for sure if it has been fixed... but if you notice the MDF / LDF for MAS_System are on the wrong drive, that's the problem I'm referencing.

Good luck.

Sage provided a separate, updated set of Migration files and we were able to migrate successfully.