Jira Server to Cloud Migration: Class Cast Exception

[Brock Price]

Our small trial migration from server to cloud keeps failing (for all issues) with this error (below).  What is happening?

2022-06-16 19:22:17.147 ERROR TDP project-export We couldn't export Issue TDP-28. Reason: java.lang.ClassCastException: java.util.Date cannot be cast to java.sql.Timestamp.

[nojansen · Accepted solution]

I am in the process of migrating a large Jira Server site to Jira Cloud.

2 months ago I was able to migrate a specific project to Jira Cloud without any issues (besides certain custom fields being excluded from the migration).

Now I am trying to migrate the project again, and it is failing with the same error for each issue:

2022-06-18 12:09:42.339 ERROR XYZ project-export We couldn't export Issue XYZ-14780. Reason: java.lang.ClassCastException: java.util.Date cannot be cast to java.sql.Timestamp.

 Comparing the pre migration reports from both migrations, I see that more custom fields are included in the migration since updating various plugins, including Jira Cloud Migration Assistant.

One of the fields which is now migrated is of the type "Last public comment date" and is from the Jira-Toolkit.

I think this is the cause of the issue, but I cannot be sure as the logs are not detailed enough.

[Brock Price]

I was able to run my first successful (small test) migration in PROD by disabling the custom fields Days Since Last Comment and Last Public Comment Date.  I'm not sure if both of these fields are problematic. I'll be running additional tests.  But at least this gets us past the big, initial roadblock.  Thanks.

[nojansen]

Hi Brock,

Yes, after contacting Atlassian support, I ended up doing the same and the migration worked.

Atlassian support mentioned that as these fields use an issues meta data, if you re-enable them on the Cloud you won't lose any data, however you will have a field with a new ID, so you may need to update any relevant filters.

[Prince Nyeche]

The error seems to be that it cannot convert the datetime that you're using on a field on that TDP-28 issue key. You have to check out the kind of data that's there and probably change it so it is something that Jira can understand. A list of acceptable datetime follows this mechanism in Java format. 

[Brock Price]

Thank you. I assume it would have to be a populated field (is that a big assumption?). So when I do a full JQL CSV export of the issue, I can see all the fields that have data for the issue.  I see a scripted field named "Time Open" that returns: "9 weeks, 2 days, 1 hour, 22 minutes".  Could this be the culprit? How could I even test to identify?

Thanks again.

[Prince Nyeche]

Yes, that would most probably be it. The datetime value should be  a string in UTC or probably any other compatible datetime format rather than that. Try changing the value and perform a single import to be certain.

[Brock Price]

I tried turning that field off, but I still see the error. I tried turning off a couple other fields, but the error still persists. I'm surprised by the lack of a specific error code. If only Jira specified the field (or fields) that cannot be converted/migrated, I'd be able to address the problem.