Sage 100

It's not just you, @Wayne Schulz !

Typically I let the version I'm upgrading from as well as the new version until I do the next upgrade.  Then I delete the original version.  So I'll have a structure like you have above and when I add v2023, I'll delete the v2019 folder.  I don't usually uninstall it, though.

I recently found that uninstalling the older versions seemed to help when I was dealing with "Error: "The PVX Object init failed" or "Object ProvideX.Script is invalid" when installing Sage 100 Standard Workstation Setup, though.  When I uninstalled, I always left the most recent and the new version, though.  <o:p></o:p>

I just logged onto a client and realized I have used this trick a few times.  I create a new folder called "OK2Delete", then I move the old version into that folder, with a screen shot of where it was before the move.  And I let the IT Team know (or table a reminder for 30-days); and then go back and delete that new folder later.  My hope is that if there are issues in 30-days, it is a quick recovery.  But I don't ever use the "uninstall" for Sage versions.  

------------------------------
Madeline Stefanou
RKL eSolutions, LLC
------------------------------

I like to rename the activate.pvx on the old version to prevent anyone from accidentally accessing it.  Something like V2019Activate.pvx .  That way I can easily re-activate it should something require it.  But, yeah, leave it there for awhile.

We rename SY_User (to SY_User.M4T.disabled) during upgrades for the same reason: preventing accidental use of the old version (with it also preventing ODBC use too, since that needs to be authenticated, but doesn't use a license so not sure if the activate.pvx rename would block ODBC).  If we get a user complaint about "sy_user is not on file", we know the cause immediately: they are using the wrong shortcut.
(Of course that doesn't work on Premium, so we rename something else that's obvious / easy to rename back... e.g. pvxwin32.exe.disabled or MAS90_disabled...).

Renaming old folders for a while before deleting is something we do too.  Better safe than sorry.  (Never uninstall).

I like to rename the activate.pvx on the old version to prevent anyone from accidentally accessing it.  Something like V2019Activate.pvx .  That way I can easily re-activate it should something require it.  But, yeah, leave it there for awhile.

I create INSTLOCK.txt in the Home folder on the old versions. Gives the message "The Administrator is currently maintaining the system. Try again later."

We rename SY_User (to SY_User.M4T.disabled) during upgrades for the same reason: preventing accidental use of the old version (with it also preventing ODBC use too, since that needs to be authenticated, but doesn't use a license so not sure if the activate.pvx rename would block ODBC).  If we get a user complaint about "sy_user is not on file", we know the cause immediately: they are using the wrong shortcut.
(Of course that doesn't work on Premium, so we rename something else that's obvious / easy to rename back... e.g. pvxwin32.exe.disabled or MAS90_disabled...).

Renaming old folders for a while before deleting is something we do too.  Better safe than sorry.  (Never uninstall).

I like to rename the activate.pvx on the old version to prevent anyone from accidentally accessing it.  Something like V2019Activate.pvx .  That way I can easily re-activate it should something require it.  But, yeah, leave it there for awhile.

We have too many users who know how to remove the instlock.txt file (because we tell them to use that trick when they want to lock the system while working on things like period end reconciliations).

I create INSTLOCK.txt in the Home folder on the old versions. Gives the message "The Administrator is currently maintaining the system. Try again later."

We rename SY_User (to SY_User.M4T.disabled) during upgrades for the same reason: preventing accidental use of the old version (with it also preventing ODBC use too, since that needs to be authenticated, but doesn't use a license so not sure if the activate.pvx rename would block ODBC).  If we get a user complaint about "sy_user is not on file", we know the cause immediately: they are using the wrong shortcut.
(Of course that doesn't work on Premium, so we rename something else that's obvious / easy to rename back... e.g. pvxwin32.exe.disabled or MAS90_disabled...).

Renaming old folders for a while before deleting is something we do too.  Better safe than sorry.  (Never uninstall).

I like to rename the activate.pvx on the old version to prevent anyone from accidentally accessing it.  Something like V2019Activate.pvx .  That way I can easily re-activate it should something require it.  But, yeah, leave it there for awhile.

LOL @Kevin Moyes Gotta keep those secrets, SECRET!

We have too many users who know how to remove the instlock.txt file (because we tell them to use that trick when they want to lock the system while working on things like period end reconciliations).

I create INSTLOCK.txt in the Home folder on the old versions. Gives the message "The Administrator is currently maintaining the system. Try again later."

We rename SY_User (to SY_User.M4T.disabled) during upgrades for the same reason: preventing accidental use of the old version (with it also preventing ODBC use too, since that needs to be authenticated, but doesn't use a license so not sure if the activate.pvx rename would block ODBC).  If we get a user complaint about "sy_user is not on file", we know the cause immediately: they are using the wrong shortcut.
(Of course that doesn't work on Premium, so we rename something else that's obvious / easy to rename back... e.g. pvxwin32.exe.disabled or MAS90_disabled...).

Renaming old folders for a while before deleting is something we do too.  Better safe than sorry.  (Never uninstall).

I like to rename the activate.pvx on the old version to prevent anyone from accidentally accessing it.  Something like V2019Activate.pvx .  That way I can easily re-activate it should something require it.  But, yeah, leave it there for awhile.

I tend to leave things as they are..   Only if disk space is an issue do I really worry about it.   I have found that if you uninstall an older version you WILL have to reinstall the client for the new version as it almost always "breaks" it.   First couple of times that happened it freaked me out so out of an abundance of caution I tend to leave things alone.