Moving from Pivot Report on Data Center to Cloud
What changes when the move is from a Data Center reporting app to Jira Cloud, and what to rebuild by hand.
Moving from Data Center is a bigger change than moving between two Cloud apps, because the Jira underneath has changed as well as the reporting app on top.
Nothing carries across automatically
Reports defined in a Data Center app live in that instance's database. There is no supported path that lifts them into a Cloud app, ours or anyone's. Plan for a rebuild.
The move assistant works from dashboard gadgets on the Cloud site. If your Jira Cloud migration brought dashboards with it, it has something to read. If you started the Cloud site fresh, it will not — rebuild from templates instead, which is quick.
Do this before the Jira migration, not after
On the Data Center side, while it is still running:
- Export every report you care about to Excel. That preserves the numbers, and the sheet is also something the move assistant can read to work out the report's shape.
- Screenshot each report's configuration. Rows, columns, measures, filters. This is the single most useful thing you can do, and it takes minutes.
- Write down which dashboards each report appeared on, and who looked at them. Most sites discover that a third of their reports were not being read.
What will be different on Cloud
| Data Center | Jira Cloud with RollGrid |
|---|---|
| Reports often run server-side, so everyone sees identical numbers | Reports run as the viewer, so numbers reflect each person's permissions |
| Reports can be scheduled and emailed | Not in this release. Reports are opened, exported or put on a dashboard |
| Field IDs and custom field IDs | Different on Cloud. Any report naming a custom field needs it re-picked |
| Practically unlimited report size | 20,000 work items by default, and it tells you when it would exceed that |
| Sub-task → story → epic, plus whatever a hierarchy plugin added | Jira's parents for free; anything above epics added as a link level |
Custom field IDs will not match
This catches everyone. A Jira Cloud migration gives custom fields new IDs. Any rebuilt report that sums or groups by a custom field has to have that field chosen again in the Cloud site — the old ID means nothing here. RollGrid's field picker lists the fields your Cloud site actually has, so you cannot pick a stale one by accident.
A workable order
- Export and screenshot everything on Data Center.
- Migrate Jira itself.
- Install RollGrid on the Cloud site and rebuild the handful of reports people really use, from templates.
- Check the totals against the exports you took.
- Rebuild the rest only when somebody asks for them. Many never get asked for.