Acumatica Upgrades - Sandbox and Post Upgrade Support

  • 28 July 2021
  • 2 replies
  • 78 views

Hello!

Would just like to ask for your experience in the Acumatica upgrades specifically in the preparation of the Sandbox environment, testing and post-upgrade activities.

Does your team perform the stated activities or is it your Acumatica Partner who does it for you?

We only have the standard Acumatica workflows and with simple customizations.

I am not a developer so I am not sure if I can manage the sandbox setup and testing activities up to the actual upgrade.


2 replies

Userlevel 2
Badge +1

I have been through several upgrades, and I’m a developer.  Our sysadmin just applies new minor patches to a QA instance and then pushes to all our other instances if it goes well.  Production, of course, being the last so we have several test runs first.  Major version upgrades are something very different for us than the minor patches.

I do the initial upgrade because I usually have to tweak something in our custom code for the new major release.  For upgrades, I always start with a new DEV instance on my local machine, including a Dev license of MS SQL.  These are the rough steps I go through.

First a disclaimer:  I’m a developer and a customer.  We have a relatively small support team, but we are efficient.  Our customizations are somewhat extensive, but we know them inside and out as we wrote them all.  We worked with our VAR to do all our own configurations to setup our instance.  ISV’s likely have more steps and have different focuses since they have to support many clients with upgrades.  VAR’s also have to support many installations, so they may have more sophisticated checklists.  This is all off the top of my head thinking back to our last upgrade and the one we currently have in-process.  Come to think of it, there probably is an official upgrade checklist somewhere in the Acumatica help!

Preparation

  • Install the same version we currently run currently and put a fresh snapshot of our data on it.  This requires publishing our customization projects to push database schema changes.
  • Apply the most recent snapshot from production.  I often develop with a “Sales Demo” tenant, but I am authorized for using production data to do the initial tests.  Real data for this testing phase is important to ensure our setups don’t run into any issues.
  • Re-apply our customization projects.  In the process, I ensure that I can still connect to the source code in the extension library of each project because I will need to compile a fresh DLL to update the project version.

Upgrade

Once I am confident that we could run on this instance if we had to, I begin the actual upgrade.

  • Unpublish all customization projects.
  • Download and install the desired version of Acumatica ERP.
  • Using the ERP Configuration tool that was just installed, upgrade the database and application from the “Application Maintenance” screen.
  • Upon completion, login to the instance.
  • Attempt to republish the customization projects.  If this fails (as often happens for me with major releases) then I ensure all customization projects are unpublished.
  • Open my customization project (extension library) in Visual Studio and attempt to compile.  Structural changes from Acumatica appear pretty instantly as errors.  Most of the time, I can resolve these easily in an hour or two until I am able to get a clean compile.  (This has taken as little as 5 minutes on some version upgrades.)
  • IMPORTANT AND OFTEN OVERLOOKED - This is probably later than it should be in my process, and in truth, I tend to skim over the documents earlier but not in depth.  Be sure to review all release notes to identify any changes that may impact your use of the standard features or any of your customizations.
  • Test scenarios.  If you have any automated testing solutions, run them.  Try to break the system.  You should try using every part of the system as you normally would and also try breaking it with entries that may not be expected from normal users.
  • Make all necessary adjustments to your customizations to successfully pass your initial test phase.
  • Export all customization packages and send to the sysadmin (or save off if that is you) to apply to the next server in your environment.  We use a minimum of Dev/Sandbox, QA/Test, Training (for our trainers), and then Production.  This gives ample practice at basically everything before it makes it to production.

Honestly, it does not feel like nearly as much as it looks like on the page.  I’ve done a start to finish upgrade in 2 hours before.  Migrating to 2021R1, we bit off migrating all our automation steps to the new workflow engine, which has us spending weeks in configuration changes and testing, but our current delays to go-live with the 2021R1 upgrade really fall on some work needed on a new screen we are releasing at the same time.

