7.9 to 18.3 upgrade

HI Jesusa,
I could not get what exactly you are looking for. When you are done with upgrade to 18.3, for potential bug fixes you would obviously follow fixing in Dev then move to Test & Prod. If you can elaborate further, that helps.
Thanks.

Hi,

As mentioned by vishnuv, after upgrade, the bugs in the present application can be fixed in 18.3.
Also, once you have upgraded to 18.3 it would be difficult to roll back to your older version 7.9. Please understand that 7.x and 18.3 uses different architectures. 18.3 makes use of Tomcat servers while 7.9 is on JBOSS.

If you need to maintain both the versions then you should prefer to have individual installations.

Thanks,
Himanshu

Hi,

Please refer below links for your upgrade, they will be very helpful since you are upgrading very old version to latest version.

Upgrade Guide : docs.appian.com/.../Upgrade_Guide.html

community.appian.com/.../upgrade-appian-from-7-2-to-17-3

community.appian.com/.../upgrade-appian-from-7-2-to-18-1

community.appian.com/.../upgrade-information

community.appian.com/.../appian-upgrade-from-7-9-to-the-latest-version

Hi Jesusa,

I understand that you want backup ready with 7.9 for fixing prod bugs and it should be easy to switch. But I think you may need to maintain 7.9 version environments by the time prod upgrades to 18.3.
There are major changes in architecture from 7.9 to 18.3.
Better to talk to Appian support and they will provide right direction to upgrade.
Thanks

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..