Customers who run older Jira instances might still have the free version of JSU. Now it is no longer free and requires a license to operate, which you'd need upon upgrading to the latest Jira instance. Recently, JSU announced price increases, up to three-fold, and as of November 4, 2019, JMWE and JSU are priced the same*. However, some customers either consider purchasing a single workflow automation tool or want to replace JSU with JMWE. In most cases, thanks to many point-and-click extensions in JMWE, as well as extensibility via simple yet powerful scripting, it can be done easily.
To migrate, you first need to go through all your Jira workflows and identify all JSU-powered post-functions, conditions, and validators. Luckily, there are apps on the Atlassian Marketplace that help you export workflow/project specifications and evaluate it easier. You can also review all workflows manually and search for the JSU key: com.googlecode.jira-suite-utilities.
Then, go to each workflow and remove and replace the JSU feature with the JMWE one. If you have JSU workflow preconditions set up, take note - you will be implementing each of these rules right inside the JMWE extension by checking off and configuring the "Conditional Validation" option.
While a few features are unique to JSU (such as bulk copy and location-based custom fields), workflow features can be easily reconfigured using JMWE. If your goal is to automate your processes through workflows, JMWE provides several additional point-and-click post-functions that are not available in JSU, so you can do even more.
Also, JMWE allows you to extend its point-and-click workflow automation capabilities beyond many of the JSU features with simplified scripting. When your automation requirements grow, or if you can't do something with JSU, try JMWE - with it, you can often find the solution.
Here is how one of the no-code, point-and-click JSU and JMWE validators compares:
Want to ensure that specific fields have a value during a transition? The Fields Required workflow validator does just that. In both apps, if any of those issue fields are left empty while transitioning, an error message will be displayed to prompt the user to input a value. Note that JSU supports many different field types, but not all. However, JMWE supports all the same field types and then more.
JSU applies context settings by default. JMWE, however, does not offer an option to ignore context since it seldom applies.
As you can see, the basic functionality is quite similar. You can customize the error message to be displayed when the validation fails - this option is available in both JMWE and JSU.
However, to make things easier for your users, JMWE also lets you display the missing field's name by simply inserting %field% placeholder.
Optionally, with JMWE, you can perform a conditional validation based on the result of a groovy expression. To conditionally execute a validator, select the Conditional validation option and add a Groovy expression. The validator is executed only if the written condition evaluates to true or a Groovy truthy. This negates the need for a separate JSU's Fields Required Precondition.
To see how JMWE Fields Required validator works, watch this 35-second video.
*As of October 23, 2019, for Jira Server and Jira Data Center