Most of the time, customers want to keep SLA data for existing issues when they attempt to change SLA definitions. There is a simple way to do this within the Time to SLA app, where you limit your current SLA definition to existing issues and define a new SLA definition for new issues. Here are the detailed instructions:
Say you would like to apply new SLA definitions on issues created after 2019/05/20
1. Clone your current SLA.
2. Set the name of the new SLA.
|Adding a version identifier is optional, yet we recommend it since it could be helpful to distinguish different versions of your SLA. So, set the name of the new SLA as the current SLA name followed by a version identifier like "v2", "new", etc. e.g. "Time to Respond v2".|
3. Select whether or not pause, reset and notification settings should be cloned into the new definition (you will probably want to check all of them).
4. Click Save and Edit, and then you will be directed to the configuration page for your new SLA.
5. Add the following clause to the end of the current JQL filter in SLA definition and save the changes
|AND created > "2019/05/20"|
6. Return to the SLA Configuration page and change your current SLA definition as follows:
a. Add version identifier to its name such as 'v1', 'old', etc. indicating that it will be used for only past issues, e.g. "Time to Respond v1".
|This step is optional, but we recommend it since it could be helpful to distinguish different versions of your SLA.|
b. Add the following clause to the end of the current JQL filter in SLA definition and save the change.
|AND created < "2019/05/20"|
At the end, you will have two SLA definitions and your issues will be subject to either one of these based on your date criteria. You can use any other field to distinguish issues such as resolution date for example, but make sure that you handle EMPTY values of those fields properly.