Tools for Jira
Tools for monday.com
Many teams are moving from Jira Data Center to Jira Cloud because the platform is becoming Cloud-first, Server support ended on February 15, 2024, and Atlassian recently announced the end of life for Data Center.
In Cloud, Atlassian delivers faster feature releases, broader automation, and evolving roadmaps and dashboards. At the same time, the heavy lifting of infrastructure is taken off your plate. This means less time patching and scaling nodes and more time improving workflows.
A smooth move starts with structured migration planning. We typically recommend a quick inventory of your instance (projects, workflows, custom fields, apps, permissions), running the pre-migration checks, and trying everything in a Cloud sandbox before production. Atlassian’s Cloud Migration Guide outlines clear options, tooling, and validation steps to reduce migration downtime and avoid disruptions during this period.
This case study walks through the real issues we ran into while helping customers migrate Smart Checklist from DC to Jira Cloud (Forge): what went wrong, how we fixed it, and what you can reuse in your own plan. If you’re earlier in the journey, you might also scan our background piece on migrating DC to Cloud for context.
Customer backdrop & migration approach
Most migrations start from a familiar starting point: a Jira Data Center instance that’s been tuned for years, with hundreds (sometimes thousands) of projects, strict security controls, and a long list of Marketplace apps. Teams typically choose Cloud to cut infrastructure overhead and stay current, but they still need assurance that product data, custom fields, and app functionality will land intact.
We generally recommend a low-risk migration path for our customers:
- Spin up a Cloud sandbox for trial runs. This allows admins and product owners to rehearse the move, compare workflows, dashboards, and permissions, and identify gaps early.
- Run JCMA pre-checks and conduct an app assessment. The Jira Cloud Migration Assistant surfaces user and domain issues, flags unsupported plugins, and helps plan the order of moves.
- Migrate in waves. Large instances benefit from staged moves: select a pilot set of projects, validate them in Cloud, and then scale up. Wave planning reduces migration downtime and keeps user management and permission fixes manageable.
- Define “success” upfront. For Smart Checklist, this means: ensuring all checklists and progress values are present, no duplicate custom fields, and clean visibility for developers, the product team, and other stakeholders after migration.
This approach provides space to test assumptions, align expectations with stakeholders, and make a predictable, low-drama move to Jira Cloud, which customers look for.
The hard parts we hit (at a glance)
Even with careful migration planning, a few patterns kept recurring as customers migrated Smart Checklist from the Data Center to Jira Cloud.
App paths and timing. Smart Checklist is built on Forge in Cloud. When automated app-data migration was not yet available on Forge, some admins hit a blocker mid-run. Our workaround was a short Connect bridge purely to transport data, then finalize on the Forge app in the target cloud site.
User experience delta. Teams accustomed to Jira DC often expect the same screens and workflows in Cloud. Differences in navigation, automation behavior, and project admin options created a learning curve, prompting us to create detailed tutorials and customer walkthroughs to prepare customers for the new experience.
Large, staged moves. Big instances rarely go all-at-once. In staged migrations, Cloud occasionally created duplicate custom fields across waves, which complicated reports and dashboards. We added a post-migration synchronization step to consolidate these into one canonical field per checklist.
Run stability under scale. Long runs sometimes stalled: rate limits, batch sizes, and background job limits surfaced at scale. We introduced checkpointing and safe restarts to keep progress moving without significantly extending migration downtime.
While these challenges weren’t showstoppers, they shaped our playbook: validate apps up front, rehearse in a sandbox, plan waves, and budget a short post-migration pass to tidy permissions, fields, and automations.
Deep dive: a checklist “drop” that only showed up at scale
One enterprise customer migrated in waves using the Jira Cloud Migration Assistant (JCMA). While pilot runs appeared successful, a larger migration wave revealed a serious issue: some issues in Cloud were missing their Smart Checklist data, while others were complete, with no obvious pattern.
How it surfaced.
Pilot users compared a DC project to its Cloud twin and saw mismatched checklist counts during sandbox migrations. We paired on a supervised re-run to watch the app migration platform hand-off: DC packaged app data, uploaded it for Cloud to pick up, and Cloud imported it into the target site. Atlassian JCMA assistant
Root cause (what we found)
Our DC exporter wrote data in batches to the platform’s export (JSON stream). To keep DC responsive, it paginated, exporting a fixed number of checklist records per batch. In a recent change, we reduced the batch size to around 1,400 items, but one offset still advanced by 5,000. Result: after writing 1,400 items, the next read skipped ahead, silently omitting thousands of checklist items before resuming. Small pilots didn’t hit that edge; large waves did.
How we proved it.
We shipped a temporary DC build with verbose logging and re-ran the wave. We shipped a temporary DC build with verbose logging and re-ran the export wave. The logs showed that each batch processed about 1.4 K checklists, but the cursor advanced by 5 K each time. That confirmed an off-by-batch bug in the export logic – the exporter skipped several thousand records per iteration. The problem was on the export side only, not related to import or JCMA.
The fix and recovery.
We corrected the export bug and triggered a new full-scale migration for the affected projects. JCMA allows restarting only failed app migrations, while the entire site migration can only be copied and re-run from the start. Since this happened during sandbox test waves, running another full migration was safe and straightforward. After fixing the exporter, all data transferred correctly.
Migrating Smart Checklist from Jira Data Center to Jira Cloud for my client in the educational domain was a smooth experience, thanks to your team’s excellent support. You were quick to respond and helped resolve a technical challenge with the Forge app, ensuring all data transferred successfully. After several trial runs, the final migration went flawlessly, and all checklist data was present in the cloud. I really appreciated the responsiveness and expertise throughout the process highly recommended!
What we learned from this experience.
- During staged migrations, validate a few high-traffic projects by comparing checklist counts DC vs Cloud before signing off on the wave.
- If you suspect an app-data gap, re-run just the app’s migration for the affected projects rather than the whole site – JCMA supports targeted reruns. Atlassian Support
Next up, we’ll cover how we handle long-running jobs and the playbook we now use to keep big migrations moving.
Engineering constraints in Cloud and how we designed our migration around them
On large moves, the technical ceiling matters. Forge is secure and Cloud-native, but it enforces strict guardrails that you’ll encounter during app-data migrations. Here’s how we adapted our approach so that long runs finish reliably without stretching your cutover window.
The 15-minute wall.
Forge background functions can run for up to 900 seconds; after that, the platform stops the invocation. We reworked long exports/imports into checkpointed batches that save state (last processed issue/checklist) and resume in the next invocation, rather than trying to push everything through a single run.
Invocation & rate limits.
High-throughput waves can hit platform quotas (invocations/minute and related limits). When we detect throttling, the job pauses, schedules the next slice, and continues from the last checkpoint. This avoids partial writes while respecting Forge’s rate and runtime quotas.
Cyclic invocation depth.
Self-queuing patterns eventually run into a cyclic invocation depth cap. To stay under the limit, we switched from deep chains to shallow batches, along with a lightweight scheduler that periodically relaunches any stalled work.
Auto-restarts for stuck jobs.
Long runs sometimes stall due to transient limits. We added a scheduled trigger that scans progress markers hourly and restarts any task that hasn’t advanced. This pattern keeps work moving without manual babysitting.
What this means for your migration.
- Big exports/imports proceed in safe chunks with the ability to resume on failure, which reduces the chance of overruns during your production window.
- If the platform slows us down, we back off, reschedule, and continue.
- You get predictable progress with clear logs and checkpoints, so validation stays straightforward after each wave.
If you’re building your own helpers for app data, we recommend adopting the same patterns: bounded batches, explicit checkpoints, and a simple “watchdog” scheduler. Atlassian’s docs on platform quotas, scheduled triggers, and metrics are a good starting point.
Other common challenges we experienced in the migration process
Even with solid migration planning, several patterns tend to emerge when moving from Data Center to Jira Cloud.
App & add-on compatibility.
Not every Marketplace app offers the same functionality in Cloud, and some don’t move data automatically. We recommend conducting an app audit early (inside your migration plan) and confirming each vendor’s path. If an app lacks a Cloud route, earmark reconfiguration time or replace it before the cutover.
User management surprises.
Accounts don’t always map 1:1. Duplicate users (same email, different usernames) or reactivated deactivated accounts can appear. We suggest validating email domains during pre-checks and syncing groups from your IdP so permissions in the cloud site match what teams expect.
Permission scheme gaps.
Global permissions and group-to-role mappings differ between DC and Jira Cloud. If users suddenly can’t browse or edit issues, or if dashboards look empty, compare the project’s permission scheme against your DC model, then fix group membership and project roles accordingly.
Automation & workflow differences.
Cloud automations use different triggers, actions, and limits. Scripted validators and post-functions often need a Cloud-native rewrite. If transitions stall or notifications stop, check the rule’s audit log, simplify complex rules, or split them into smaller steps you can validate quickly.
Custom field duplication.
Staged migrations sometimes produce duplicate custom fields. At the post-migration step, consolidate to a single canonical field and re-point filters, JQL, and reports. This keeps reports, dashboards, and workflows clean.
Heavy data loads.
Large attachments or very busy projects can slow down the migration process. We usually recommend archiving old projects, trimming oversized attachments, or migrating in smaller waves to avoid extending migration downtime.
How we handle recovery.
When something slips, we re-run only the affected projects or app data after fixing the root cause. A short post-migration checklist—issues, attachments, workflows, permissions, and key apps—helps confirm the site is healthy before you call the migration done.
Results of Smart Checklist DC to cloud migration
When we finalized the migration process for multiple customers, outcomes were consistent and measurable:
- No data gaps. Checklists, items, and progress values arrived intact. Where staged waves created duplicate custom fields, a quick sync consolidated everything into one canonical field, keeping JQL, filters, and dashboards clean.
- Predictable cutovers. Batching plus checkpoints ensured that long runs didn’t overrun the freezing window. If something slowed down, jobs paused and resumed without risking corruption.
- Operational simplicity. Teams left behind DC maintenance (nodes, storage, backups) and adopted Atlassian’s Cloud cadence for features and security updates, spending less time on infrastructure and more time on optimizing workflows and automation.
- Clear validation. Admins and QAs had a short, repeatable checklist to verify permissions, user mapping, and app behavior after each migration wave, so go-live decisions were confident.
- Happier stakeholders. Product owners and other customer stakeholders saw that data residency choices and compliance controls in Cloud met policy, while end users enjoyed a faster, more consistent experience.
If you’re at the planning stage, we recommend starting with Atlassian’s Cloud Migration Guide for the official steps and pairing it with a sandbox pilot to pressure-test your app before production.
Short migration playbook you can reuse
Here’s a lightweight runbook we’ve developed on our path of moving Smart Checklist from Data Center to Jira Cloud. Use it as-is or adapt it to your migration planning.
Before you start (prep)
- Inventory the instance: projects, workflows, custom fields, dashboards, automations, and installed Marketplace apps.
- Spin up a Cloud sandbox and connect JCMA. Run pre-migration checks; fix email/domain mismatches and obvious permission gaps.
- App audit: confirm each app’s Cloud availability, data migration path, and any feature differences. Decide on phased moves for larger projects.
- Pick validation targets: a few high-traffic projects where you’ll compare DC vs Cloud data and user experience.
- Work with users: define Pilot users who will be testing migration results, communicate plans with these users in advance, plan learning sessions for end users, and document the “new way” for teams in Confluence.
During migration (execution)
- Freeze changes in DC for the wave, then run JCMA for projects and users (and app data where supported).
- Monitor progress and logs. If a step slows or throttles, pause and resume; avoid forcing long single runs.
- Validate immediately in Cloud: check for issues, attachments, custom fields, automations, and app data. Log any gaps while the context is fresh.
After each wave (tidy & enable)
- Consolidate duplicate custom fields and re-point saved filters/JQL and dashboards to the canonical field.
- Re-check user management (groups/roles) and spot-test Jira Software boards or Jira Service Management queues.
- Recreate or simplify app rules/automations to fit Cloud limits; document the “new way” for teams in Confluence.
- Communicate changes (through short notes, GIFs, or a 10-minute walkthrough) and capture feedback for the next wave.
Note: We can help you migrate your data from other checklist apps to the cloud. If you’re interested, please contact us.
Security note: why Cloud was “not yet” before and is “yes” now
Many teams originally chose the Data Center for tighter control and perceived lower risk. Today, Atlassian Cloud addresses most of those concerns with concrete controls and certifications:
- Data residency. Org admins can keep in-scope Jira/Confluence data in specific regions (US, EU, Australia, Germany, Singapore, Canada, UK, Japan, India, South Korea, Switzerland) rather than distributing it globally. That satisfies many sovereignty and compliance needs without running servers yourself.
- Government-grade compliance. Atlassian Government Cloud achieved FedRAMP Moderate authorization in March 2025, opening Cloud to agencies and regulated contractors that require a vetted security baseline.
- Roadmap for stricter environments. Atlassian continues to expand residency coverage and introduced Atlassian Isolated Cloud (a managed, dedicated VPC offering) on the public roadmap for organizations with the most sensitive workloads.
If you’re still on Server/DC mainly for security reasons, it’s worth revisiting those assumptions. Server support ended on February 15, 2024, and DC support will reach its EoL on March 28, 2029, meaning no new fixes or patches, which creates an actual risk surface that grows over time. Cloud now combines residency choice, regulated-market certifications, and a fast release cadence that’s hard to match on-prem.
A clean move from Data Center to Jira Cloud is absolutely achievable with the right plan: rehearse in a sandbox, run JCMA pre-checks, migrate in waves, and validate apps, permissions, custom fields, workflows, and automations as you go. If you need an experienced team to support your migration from DC to Cloud, please contact us.
