Sage 100

Sage 100 2014 to 2017 Premium upgrade. Unable to migrate data, not even just system files after multiple attempts. v2014 is 2 servers, 1 SQL, 1 for Sage is on a separate domain than new Sage which also has 2 servers. Examples of Errors we get are ""Error Number: 0x80040E14 Cannot Open backup device, operating system error 5(acess denied)."" and ""Error Number:0x80040E4D, Invalid authorization specification setup will now terminate."" Sage took v2014 system files in house and says they were able to convert so its environmental. We also tried to do a manual migration sometimes called a merge and it also failed. The current suggestion from Sage is to set the two SQL instances windows services, log on tab to run under their respective domain administrator accounts.

You more than likely will have to setup trusts between the domains in order to get this to work.

Trust already exists.

Ensure that SQL service is not under 'local account'. I think that was my last headache when doing a SQL to SQL migration/upgrade

I believe the file copy of the .BAK file accesses the path through the C$ / D$ / E$... admin share. The source SQL service needs to be able to backup to that location on the destination server.

Hello Bruce, try manually creating full SQL backups on existing v2014 SQL server. Copy those .bak files to new SQL server. I've had to do this before too, but can't remember exact details - it's been a while. Believe the migration utility looks in local SQL Data directory for those .bak files and I had to copy them there. If I remember correctly, the utility stated couldn't find backups and specified path. Once those .bak files were found in the path migration proceeded without further incident. Hope this helps.

Things are coming back to me a little as I ponder this further. Wherever the .bak files are being created on the Source SQL server is where copies need to go on the Destination SQL server. If remember correctly (this is a brain tease), had to let the utility run again and create .bak's where it does on Source, but once it looked for them on Destination in same location it found cop(ies) and proceeded. Almost sure that's how it had to be done for me to complete the migration. That was version 2015, so may be a little different now.