Hi digitmasters always dump and load the System Database too as it contains user security settings, currency rates, and a few other things.  Using a blank System Database can be problematic.

Hi Tim,

New version license info entered during installation, in load xxxsys, will this case an "older version found" error?

Hi

This process will not copy across any users if going to 2024.  Last I read there is currently no way to migrate to new server straight to 2024.

If you fo this you will have to manually recreate all the users, then import security groups and security authorisations.

In the past, users can back up their Sage 300 system setup by making a copy of the SITE folder located in the Shared Data folder. While this is still a necessary step, it alone will not be sufficient for restoring a security enhanced environment. At this time, there is no supported way of backing up and restoring a security enhanced environment. This is a known issue and Sage are working on new tools.

Im a thinking we have to migrate with Sage 2023 and then upgrade to 2024 on the existing server but I am still reading through documentation for this.

I am hoping I am wrong and someone can direct me to the correct process.

Thanks

Hi Stacy,

Wow, we have 36 users.

When Sage released this new version, they just conveniently "forgot/ignored" about user migration issue? I am speechless.

Hi Stacey Orrock and digitmasters when you install version 2024 and open Database Setup for the first, it goes through the same setup of the Vault databases and user migration/conversion as 2023 PU2-4.  Even when you install a 100% new site, you will note the first thing 2024 does is upgrade the ADMIN account after opening Database Setup for the first time using "admin/admin", transferring from a temporary SAM to the new SQL database (I imagine this unnecessary legacy architecture step will eventually be removed).  I've not upgraded a production site straight to 2024 but have upgrade a test site from 2022 to 2024 and my test accounts came across (unless I'm remembering differently).

@Digitmaster, setup your 2024 database setup with the same system database linked to the same company databases present in your 2027 system, install version 2024 and open database setup to do a test update - I'm almost certain it will be fine.

BTW I can only see wording here that supports the idea that users get upgraded as long as old version is v5.6 (2009/10) or later help.sage300.com/.../ReleaseNotes.htm

Let me preface this with, I have not researched or tested this fully.  Accsys have done the yards on this one by the look of it so their info is probably more accurate.  Its just I did this exact thing on the weekend.  In the end I manually recreated the 38 users, it was quicker than trouble shooting,less than 10 mins work.  The Vault and Store would just not create, but then I probably did the steps wrong.  I installed 2024 on the new server, copied across the company site and user like I would have normally and then tried to create the Store and Vault but by then realised I probably broke the Site folder(found the note on not being able to do this trick  - page 23 of the Sage300EnhancedSecurityForV2024.pdf).  So couldn't use that.   I kept getting weird messages that I had not assigned enough rights to create the dbs,  reinstalled 2024, and then worked through it like a normal site and it all worked fine(it was happy with the rights).  So I am unsure how to take a Sage lower site to a new server at this stage.    I think maybe Im going to install 2023 if I have to move servers when doing an upgrade.  Straight upgrades its fine, just when introducing a new server could be problematic.

You can't import the Users like the old days, as you have to have passwords set.  So I think I got myself in an infinite loop, went looking for the manuals, and all the 2024 install guides link to 2023.  So I think Sage need to get some better documentation in order.

So I think  if I do the following

• Move the folders
• Install Sage 2024
• Then I restore or db dump load data (I use restore when I have lots of views or stored procedures)

Should be good, will try this on the next one

Stacey

Hi Stacey, it probably doesn't take much to trip the upgrade/migration process up when it comes to the ISAM user accounts being moved into the new SQL database.  A site a decade or so old is going to have a lot of history in those ISAMs so until I get a chance to move an actual 2017 site to 2024 I'm not sure how flaky the process is with an older site - what you did sounds solid so I imagine I'll run into similar issues.  I actually have a copy of a production 2017 site with data going back to the early 2000's so it will be a good one to try when I get a chance this week.  I like your idea of going to 2023 first - I'll take a snapshot before I upgrade so I can roll back and try the 2023 PU4 step first before going to 2024 PU1.  I agree that not being able to import users now is a pain and cost me a lot of time upgrading security profiles for a 2023.3 site recently as the propagation process for changes is much slower now to with the read/write to SQL instead of ISAM.

Even importing User Authorisations is very slow, there's obviously a lot of changes going on.  My new phrase is going to be , "Oh you are moving servers"  it would be a great time to review your users and set them up from scratch and forget trying to upgrade the users.

The more I think about it the more I think the procedure needs to be to take a snapshot of the application VM right before opening Database Setup for the first time so we can have multiple attempts at upgrading the users, or have an easy chance to roll back and try a different version before everything gets added to SQL and things have gone too far