/
DC to Cloud migration guide

DC to Cloud migration guide

This page is about Time to SLA for Jira Data Center. Using Cloud? Click here.

We're excited to be a part of your journey with Time to SLA for Cloud and are here to assist you through the migration process. Here’s a comprehensive guide to make your transition smooth.

Pre-migration checklist

Review Data Center vs. Cloud feature differences.
Choose between JCMA (recommended) or CSV Export/Import. Use the JCMA for a seamless migration of issue SLAs and configurations. If using the Export/Import method, be prepared to recalculate SLA data in small batches.
Ensure all SLA configurations are valid and compatible with Cloud before migration.
At least one active goal per SLA.
Different start and end conditions.
No Workflow scope (use project/issue type scope).
Avoid IDs in JQL; use names instead.
Adjust unsupported Cloud notifications (for example, project lead notifications).

Important considerations

Comparing Data Center and Cloud features

Before beginning, review our Data Center and Cloud feature comparison to ensure a seamless transition. You’ll find details on features available in each environment and understand any limitations or adjustments needed post-migration.

Key differences in migration options

  1. Jira Cloud Migration Assistant (JCMA)
    JCMA is the preferred method to migrate issue SLAs and SLA configurations without recalculation, as JCMA maintains issue history and SLA continuity.

  2. CSV Export/Import
    Exporting via CSV only moves the issues without full issue history. Using this option, SLAs won’t function due to missing history. Recalculate after import, but note this can be labor-intensive for large instances.

 


Preparation steps before migration

  1. Update JCMA and Time to SLA.
    Ensure both Jira Cloud Migration Assistant and Time to SLA are updated to the latest versions for compatibility and smoother migration.

  2. Thoroughly check SLA configurations:

    • Each SLA must have at least one active goal; otherwise, migration of the SLA will fail.

    • The SLA’s start and end conditions must be different.

    • Remove any Workflow scope in SLAs, as it's not supported in the Cloud. Instead, ensure SLAs are scoped to specific projects and issue types.

  3. Ensure the JQL you used in the SLA configuration will also be valid in the Cloud:
    For example, avoid using IDs in JQL conditions within SLA settings, as IDs may not match in Cloud. Instead, use names (e.g., field names, status names) for better compatibility.

  4. Mind the notification configuration differences:
    Fire an event and Automation notifications settings and recipient types (such as project lead, component lead) aren’t supported on Cloud and will not be migrated.


Migration process

When you migrate to Cloud with Jira Cloud Migration Assistant, you also migrate your issue SLAs. This means you don't need to perform recalculation upon migration. However, when you use the Import/Export feature, you’ll need to recalculate. If you have a high number of issues, we strongly recommend using JCMA, as it would be difficult to recalculate all of your issues afterward.

Option 1: Migrating using Jira Cloud Migration Assistant (JCMA)

To retain issue history and SLA continuity, use JCMA. This method preserves all historical SLA data, issue data, and configurations.

  1. Start migration:

    • Go to Settings > System > Migrate to Cloud.

    • Select Assess your Apps and mark Time to SLA as Needed in Cloud.

  2. Follow JCMA prompts:
    JCMA will guide you through the migration process, ensuring all SLA configurations, calendars, and notifiers are migrated seamlessly. For detailed steps, refer to Atlassian’s JCMA guide.

  3. Post-migration check:
    Once the migration is complete, you should see your SLAs, calendars, and SLA panels functioning normally within your Cloud issues. JCMA ensures history is retained, so SLAs should remain fully functional on the Cloud.

Option 2: Export/Import method

This method only migrates SLAs and calendars and requires additional steps for recalculating SLA data.

  1. Migrate your instance with JCMA
    It's recommended to first migrate your entire instance with JCMA. This ensures all configurations used in your SLAs are migrated before importing SLAs and calendars.

  2. Export your SLAs and calendars
    Follow the provided instructions to export your SLAs and calendars from your Data Center instance.

    • Go to Import/Export > Export.

    • Select the SLAs you want to export.

    • Select the calendars you want to export.

    • Check your selections in the Export section, and click Export once you think they are ready.

    • Your export will be downloaded in .json format automatically.

  3. Import your SLAs and calendars
    Follow the provided instructions to import your exported SLAs and calendars into your Cloud instance.

    • Go to Import/Export on the sidebar and click Import.

    • Upload the file you want to import, select its source, and specify where it’s coming from.

    • Select how you’d like to merge imported configurations with existing ones.

    • Select and match the components you want to import.

    • On the Summary screen, check if there are any mistakes in your selections. After you make sure everything is as it should be, click Import.

    • Once the process is done, it will look like this and the imported configurations will appear on your related screens:

  4. Recalculate SLA data
    Since issue history is not migrated with this method, you'll need to recalculate SLA data for all your issues. We recommend using our recalculation guide to perform this in smaller batches to avoid throttling issues.

If you have already migrated TTS, but the instance has not been migrated yet:

If you have already migrated Time to SLA but have not yet migrated the full instance, follow these steps:

  1. Disable Time to SLA on the Cloud side to prevent any data issues.

  2. Run a new JCMA migration to migrate any projects that you may have deleted in Cloud during the first step.

  3. Perform any necessary bulk imports or updates to ensure data consistency.

  4. Enable Time to SLA again on the Cloud side once the instance data is fully synchronized.

  5. Complete the import of SLAs and calendars, if it wasn’t already completed in the previous steps.

  6. Run recalculations in smaller batches following our recalculation guide to avoid request overload.


In case you need any guidance or help during your migration process, please do not hesitate to contact us – we'll be glad to help!