Hi Appian Community,
I am working on a large-scale decommissioning project for a legacy system that has been active for over 15 years. We are currently on Appian 25.4 and are facing significant disk space consumption (approx. 12GB in Process Model definitions and 11GB in Engine KDBs).
A major challenge is that these legacy assets do not follow any standard naming conventions or abbreviations and are scattered across multiple applications. We are currently trying to define the best criteria to categorize which objects are "Dead" and safe to delete versus which are still "Active."
I am seeking best practices and recommended utilities for the following:
1. Categorization & Filtering Strategies Since naming conventions are unreliable, what parameters are most effective for identifying legacy artifacts?
Are there ways to bulk-query metadata (like Last Run Date, Last Modified Date, or Total Instance Count) to distinguish between legacy and active objects?
Is there any Plug-in that can generate a list of "Orphan" objects (Interfaces, Expression Rules, Query Rules) that are no longer called by any top-level process models?
2. Instance Management (Running & Archived) The legacy architecture kept many parent processes "Live".
What is the most efficient way to Terminate and then Hard Delete thousands of instances (Running, Paused, and Archived) across different models?
Should we use a specific batching strategy to avoid engine performance issues during a mass cleanup?
3. Identifying Hidden Dependencies We need to clean up related DB triggers, Stored Procedures, and filesystem documents.
Are there recommended methods to map an Appian Process Model to its specific database triggers or Knowledge Center documents when names are not linked?
Any advice, plugin recommendations, or strategy frameworks would be greatly appreciated!
Thanks in advance!
Discussion posts and replies are publicly visible
Here some ideas:
1. I would start by listing all the applications involved in the bulk decommissioning. Then, for each application, I would review which objects need to be removed. Considering that the development team might have incorrectly added objects to an application that should not be removed from the environment (for example, the User record type might have been added to the app), there is no fully automated way to handle this. Therefore, you will need to manually verify whether each object should be removed or not. To help with this, I would rename the objects by adding the _DEPRECATED suffix.
2. Once all the Appian objects are identified (which will now be much easier to find thanks to the previously added suffix), it is time to check the database. You can follow this post: Query to find the dependent object on Table in MySQL or MariaDB - SmartTechWays - Innovative Solutions for Smart Businesses. This approach is not 100% accurate, but I believe it can still be helpful.
3. Regarding stored procedures, since you already have all the applications listed, you can check how many of them are using the execute stored procedure plugin. Here, I am assuming that because these applications have been running for the last 15 years, they have not migrated their processes to newer Appian versions where executing stored procedures is an OOTB feature.
4. I would also use an ad-hoc process model to remove all KCs marked as deprecated by using Delete KC Smart Service - Appian 26.3 smart service. I have not used it before, so I recommend verifying whether it also removes the documents stored within the KC.
5. By following these steps, I believe you will have everything needed to remove the active instances (for example, by querying a process report filtered by all active process model instances obtained in step 1) and then cancelling them.
Obviously, this approach could be further improved, but at least it provides a pseudo-framework to follow. I hope this helps you