Jira Data Center to Cloud: your worklog reports

Atlassian is ending Jira Data Center. If your teams’ timesheets come from a worklog report app on Data Center, this page says what moves to Cloud with your issues, what stays with the app, what Jira Cloud has in its place, and what to check before the move. It ends with Logline, the worklog report we built for Jira Cloud.

The dates

From Atlassian’s Data Center end of life page and its migration page:

• 16 December 2025: no new Data Center apps submitted to the Marketplace.
• 30 March 2026: no Data Center subscriptions sold to new customers.
• 30 March 2028: existing customers can no longer buy Data Center products, apps or more users.
• 28 March 2029: end of life. Data Center subscriptions and the Marketplace apps that go with them expire, and the products become read-only. Until then Atlassian keeps up technical support and fixes for critical security issues.

Jira Software and Jira Service Management Data Center are both on the list; Bitbucket and Bamboo are not.

What moves with your issues

The Jira Cloud Migration Assistant moves each issue’s work log and time spent, and its original and remaining estimates (what gets migrated). So the hours people logged with Jira’s own Log work arrive in Cloud on the same issues.

The same page says what the assistant leaves behind. For a worklog report, these matter:

• Dashboards, so a dashboard that showed the team’s hours is rebuilt in Cloud.
• Filters across more than one space, and filter subscriptions, so a saved worklog search that covers several spaces, or the email it sent every Monday, is set up again.
• Each person’s time zone: “timezone information on a per-user profile will be lost”. The time zone decides the day a worklog near midnight counts on, so ask people to set theirs in their Atlassian profile after the move.
• An app’s own data, which moves only along a path its vendor provides (the next section).

What happens to the app’s own data

A worklog report app keeps things of its own: saved reports, shared views, settings, and in some apps time or fields kept outside Jira’s work log. In the migration assistant, Assess your apps lists every installed app with its Cloud availability and its Migration path (Atlassian):

• Automated: the vendor built a path in the assistant, marked Stage 1 or Stage 2; Stage 2 apps have shown high migration success rates.
• Install-only: you install the Cloud app, and its data moves with the issues.
• View path: the vendor has a method of its own, outside the assistant.
• Upgrade app or Contact vendor: a Cloud app exists, but the path is not ready for your version, or not built yet.
• No: the app’s data cannot be migrated.

If the app only read Jira’s worklogs, the hours are safe whatever its path says: they move as Jira data. What can stay behind is the reports people saved in it. If people logged time in the app’s own screens, ask the vendor where that time is kept before you count on it arriving.

One more check: the app’s Cloud version may be built on Atlassian Connect, whose support ends on 31 January 2027. Connect end of support: what to do about your Jira worklog report says how to tell.

What Jira Cloud has in place of a worklog report

• No report of hours per person per period; the request, JRACLOUD-97253, is gathering interest.
• The Time tracking report, per version, in company-managed spaces, and on Atlassian’s list to retire (Jira’s Time tracking report).
• JQL’s worklogDate and worklogAuthor, which find issues, and an export whose Time spent is each issue’s all-time total (Jira worklog report by user and month).

Before the move, step by step

1. In the migration assistant, open Assess your apps. For the worklog report app, read its Cloud availability and Migration path, then set its decision: Needed in cloud, Not needed in cloud or Choose alternative.
2. Write down each saved report people use: its period, rows, columns and people, who it is shared with, and what gets exported and where it goes.
3. Note a closed month’s totals per person and per space from the Data Center report.
4. After a test migration, compare that month in Cloud. The worklogs are the same, so the totals should be too; where they differ, look at each person’s time zone first, then at worklogs restricted to a group or role.
5. Rebuild the dashboards and filter subscriptions the report fed.

With Logline

Logline is our app. It is a worklog report and timesheet for Jira Cloud, built on Forge:

• It reads Jira’s own worklogs, so the hours that migrated with your issues are in it from the day you install it. Apps › Logline opens on the last 30 days, and a custom range reaches back up to 400 days.
• There is no importer: you rebuild each saved report once, from the list in step 2. Coming from a Connect worklog report lists where each view of a Connect worklog report lives in Logline.
• It reads as the person viewing, with read-only permissions, and nothing leaves your Atlassian site.
• A report counts each worklog’s day in the viewer’s time zone or in each author’s, from their Jira profile, and names the time zone under its total: one more reason to have people set theirs after the move.
• It adds billable hours with their amount, hours against expected hours, gaps on working days with no time logged, and Excel export.

What it does not do: timers, approvals, logging time or grouping by version. If your Data Center app did those, look for a time-tracking app instead. More on the Logline home page.