Prior to build 14900, Additional Fields were stored in tables Workorder_Fields and Workorder_Multi_Fields,ServiceReq_id with values of picklist and multi select fields. This caused issues where if a picklist option was renamed, the new option value would not be reflected in request data created before the update. Additionally, storing additional fields data as characters instead of IDs impacted performance of the application when sorting data based on picklist values.

To address these issues, important changes were made in the application design and released in 14900. Here is the list of changes:

- Picklist options chosen for the request are stored as IDs instead of names.

- Single Line, Multiline, Picklist, and multi-select data are stored in separate tables, and sorting is not provided for multiline fields.

Issue in 14900

During the request additional field migration process in 14900, option to either migrate all tickets at once or migrate the first 25,000 open tickets first and then schedule the migration of the remaining tickets to run for 12 hours a day until all tickets are migrated can be opted.

Due to an issue in the additional field migration, if additional field migration is opted to be done fully during upgrade, only the most recent 10,000 tickets for a template would get migrated, and the rest of the data would be ignored and lost. This issue affected active/archive tickets with templates containing picklist/radio fields, multi-select fields, multiline fields, and service category-specific fields. However the request additional field migration would be successful if the migration option is opt to be done in schedule. Here is the issue Id SD-125121

Fix for the request additional field migration in 14900: