7.9 to 18.3 upgrade

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"

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"

Hi Rob,

Thank you very much for your useful comments. I agree with you 100% and in fact I have already suggested to upgrade in the order 1. Test, 2. Prod, 3. Dev but there are some concerns, specially a concern related to changes in the code related to plugins. We have 60+ plugins and more than 50% are not available in the Appian Market. If a plugin has become part of the product that means that we must update our code to use the out of the box function instead of the plugin, right? and that means that we need to go application by application to replace the plugin calls with product calls. It is potentially a big task and the customer might prefer that we implement those changes in the dev environment. If we make multiple changes in the test environment and then we export them to dev we might be overwritting some new development.

I am in the process of opening a case support with appian asking which of our plugins require changes in the code when we move from 7.9 to 18.3

Thank you very much once again.

If plugin functionality has been added to the product, you're not required to switch away from the plugin immediately, but it is recommended that you do.

please refer to the shared component policies and guidelines.
A plugin does not necessarily need to be broken to be discontinued on the AppMarket. 
Understanding that use of many plugins is "at your own risk", I can't recall an upgrade event that directly broke a plugin.  

Assuming you upgrade Test first, you can then use Search Expressions to find the use of any plugin functions in your SAIL.

This post outlines how to find plugin smart services in process models.

thanks Rob..