Hi all,
We are planning an upgrade from 7.9 to 18.3 and we have a question.
If we upgrade in this order 1. Dev, 2.Test and 3. Prod from 7.9 to 18.3 at some point we wont have an Production-like Environment for critical bugs.
As we would have a backup in dev (e.g. /appian79) could we:
1- Stop the upgraded 18.3 Environment in dev
2- Rename the appian79 old Environment to appian as it was originally
3- Start appian 79
Would that be enough to restore the backed up 7.9 Environment or would we Need to restore the database too?
Many thanks!
Discussion posts and replies are publicly visible
Hi jesusa310
It's a good idea to backup the database.
/
Now, in response to you upgrade plan -
For most customers, it's critical to keep the design/development pipeline unblocked during the upgrade process.
We cannot currently move an application from newer Appian versions to older Appian versions (e.g. can't import an app from 18.3 to 7.9)
So, the Dev server should probably NEVER* be upgraded first.
If you upgrade Dev first, you face 2 risks:
1st) once Dev is upgraded, new code in dev cannot move to Prod until prod is upgraded. Consider the implications of this if you have a bug in prod that needs fixing before you're ready to upgrade Prod.
2nd) Once you start an update, the server is not available to designers until the update is finished. If you run into a challenge, designers cannot unable to work until it's resolved.
If you have only 3 environments, you're likely to suffer the least interruption to your business if you test the update/upgrade on TEST first. Then test the upgraded server to ensure you understand how it behaves after the update. If you encounter a behavior change that requires a patch, (which is rare, but possible - sometimes it's merely aesthetic) you can design this patch in Dev and move it to Test, and retest.
Then, when you're happy with your testing outcomes, Update Prod next.
Then, as soon as possible after the prod update, update Dev LAST.
Alternatively as referenced in your question from yesterday, the ideal is a dedicated upgrade test server that mirrors the conditions of prod. This provides benefits not just to your upgrade testing for Appian, but also if you have a lot connected systems that are sometimes subject to upgrade.
* I'm conservative about my use of the terms "always" and "never"