Sage 100

The source data version 4.40.0.5 is higher than the target data version 0.0.0.0 The migration wizard will now exit."" Trying to migrate from MAS 90 4.40 to Sage 100 Premium 5.00.4. I seem to remember seeing something like this a while ago but I can't remember how it was corrected. I'm thinking somehow it may be permissions in SQL but all other tests I've run on them are fine. I checked the version number in the SY_System table and it is 5.00.4.0, so I'm just drawing a blank on where the migration utility it pulling this 0.0.0.0. Anyone else seen this one? They have mods but I have tried removing all modified files and still getting this.

I got around this by renaming the LINKS folder, doing the migration and conversion and then restoring the LINKS folder. That worked for a Premium installation with lots of extended solutions that where jamming up the migration process. Everything worked fine after those steps.

Sounds like you have a mod installed on 4.40.0.5 that's not on 5.00.4. Migration and Conversion hook into Sy_EnhancementModule, Sy_Enhancement, and Sy_ClassEnhancement. Here are some ways to deal with it the right way is whatever works: 1) On target system DFDM Sy_EnhancementModule and Sy_Enhancement and remove appropriate records. On SQL these are still pvx data files in Mas_System folder (not db) 2) What @KateKrueger said 3) Make a copy of source \mas90 folder, uninstall mods from there, make this the new source.

Hi @KateKrueger - that is something I always do for test migrations, didn't work this time. @AlnoorCassim I manually reinitialized those files instead of opening and removing records. I would think that amounts to the same thing. I also removed 4 mods from the copy I'm working with (FL, IT, PR & WO) because they don't, or can't, exist in 2013 Premium. The mods are BM-1005 and BM-1078. I have disabled them but I can't find any other way to uninstall them. The ES Control Center in Library Master doesn't offer anything in that regard. Maybe I should dig through SY0CTL as well.. Thanks for the great responses, BTW.

One other thing. The way Migration works in SQL is it always looks for the .M4T pvx data file with the same name before it looks for the SQL table. IOW look for a Sy_System.m4t in mas90\Mas_System folder. It's only supposed to be there temporarily until Sy_System table is set in Mas_System db. But there's a chance it didn't get removed and the Version in there is 0.0.0.0. If it's there rename it.

Hey Alnoor, thank you very much. I thought you were onto something, however that didn't fix it. SY_System is definitely there in MAS_SYSTEM, but when I rename it the darn thing comes back. So I ran Migrate.exe, watched to see when it gets recreated, and it happens just after I login to SQL server. So this time I deleted it right after that screen but then still get the error when I go to the next screen. Now there is no SY_System in the MAS_System folder but still the error. I'm now digging through other files that look suspicious. When it gets created in there it is a blank file, no data and no version number, just FYI.

As a postscript, hopefully, to this issue I will say that @AlnoorCassim was incredibly helpful, although some assembly was required. At least you got me thinking in the right direction, sir. If anyone else gets this issue I will include what I hope is the resolution, although as the client has gone dark on me I won't know if the resolution is totally effective until we actually do the migration. Warning, verbose dissertation ahead! Here's what I did: If you remember where we left off Mr. Cassim suggested I remove the SY_System file that might be in the MAS_System folder, where it shouldn't be, so the system would use the one in the MAS_SYSTEM database, where it should be looking for it. This didn't quite work as the migration program seemed to be recreating that file whenever I ran it - and even when I removed it immediately after it was created I still received the error. So flipping that logic on its head, if it is a old fashioned SY_System.m4t it wants - that's what I gave it. I edited the one it kept creating in the windows folder to look like one from a Standard/Advanced system with the same version number as the live system (5.00.4). With that in place it got past the spot of the error and asked for the Administrator password. Problem resolved I thought, then it said it couldn't find SY_Company. Same deal as with SY_System in that it was in the SQL DB and looked fine, only this time it was not in the MAS_SYSTEM folder. I recreated one manually anyway, and even though I worried about possibly creating a scenario where I might be chasing my own tail trying to create many system files, after SY_Company.m4t was in place it gave me the list of companies and seemed ready to begin the migration. On a bizarre twist; I made those changes over 2 days ago and even though I asked the client to stop the service on a server that he has denied me access to he has neither done it nor responded. As I'm sure many of you know the migration won't run if the service is running. Sigh.. Onward through the fog. Oh, one more note of thanks to Alnoor. I had another client I just happened to be doing a re-migration for from 4.40 Adv to 5.00 SQL and received a message that ""G/L Options is missing"". Sure enough I found an AR_Options file sitting there taunting me in the ARxxx folder. Removed it and all was well. Sorry to be so loquacious, but I thought it was important.