This page provides information about Appian's unparalleled, backward compatibility promise, the development and testing principles and practices that make it a reality, and how you can upgrade Appian with confidence and ease.
Upgrading to a newer version of a platform that isn't backward compatible can be time-consuming, expensive, and risky. We didn't want that to be the case with Appian, so we committed to providing backward compatibility very early on, and made that a foundational principle for our platform's design and development.
This means if you want to upgrade to the latest version of Appian, our goal is to make your existing applications work without further effort on your part. We take the cost on ourselves, but we don't do this just to save you time and money. We do this so you have the best possible experience and are able to take advantage of new features, stay current with the fast pace of technological innovation, integrate with the latest players and services, and benefit from every advance in performance, stability, and security.
In order to improve the platform in a way that ensures the applications you build today work on the platform tomorrow, proposed new features or capabilities must align with the following tenets:
Rather than change existing features in ways that would make them incompatible with existing applications, we will improve them in compatible ways that benefit their existing usage while enabling new ways of using them, or introduce new, improved versions of said feature without removing the old.
This allows customers to build new applications to take advantage of the new features, while having the option to choose whether or not it makes sense to implement them in older applications.
Rather than create new product areas, or new products, new features should be able to interact/work with the applications created with older features.
This allows customers to evolve their applications to take advantage of new features without having to remake them from scratch.
Above all, we don't mindlessly adhere to any design tenet if it denies our customers a new, high-value capability. Although the tenets ensure that it rarely happens, we are sometimes faced with the decision of making a change that impacts backward compatibility for a particular element of the platform. Leaving old elements in place is typically the preferred method, but when that's not possible, we weigh a number of factors including the popularity of the component, the cost of its removal, whether we can automate its replacement, and so forth. We only remove things that extremely few (if any) people are using, and the large majority of customers over the last few years haven't had to change anything as a result.
If we reach the decision that something should be removed from the product to the benefit of all, we make sure the impact is as minimal as possible by providing:
We employ industry-leading testing practices that include comprehensive regression testing to ensure that every feature is compatible with every other. No single feature can even become a part of the platform until it's proven it integrates seamlessly with every other part.
We also run an internal alpha phase all throughout development with real-world usage of the product in progress to flush out errant bugs.
Then, when development is complete, each new version of Appian goes through an additional, month-long, private beta phase where the release is used in production by select participants.
Any issues discovered during either of these phases gets corrected, and we expand our test suite to ensure that it, and similar types of issues, are found in the future.
These practices ensure the highest level of quality and confidence possible so you never need to test your applications, or Appian itself, when you upgrade to the latest version; we've already done it for you.
We rely on a strong communication plan of documenting everything you need to know before you upgrade to the latest version of Appian. If anything has been removed, or any product behavior has changed that you may need to know about, we document it all. For every release of Appian we document all removals, behavior changes, and changes to upgrading Appian, as well as provide notices when some part of the product is placed into the deprecated status.
Since that content relates to upgrading Appian from one version to the next, if you are skipping versions, you must read the Release Notes and Upgrade Guide for every intervening release. This means if you're upgrading from 20.2 to 20.4, you must read the Release Notes and Upgrade Guide for 20.2, 20.3, and 20.4.
Every version of Appian has its own version of the documentation, and that version number is displayed on every page at the top of the right-hand panel. Click on the number to quickly navigate to the same page in another version of the documentation.
On This Page