By using this website, you agree to our Terms of Use (click here)
Hello, I was trying to look up a "best practice" when it comes to Apply Updates and when/if I should apply a minor version update. I didn't find anything really discussing this. I'd really like to hear what the community has to say! If, say, I am happily operating on 19.102.0051, should I update to 19.103.0030? When I update, what could I risk breaking as far as GIs, Dashboards, Reports, or Customizations? Any horror stories when a minor update wreaked havoc on a system you are involved with?
Well here in Australia MYOB applies minor updates without giving us an option! We had one go through last night (18.108.0016.193), no issues at all.
I would hope that with their policy of enforcing minor updates the risk of things going wrong should be minimal.
I totally agree with John. Make sure you have a good test script of things you test in the upgraded sandbox environment, then keep adding to that test script over time.
And ISV products really slow down your ability to keep up with updates. Just the way it goes.
Thank you for the good tips guys!
I need a recommendation: Do most businesses do their own Acumatica software "build" updates? Or do most businesses pay a VAR to do the Acumatica software "build" updates? What about for version updates such as going from 2020 R1 to 2020 R2?
Hey @doug-mcbride
I can't speak for everyone, but our company does the version updates self-sufficiently (we are an Acumatica customer running on prem). Usually we do not keep up with the minor updates unless there is a great need (such as Chrome iframe issue). I think it has more to do with what your internal team is capable of/has time for measured against impact of bugs than any other criteria for minor versions. For major releases, if you have setup and maintained any development environments, the upgrade process should be something you can handle internally. Though, if your system is sufficiently complex, i recommend working with your VAR. You can at least leverage them for project management skills if needed, and have them on standby in case you end up in the weeds.
This is my process for an On Premise Version upgrade:
Phase 1: Upgrade test instance
- Create a new instance on your test machine that is the same version as your production environment and point it to a copy of your production data (I usually use AcumaticaYYYYMMdd as instance Name).
- If you have access to them, make copy of IIS Site files.
- Any changes you made here will get overwritten during the upgrade process.
- If you made changes to .css files, you may need to update them after update (Example: Addition of [+New] button on menu items breaks .css between 2019 R1 and 2020 R1 versions).
- Mainly focused in these areas:
- App_Themes folder
- Content folder
- Icons folder
- Web.Config file
- Unpublish customizations.
- Perform any other maintenance tasks you discover if installation didn't go expected. Shouldn't have anything on your first go.
- Download/Install newest release of Acumatica install tool (that your 3rd party addons will handle. Coordinate with them).
- Upgrade your test instance to the new version.
- If you have any issues here, it is best to fix the issues and start over from the first step.
- If your customizations have any issues here, you will know about it if you did not unpublish them.
- Make notes because these are important to address during the real upgrade.
- Sigh of relief when it is completed.
Phase 2: Does it throw exceptions?
- Log into the instance.
- Make sure you disable scheduled tasks unless you are specifically testing them and understand the consequences.
- ***There is a potential to send test notifications or worse, exports, internally or to partners and integrated systems.
- Publish Customizations.
- Depending on how in depth you went, there is a good chance you will run into something here. Debug.
- Depending on if you have 3rd party addons, you will need to get their updated versions.
- Depending on how heavily Acumatica made changes to the Screens, even simple re-arranging might need redone here. Delete that screen from customization, re-add it, and rebuild it here. (See Opportunity/Contacts in 2020 R1 with the introduction of workflow).
- Verify GIs and Dashboards.
- You are only interested in making them not throw an exception. Verification of data comes later.
- Check to see if schema changes break and GIs. Open GI, if exception break error.
- Filters may also need updated.
- Because you are local, you should have access to the DB. You can use this query to help get a bunch of URLs to test the GIs quickly:
- DECLARE @MyCompanyID int = 2
SELECT REPLACE(URL,'~/',' start https://my.acumatica.url/AcumaticaYYYYMMdd /') [Paste Me Into CMD]
,S.Title, GI.Name, S.ScreenID
,''[.],''[.],''[.],*
FROM [SiteMap] S JOIN [GIDesign] GI ON RIGHT(S.URL,36) = CONVERT(nvarchar(36), gi.DesignID)
WHERE S.CompanyID IN (1,@MyCompanyID)
- DECLARE @MyCompanyID int = 2
- Once GIs give no exceptions, check Dashboards.
- Make sure GIs work first. They will cause a lot of issues for your Dashboards.
- Do some light testing. Make sure the things that make you money and let you pay work. Some Examples of what I do (we use distribution with advanced warehousing module):
- Workflow SO-Invoice.
- Workflow PO-Bill.
- Print a check.
- Receive a payment.
- Look at GLs and On Hand numbers to make sure they look ok.
- Come up with exports of anything that need changed.
Phase 3: Does it work right?
- Create a new instance that is accessible to users within your company. It should be a copy of your working test instance.
- You can just export/import from your test instance, but I find it a good exercise to go through the whole process of Phase 1 and applying the exports you generated from Phase 2, since this is what you will be doing during the upgrade.
- Work with department leaders to create and coordinate teams to hop into the system.
- Have the each team run test processes through the system.
- Have them print and verify reports.
- Have them make sure the data is correct on screens, GIs, dashboards, and in seldom used workflows.
- Fix issues as they arise.
- Work on personal test system.
- Update export files.
- Update company test system.
Phase 4: Update Production.
- If you do Phase 1-3 correctly, this should be the easiest part.
- Turn on Maintenance mode.
- MAKE BACKUPS OF DB AND SITE FILES!
- Unpublish customizations.
- Perform any maintenance tasks uncovered during Phase 1.
- Update your Production environment.
- For sanity's sake, use the same minor version you tested on.
- Replace any .css and other Site files with your updated copies.
- Import your updated files:
- Customizations
- GIs
- Dashboards
- Reports
- etc.
- Restart Application Service (IIS App Pool thread).
- Clear Browser cache and verify things look ok.
- Celebrate by turning off Maintenance mode.
Sorry for the length, I was already making documents on the process I use and thought that it's good enough to share.
Also: This works for me, but if anyone notices any mistakes or has a contribution to avoid a pitfall i dodged by luck, let me know and I can update the process.
Thank you so much for your detailed instructions. I greatly appreciate it.
