I want to know what is the most effective strategy to handle old production processes that were designed with a methodology that involves extensive and long-lasting processes. In addition, we face numerous PRO issues that require quick solutions from the support team. Simultaneously, improvements are being made to extend or enhance the functionality of these processes. However, problems arise when we have to solve an issue that involves the modification of objects that are also being altered in the enhancements and are not yet stable. Another challenge is managing active instances with old versions of the flow; when trying to implement a new version of the process, conflicts can arise due to incompatibility between the old version of the instance and the new version of the process. Appian suggests a method in their documentation, but I find it has several limitations. I am interested to know how they handle these situations in other projects to learn from the best practices applied.
docs.appian.com/.../Process_Upgrade.html
Discussion posts and replies are publicly visible
For resolving production issues when there are current dev/test efforts for other enhancements, as Stefan notes a Pre-Prod or "Hotfix" environment that is synched with production is very helpful. You can dev/test in that environment, push to prod, then [manually] make the same changes in the dev environment.
Another method you might be able to use, if possible, is to halt testing on current upgrades, backfill your production application to TEST, fix/deploy from there, then re-deploy your Dev changes to Test and resume testing (after also adding the 'fix' in Dev manually).
For enhancements to processes with long-running instances, I always maintain a "version" data point in the CDT. I store this in a process variable (which saves to the CDT on launch), any time I make changes such as adding data points to a CDT and interfaces, increment the version by 1, then interface and other logic (sub process, expression rules, etc) can reference the version to see if it should attempt to utilize the newer logic. E.g., showWhen: ri!CDT.version>3.
Another methodology that works well for me is completely avoiding passing CDTs to sub processes. In all of my current proceses, the parent will persist data to the DB, pass the unique ID only to the sub process, the sub process will query back based on ID to populate it's own CDT and work from there. Then, the sub knows which 'version' of the parent has been started on and you can design the logic accordingly.