I have been through several upgrades, and I’m a developer.  Our sysadmin just applies new minor patches to a QA instance and then pushes to all our other instances if it goes well.  Production, of course, being the last so we have several test runs first.  Major version upgrades are something very different for us than the minor patches.

I do the initial upgrade because I usually have to tweak something in our custom code for the new major release.  For upgrades, I always start with a new DEV instance on my local machine, including a Dev license of MS SQL.  These are the rough steps I go through.

First a disclaimer:  I’m a developer and a customer.  We have a relatively small support team, but we are efficient.  Our customizations are somewhat extensive, but we know them inside and out as we wrote them all.  We worked with our VAR to do all our own configurations to setup our instance.  ISV’s likely have more steps and have different focuses since they have to support many clients with upgrades.  VAR’s also have to support many installations, so they may have more sophisticated checklists.  This is all off the top of my head thinking back to our last upgrade and the one we currently have in-process.  Come to think of it, there probably is an official upgrade checklist somewhere in the Acumatica help!

Preparation

  • Install the same version we currently run currently and put a fresh snapshot of our data on it.  This requires publishing our customization projects to push database schema changes.
  • Apply the most recent snapshot from production.  I often develop with a “Sales Demo” tenant, but I am authorized for using production data to do the initial tests.  Real data for this testing phase is important to ensure our setups don’t run into any issues.
  • Re-apply our customization projects.  In the process, I ensure that I can still connect to the source code in the extension library of each project because I will need to compile a fresh DLL to update the project version.

Upgrade

Once I am confident that we could run on this instance if we had to, I begin the actual upgrade.

  • Unpublish all customization projects.
  • Download and install the desired version of Acumatica ERP.
  • Using the ERP Configuration tool that was just installed, upgrade the database and application from the “Application Maintenance” screen.
  • Upon completion, login to the instance.
  • Attempt to republish the customization projects.  If this fails (as often happens for me with major releases) then I ensure all customization projects are unpublished.
  • Open my customization project (extension library) in Visual Studio and attempt to compile.  Structural changes from Acumatica appear pretty instantly as errors.  Most of the time, I can resolve these easily in an hour or two until I am able to get a clean compile.  (This has taken as little as 5 minutes on some version upgrades.)
  • IMPORTANT AND OFTEN OVERLOOKED - This is probably later than it should be in my process, and in truth, I tend to skim over the documents earlier but not in depth.  Be sure to review all release notes to identify any changes that may impact your use of the standard features or any of your customizations.
  • Test scenarios.  If you have any automated testing solutions, run them.  Try to break the system.  You should try using every part of the system as you normally would and also try breaking it with entries that may not be expected from normal users.
  • Make all necessary adjustments to your customizations to successfully pass your initial test phase.
  • Export all customization packages and send to the sysadmin (or save off if that is you) to apply to the next server in your environment.  We use a minimum of Dev/Sandbox, QA/Test, Training (for our trainers), and then Production.  This gives ample practice at basically everything before it makes it to production.

Honestly, it does not feel like nearly as much as it looks like on the page.  I’ve done a start to finish upgrade in 2 hours before.  Migrating to 2021R1, we bit off migrating all our automation steps to the new workflow engine, which has us spending weeks in configuration changes and testing, but our current delays to go-live with the 2021R1 upgrade really fall on some work needed on a new screen we are releasing at the same time.

Hello!

This is very much appreciated.

Very clear and detailed. Will discuss this with our team and will map this into our initial activities that we drafted a few days ago.

Thank you very much.

Reply


About Acumatica ERP system
Acumatica Cloud ERP provides the best business management solution for transforming your company to thrive in the new digital economy. Built on a future-proof platform with open architecture for rapid integrations, scalability, and ease of use, Acumatica delivers unparalleled value to small and midmarket organizations. Connected Business. Delivered.
© 2008 — 2020  Acumatica, Inc. All rights reserved