SLA & OLA migration guide

Here’s the migration guide for anyone still using the old SLA/OLA management. As of version 3.0.0, we will discontinue support for SLA v1 and remove it from the application—only SLA v2 will remain. To prevent any disruptions, we strongly recommend migrating to SLA v2 as soon as possible.

You can find detailed migration instructions in this guide. If you need assistance, please reach out to our support team. Should you encounter any issues—such as potential feature gaps—contact us through the usual support channels so we can investigate and propose a solution.

To streamline this transition, we’ve added a built-in migration feature that automatically carries over most of your existing settings (working calendars, color thresholds, SLA/OLA field definitions, etc.). By following the steps in this guide, you’ll minimize the time required to start using new and improved SLA.

Here are key differences between new and old SLA/OLA management:

Step-by-Step Migration Procedure (using the SLA Migration Helper)

1. Choose an appropriate maintenance window

   • Ideal timing: off-peak hours or a scheduled maintenance window when few users are active.

   • Reason: During migration SLAs will pause and then be recalculated for every open issue, which can take significant time on large instances.

2. In Jira navigate to Jira Administration -> HelpDesk -> SLA -> [Deprecation notice] SLA & OLA.

3. Click “Migrate” button and you will open Migration helper:

   

   Read the information in the “Start” and “General Settings” steps carefully

4. Automatic Migration of General settings
   Some of your settings will be carried over automatically by the migration engine and after migration you can immediately reuse these in your new SLA rules. There is no manual re-entry required for:

   1. Working Calendars (including all exceptions and holidays)

   2. Color Schemes (all thresholds and palette rules)

   3. Working Day / Week definitions

5. At the step “SLAs” you must explicitly review and (if desired) tweak during the migration is your trigger conditions (formerly workflow post-functions). At the SLAs step, for each SLA entry:

   1. Click the “Show more migration details” button on the right.

   2. In the menu you’ll find SLA/OLA settings which will be migrated (can’t be changed) and four checkbox lists (Start, Pause, Stop, Reset) - they correspond to the old “HelpDesk SLA/OLA Management” work types. All work types which were defined in post-functions will be selected here. Change your conditions if needed.

      

      • To replace “Reset & Start”, simply check both Reset and Start on the same transition.

      • Since OLA is now built into new SLA, you must reconfigure your triggers to align with the new SLA.

   3. You can add multiple condition per action — no need for separate post-functions.

   4. Click Next.

6. The “OLAs” step consists of all created OLAs which will be transformed into SLAs (because OLA is now integrated into SLA). To maintain effective tracking of internal team performance, you must reconfigure your triggers on previous step. Additionally, after the migration is completed, you’ll need to transform your existing OLAs goals to new logic (more on that at step 9 of this guide).

7. Click Finish to apply.

8. All open issues’ new SLA timers will be back-filled and recalculated. This can take several minutes to hours depending on number of issues.

9. Once migration completed, you’ll need to reconfigure your OLA settings because all existing OLAs will be automatically transformed into SLAs. In previous version the SLA and OLA were managed separately: you chose a custom “Team” field in the OLA settings and then embedded each team’s name directly into the JQL. In the new SLA model, OLA is a built-in part of SLA: you define one generic JQL per goal and then pick which teams that goal applies to via a “Teams” select field.
   To transform your existing OLA goals to new logic, you should change each goal and remove any “teams” from its JQL. Then, after you strip out the “teams” from different JQL, you may end up with multiple goals using identical JQL—feel free to delete those duplicates and then use the “Teams” select field to add the specific teams you need with the appropriate goals for them.

10. Create a few test issues and walk through your workflows (don’t forget to configure new SLA/OLA fields) to confirm:

    1. SLA timers start, pause, reset, and stop exactly where you expect.

    2. Color thresholds display correctly.

    3. Re-opens behave per your chosen cycle mode.

11. When you’re satisfied with the result:

    1. Update any runbooks or internal docs referencing “HelpDesk SLA Management” or “HelpDesk OLA Management” post-functions.

    2. Notify your team about the changes when the new SLA is ready.

    3. Remove any leftover post-functions for the old SLA and OLA in your workflows and remove any “SLA Karma” custom fields to keep your instance clean.

For an in-depth look at all the new features check out our full documentation here.