Uploaded image for project: 'Migration Platform'
  1. Migration Platform
  2. MIG-1358

JCMA Pre-flight checks should show the entities impacted by 32767 limit

XMLWordPrintable

    • 10

    • Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

      Currently JCMA can't migrate any comments, description, custom fields beyond 32767 character limit. And fails such entities with logs

      Truncated text "xxxxx -..." to cloud limit of 32767 chars

      But the pre-flight checks for JCMA don't show any such errors. 

      And the user has to find out after seeing the error that they need to follow "CommentBodyCharacterLimitExceededException: No message" or "The entered text is too long. It exceeds the allowed limit of 32,767 characters.." error message in JCMA. While it would be ideal if JCMA can handle the limit in a better way as requested at MIG-1356: Better Handle comments,descriptions greater >32767 chars. The pre-flight checks should atleast show all entities impacted by this limit before the migration. 

      This feature request is to request improvement in current pre-flight checks to capture this limit. 

        1. Team22 - Journey to Cloud - CMAs - Taronga Zoo Edition.001.jpeg
          Team22 - Journey to Cloud - CMAs - Taronga Zoo Edition.001.jpeg
          506 kB

            [MIG-1358] JCMA Pre-flight checks should show the entities impacted by 32767 limit

            Jason Wong added a comment - - edited

            The more preflight checks we add, the more it exacerbates this problem MIG-1187 - JCMA Pre-flight check for "Data preparation" takes a long time to complete" where the time taken to run them becomes a problem.

            I would first look to add this to pre-migration reports, which are 3x downloadable CSVs where a) Time taken to access these reports is optional and b) We have a lot more space in these reports to provide the entity level details on which will be truncated.

            Would that work?

            Further to this, once it is known that there will be truncation due to the limit in Jira Cloud, what course of action would a customer take? Would you reduce the data to get it below the limit, or look to other methods such as splitting the source (say comment as an example) so that the original oversized comment is replaced by multiple smaller comments but displayed in the same chronological order?

            Jason Wong added a comment - - edited The more preflight checks we add, the more it exacerbates this problem MIG-1187 - JCMA Pre-flight check for "Data preparation" takes a long time to complete" where the time taken to run them becomes a problem. I would first look to add this to pre-migration reports, which are 3x downloadable CSVs where a) Time taken to access these reports is optional and b) We have a lot more space in these reports to provide the entity level details on which will be truncated. Would that work? Further to this, once it is known that there will be truncation due to the limit in Jira Cloud, what course of action would a customer take? Would you reduce the data to get it below the limit, or look to other methods such as splitting the source (say comment as an example) so that the original oversized comment is replaced by multiple smaller comments but displayed in the same chronological order?

              Unassigned Unassigned
              1578984bf038 Hamza Tila
              Votes:
              3 Vote for this issue
              Watchers:
              7 Start watching this issue

                Created:
                Updated: