Hey Cullen

I've had a similar experience, gone through multiple KBs and attempted various solutions, just like you have. The only way I was able to go live was to start from scratch. Backup the entire MAS90 folder, especially all the MAS90\Reports and MAS_XXX\Reports folders, with all the converted forms, then uninstalled 2022 completely, deleted the MAS_System and other company databases. Once everything was cleaned up, I reinstalled and remigrated, converted data, then restored the reports folders and any module\custom folders. That was the only way I could move forward, painful as it was, I was able to have the client up and running for the Monday morning go live fun.

Good luck.

John

Thanks John,

It didn't quite come to that, and thank goodness this client's IT administrator is smart and stubborn and wouldn't let it go. After the 6th attempt I had given up and decided sleep was the best solution (and Sage City). He stuck with it a bit longer and, since the other company's MAS_XXX database had already migrated successfully we assumed the problem was that Sage was doing something strange with the other, much larger, MAS_XXX database. So he just removed the database completely and after that the "re-migration" finally went through successfully.

I don't know if there is something Sage doesn't understand about MS SQL Databases, or if Microsoft is somehow making this deliberately difficult for Sage - but this process really should NOT be this difficult. 

Here is what it says in KB # 111959:

Option I:
Contact Sage Support for Program fix for Sage 100 Premium 2020 - 2022 [Well, we has already applied the HotFix] 
Option II:
Upgrade to Sage 100 2022 [We are on 2022.1]
Option III:
1. Create a manual backup of the MAS_System database to the \INSTANCENAME\MASSQL\DATA folder
through SQL Server Management Studio. [Tried that and several variations of that, except since we weren't migrating system files we were only concerned with one of the MAS_XXX databases]
2. Run the migration tool as Administrator. [Every time]
3. When prompted to overwrite the backup in the previously mentioned location, click Yes. [Yup]
Option IV:
1. Reinstall Sage 100 ERP 2021 base product. [Not sure if them mean 2022 base product, but I guess that would have next]
2. Run migration tool as Administrator [Of course]
3. Convert source data.
4. Install product updates as needed.

I guess we need to suggest an Option V:

Remove the target database that blows up and re-migrate.

Onward through the fog, as we used to say back in Austin, TX, back in the day 

Thanks John,

It didn't quite come to that, and thank goodness this client's IT administrator is smart and stubborn and wouldn't let it go. After the 6th attempt I had given up and decided sleep was the best solution (and Sage City). He stuck with it a bit longer and, since the other company's MAS_XXX database had already migrated successfully we assumed the problem was that Sage was doing something strange with the other, much larger, MAS_XXX database. So he just removed the database completely and after that the "re-migration" finally went through successfully.

I don't know if there is something Sage doesn't understand about MS SQL Databases, or if Microsoft is somehow making this deliberately difficult for Sage - but this process really should NOT be this difficult. 

Here is what it says in KB # 111959:

Option I:
Contact Sage Support for Program fix for Sage 100 Premium 2020 - 2022 [Well, we has already applied the HotFix] 
Option II:
Upgrade to Sage 100 2022 [We are on 2022.1]
Option III:
1. Create a manual backup of the MAS_System database to the \INSTANCENAME\MASSQL\DATA folder
through SQL Server Management Studio. [Tried that and several variations of that, except since we weren't migrating system files we were only concerned with one of the MAS_XXX databases]
2. Run the migration tool as Administrator. [Every time]
3. When prompted to overwrite the backup in the previously mentioned location, click Yes. [Yup]
Option IV:
1. Reinstall Sage 100 ERP 2021 base product. [Not sure if them mean 2022 base product, but I guess that would have next]
2. Run migration tool as Administrator [Of course]
3. Convert source data.
4. Install product updates as needed.

I guess we need to suggest an Option V:

Remove the target database that blows up and re-migrate.

Onward through the fog, as we used to say back in Austin, TX, back in the day 

How did you make out?  I have had situations where permissions were different on some databases, especially if they were previously moved to a different location than the other databases due to size constraints.  There is also some articles regarding whether the master database has any processes in Killed/rollback state that could affect things as well.

Ended up deleting the target MAS_XXX database and the migration worked.

Glad you got through it and didn't need to blow away everything and start over. Good luck with the go live today.

Deleting the MAS_XXX database prior to migration is one of the next things I'm going to try too

I believe you must keep MAS_SYSTEM to be able to re-migrate ( this is an important database to have a SQL backup of)