DC to Cloud: Your SLA app probably won’t migrate the way you expect

[#1]

If you’re planning a Data Center-to-Cloud migration, there’s one thing that catches a lot of teams off guard: your SLA configuration might not survive this move unchanged.

In some cases, your current app may support an automated migration path. In others, you may need to rebuild parts of the setup manually. And yes, the scenario where you recreate your SLA setup from scratch is real.

At Deviniti, we’ve worked through this with several teams and want to share what helps in practice, so you don't spend a week discovering the same gaps during go-live prep.

Before you rebuild anything, check the migration path

Before you start recreating SLAs, check your current app’s documented Cloud migration path.

Some apps support JCMA. Some offer a separate vendor-led migration path. Some migrate only part of the configuration. Others require manual work.

Here are the first checks we’d make:

Check	Why it matters
Does your current SLA app have a Cloud version?	The Cloud version may not match Data Center feature-for-feature.
Does it support JCMA migration?	Some apps migrate configurations or data automatically; others do not.
What does not migrate?	Custom fields, reports, dashboards, historical SLA data, or app-specific JQL may need manual work.
Is the Cloud app Forge or Connect?	This matters for data residency, compliance, and vendor review.
Is pricing different?	Cloud subscriptions may change the business case.

✅ Result: Before anyone starts rebuilding, you know whether you are migrating, partially rebuilding, or redesigning the SLA setup.

Be prepared for a rebuild

Your Data Center SLA app may have a Cloud version, but don’t assume it will behave exactly like the app you use today.

The Cloud version can have a different architecture, UI, feature set, pricing model, migration path, or data-hosting model. That does not always mean you are starting from zero. But it does mean some parts of your SLA setup may need to be reviewed, rebuilt, simplified, or tested again.

This is where teams often find surprises:

• some configuration migrates, but not everything;
• some SLA rules need to be recreated manually;
• calendars, notifications, reports, or historical SLA data behave differently;
• the Cloud version uses a different configuration model;
• pricing, hosting, or compliance requirements need a fresh review.

The upside? Migration is also a cleanup opportunity. That SLA created three years ago for a project nobody uses anymore probably does not need to come with you.

Set up priority-based response SLAs with JQL

A common SLA setup in the Data Center is different first-response targets by priority:

• Blocker = 1 hour
• Critical = 4 hours
• Minor = 24 hours

In many Data Center setups, teams configured this with dropdown-style conditions: select Priority, pick the value, and define the goal.

In Cloud, JQL-based targeting is often the more flexible approach. It feels different at first, but it gives admins more control when SLA rules depend on priority, issue type, project, customer group, or request context.

A simple setup could look like this:

1. Create one SLA for the priority level.

2. Add the JQL filter: priority = Blocker.

3. Set the goal to 1 hour.
4. Start the SLA when the issue is created.
5. Stop the SLA when the status changes to “In Progress” or when the assignee adds a public comment.
6. Add a warning before the deadline, for example, when the SLA is at risk.

Then duplicate the SLA for each priority and adjust the name, JQL, and target.

Need to combine Priority + Issue Type + Project? Use one JQL line:

priority = Blocker AND issuetype = Incident AND project = HELPDESK

⚠️ Important: If you used Request Type or Organization to decide which issues get an SLA, you may be able to handle that in the JQL filter. But start, pause, and stop conditions depend on what your chosen app supports, so check this before rebuilding all rules.

Check the calendar setup early

Calendars are one part of the rebuild that can be faster than expected, depending on the app you choose.

In the Data Center, many teams handled holidays manually: one date at a time, often per country or region. If you support several markets, that turns into a lot of copy-pasting and checking.

When you evaluate your Cloud SLA setup, check whether your app supports:

• applying the same working hours across multiple working days;
• importing national holidays instead of adding them manually;
• repeating holidays annually;
• handling multi-day holidays as one entry.

A typical setup might look like this:

1. Create a calendar, for example “PL Business Hours.”
2. Set the timezone to Europe/Warsaw.
3. Define working hours, for example 8:00–17:00.
4. Apply those hours across working days.
5. Import national holidays, if your app supports it.
6. Enable annual repeat, if available.

✅ Result: You avoid rebuilding calendars date by date and can test regional support hours before go-live.

Test Customer Portal SLA visibility

Another Cloud-side improvement worth checking is customer-facing SLA visibility.

Some Cloud SLA apps can display SLA progress directly in the Customer Portal, so customers can see timing information without having to ask the support team for an update.

For example, instead of sending another “any update?” message, a customer can see whether the request is still within the expected response window. If your stakeholders see migration as “just recreating the old setup,” this is a useful counterpoint: some Cloud setups can improve the customer experience, not only preserve the existing one.

⚠️Important: Test how your chosen app handles visibility, permissions, and time zones before go-live. The last thing you want is to expose timing information that customers interpret differently than your support team does.

Don’t assume recalculation will fix historical SLA data

After migration, test what happens when you change SLA rules.

Do the new definitions apply only to new issues? Open issues? Closed issues? Can you recalculate historical SLA data? If yes, can you scope that recalculation to selected projects, issue types, or time ranges?

This matters if leadership expects clean reports right after go-live. A rule that works well for new tickets may not automatically fix historical SLA data.

✅ Result: You know whether post-migration reporting will reflect the new SLA rules or whether you need a separate reporting note for historical issues.

Small checks that prevent bigger migration problems 

Check where your Cloud app stores data. On DC, everything was on your servers. On Cloud, some apps use Connect (data is processed on the vendor's infrastructure), and others use Forge (data stays within Atlassian). For regulated industries (banking, healthcare, government), this distinction matters. Ask your vendor before you commit.

Do not rebuild 1:1. If an SLA no longer supports a real process, leave it behind. Migration is a good moment to simplify old rules, remove unused calendars, and clean up notification logic.

Re-evaluate your app stack. The app you used on Data Center may have different features, pricing, architecture, or migration options on Cloud. It is worth comparing options before automatically choosing the same setup.

Test before go-live. Set up SLAs in a sandbox project. Run a few tickets through the full lifecycle: created, in progress, waiting for customer, resolved. Check start, pause, stop, warning, and breach behavior.

Document your current setup first. Before touching anything, create a simple spreadsheet with SLA name, target time, conditions, calendar, notifications, and reporting use. Then map each item to the Cloud equivalent.

Decide how time zones should work. If your support teams work across regions, define whether SLAs should follow the customer, reporter, assignee, organization, or support team calendar. Do not leave this implicit.

Quick reference: What changes from Data Center to Cloud

Area	Data Center	Cloud
Issue targeting	Often field- or condition-based	Often JQL-based, depending on the app
Start, pause, and stop conditions	Status, priority, fields	Depends on the app; commonly status, priority, assignee, resolution, comments, or custom fields
Holiday calendars	Often manual setup	May support holiday import, annual repeat, or faster regional setup
Customer Portal SLA visibility	Often unavailable or limited	May be available depending on the app
Multi-day holidays	Often added day by day	May be supported as a single entry
Data hosting	Your own environment	Depends on app architecture and vendor setup
Pricing	Data Center licensing	Cloud subscription; compare before assuming parity
Configuration migration	Existing app configuration	Automated, partial, vendor-led, install-only, or manual depending on the migration path

What we used

For the examples above, we used Deviniti’s SLA Time Management on Cloud. The concepts apply broadly, but exact migration options, supported conditions, recalculation, calendar features, and portal visibility depend on the SLA app you choose.

Migration checklist

Before rebuilding your SLA setup, check:

• which parts of your current app can migrate;
• which SLA rules, calendars, and notifications are still needed;
• whether historical SLA data can be recalculated;
• how time zones and regional calendars should work;
• what customers and agents should see after go-live.

If you have already migrated SLA configuration from Data Center to Cloud, what caught you off guard?

Did your existing app carry over cleanly, or did you end up rebuilding more than expected? Let's discuss :)