Control chart cycle times inaccurate, very long

[Alex Eldridge]

Hello -

We migrated from server to cloud at the beginning of December.  Since migration we have seen a drastic change in our control chart with closed issues showing very long cycle times not matched with system data.  For example, an issue created November 9th 2022 as a helpdesk ticket, then moved to a project ticket and ultimately closed on  January 13th 2023 shows as being in a To Do workflow state for 2,640w, 6d, 16h and 46 m.

Has anyone else seen issues with how workflow status and cycle time are affected with a migration to cloud?  IS this a known issue and is there a fix?

Any findings would be great to hear!

[Emre Toptancı _OBSS_ · Accepted solution]

Hello @Alex Eldridge ,

I guess this is caused by a known JCMA bug.

While migrating from on-prem to cloud, all Jira entities (and especially statuses in this case) get new IDs but the IDs for changes in issue histories are not updated accordingly. In other words, histories of issues migrated from the source system are corrupted during migration. When viewed from Jira UI, issue histories seem to show correct names but actually, the IDs are inaccurate. Issues created after the migration should be fine. As a result, all reports that depend on IDs produce inaccurate results.

Below is the link to Atlassian's bug about this. I suggest you vote for it.

https://jira.atlassian.com/browse/MIG-1032

EmreT

[Alex Eldridge]

Thanks Emre - that is very helpful.  I will definitely vote for the bug.

When doing a search on this issue, I saw notices of Jira add on products to show time issues spend in different parts of the cycle.  Can these tools be used to get around the bug, or will they have the same issue because they are drawing on the underlying IDs?

[Emre Toptancı _OBSS_]

I am afraid not. My team at OBSS are the builders of one such app, Time in Status.

Jira issue histories are the only place that data about this can be found and when it is corrupt, there is nothing anyone can do. This bug also corrupts our reports.

The only way forward seems to be to consider any history-dependent stuff as "lost" and do the reporting only based on issues after the migration.

The annoying thing is, even when the bug that I sent you earlier is fixed, it will only affect new migrations. Customers naturally can't wait for this bug to be fixed to migrate to cloud. Once they've migrated, histories will already be corrupted and can't be fixed backwards.

Anyways, if you have such reporting needs, I suggest you take a look at our Time in Status. It is the oldest and the most capable one of the bunch.

https://marketplace.atlassian.com/apps/1211756/time-in-status

[Alex Eldridge]

Thanks Emre.  I was able to build a Quick Filter for issues created since our migration in Decmber and use it in the control chart.  I now see data that looks realistic for issues created in the past three months.  This gives us something to start with and will get better as time goes on.  I'll take a look at your product to see what more can be provided and consider whether to add that as well.

[Valeriia_Havrylenko_SaaSJet]

Hello @Alex Eldridge   👋

If you're looking for add-on, as an alternative, you can try Time in Status for Jira Cloud (developed by my SaaSJet team). Create the Cycle or Lead time report easily and display it on your board and export it to CSV or XLSX files for further analysis.

All you need is to:

• create a status group;
• choose statuses;
• click the "Save" button.
  
  
  
  

As an alternative, you can try a solution described in this short use case on how to get Cycle and Lead time for Jira issues. 

Also, you can read the article which describes some ways to get the Cycle time report for your issues.

Add-on has a 30-day free trial version and free up to 10 users. 
Please, let me know if you have any questions

Hope it helps 😌
Valeriia