Sage 100

Upgrading Sage 100 Premium from version 4.5 to 2016. Running the Parallel Migration Wizard and after the SQL database login screen (where we enter the SA password) it is giving SY_Migration failed with the following message: Unable to open one or more files. Setup will now exit. The only thing in the KB is about activate.pvx which I believe is okay because we can log into the 2016 installation. Any one have an idea to try? Thanks!

Have you tried re-propagating permissions on the Sage folder? (and all related folders , in COMMON FILES, etc... )

Might want to do the same on the source MAS90 folder as well

Kate, search this group for 'sy_migration failed'. @NancyHanson and @PhilMcIntosh posted about this problem.

@KateKrueger I am not sure of the error message I received but I remember failed migration attempts and the culprit was permissions on the SQL folder on the SQL server. It was not inside SQL but in the folder structure. I can dig a bit of you need me to.

I'm sure you're logged in with the appropriate rights but verify that you can access the \\servername\C$ admin share. I know we usually focus on the Sage folders we create and their share permissions, but because we're dealing with SQL then we need proper permissions to the C$ admin share folder. I recently tried a premium 2013 to premium 2016 upgrade and had to give up due to migration errors. Sage support was able to duplicate the problem but I don't have a fix as yet. If you call Sage support then reference this case number: CASE ID 8005400240 DEFECT_Failed Premium Parallel 2016.1 . Good luck.

Thanks for the help! I had seen where other 90minds users received this issue but they weren't the same error or situation. I tried what worked for them anyway but it didn't get me past this one. I will verify the security rights to all Sage folders and C$ and let you guys know!

This is the fix for the problems we had: ""We had to get permissions changed on the SQL server box to allow our user account to create entries in the log and backup folders for SQL."" This was pretty obscure and may not be your issue but might help.

I can't remember the error, but I had a problem with a Premium migration once where there was no room for the backup file on the old server. I'd also check the firewall to ensure the SQL port isn't being blocked.

You may want to run SQL profiler while you are running the Parallel Migration Wizard. This may tell you whether your issue is with accessing SQL server or accessing the file system.

We gave the MAS_USER account ultimate rights in SQL and now we get this error during the Parallel Migration Wizard: ""Error execute:sp_changedbowner @loginname = 'MAS_User'."" has anyone encountered that error before?

Can you specify what you mean by ""Ultimate rights"" ? being a dbowner on the MAS folder may not give it necessary permissions on the Master database, which is likely where the sp_changedbowner needs to write.

I always run the migration wizard as ""sa"" to prevent any kind of permission issues.

we granted all the rights possible under Security > Logins> Properties for both MAS_USER and the network account I'm using to run the Parallel migration wizard. We also set MAS_USER and the network account as db owners. That was for both for MAS_SYSTEM and MAS_XXX.

I agree about using the SA which we have been using when getting these errors. Made more difficult when IT won't give up the SA password so any time we want to test it, we have to have IT go into the server room and enter the password. grumble.

IT can actually give your user necessary rights to do this, but it requires a bit more know how. People usually use the sa, because it's the safe bet, though, as best practice, it's probably not the best way to go. Can you at least temporarily give the MAS_USER account the ""sysadmin"" role on the server? . then do your migration, then remove the sysadmin role...(assuming all other necessary permissions are there for Sage to operate).

I'd think the MAS_User account might be dropped / re-created by the migration wizard, so your permissions pre-migration might be dropped. If you have to use a non-SA account, I'd certainly go with sysadmin permissions if at all possible. I avoid using a Windows login so as to remove any possible domain policy issues.

Sage spent a few hours troubleshooting this on the client system before asking for the data and now they are testing it on their systems. I'll post the resolution when (if?) we get one!

I'm running my test migration now and am having fun of my own with an error similar to yours. Oh joy.

The problem is it doesn't put the .bak it creates in that location. Make the .bak files manually (MAS_SYSTEM and all MAS_XXX databases) and put them where the migration bug collection expects to find them and it should work. There is a KB that says to put them in the destination \MAS90 directory - that is WRONG!

Thanks Phil. I was just doing that as a test and can confirm making the backup files in the correct location (before migrating) does work to bypass my problem. It seems the xcopy doesn't work properly, even when both instances are on the same machine.

I spoke too soon. It worked for MAS_System, but died on the company database. When I start to migrate again, I get Kate's error.

I'm so sad for you! Brian with Sage is still working on my client's data and I haven't heard anything since Wednesday. If you call in to Sage, reference Case # 8005430648. Maybe if there are two of us it will prioritize the resolution (right?...right?)

I'm trying a repair... then I have to start packing for Summit. It's always when there's no time that these things happen!

I'll be at summit as well! We can team up and find the responsible Sage people and encourage them to work on the ticket. Or we can drink enough to forget about the whole thing. I'm good either way. :-)

This is comical (migrating from 2013, PU4).

Sounds like a plan!

I was able to get past the SY_Migration error... Uninstall 2016 (saying no to the question about removing registry entries... just to be safe, and not affect the current 2013 system). Delete the MAS* databases from the new instance. Reinstall (with PU2 and enhancements). Set up the 2016 service again... Manual database backups from the source instance (MAS_SYSTEM and MAS_###) into the new instance's data directory. Running the migration again. *fingers crossed*

Did it successfully migrate?

Yes, it did. I had the SY_Migration error when connecting to the 2016 instance, so if that is where you get your error (instead of when connecting to the destination server) then you may want to try the above steps... After migration there was another error when doing the company data conversion though, but I don't know if that's related.