Solution for Deleting Custom Fields and Preservation of Values in the Ticket Description

[Jeffrey Bistrong]

I am working on cleaning up old unused fields in jira. Our company acquired 3 companies over the past 4 years and there are tons of fields that are not used anymore. We want to preserve the values. The solution I came up with is to append the description field at the end with the values I want to preserve. 

See image below for example. 

My solution to do this is using postman to grab the description field as well as the values I want to preserve and then via the API and Postman's test scripts feature make the modifications to the description field. This works well, however it takes a long time (2 hours to update 6,000 tickets) because its making 2 calls, first to read the data and store them into variables, make the modifications and then the put call to put newly updated description. 

I have to update 130k+ values via this method and this would take 45 hours to complete. Looking for solutions to help accomplish this faster. 

Below are my API calls as well the the post-response scripts just in case anyone wants to see the details of what I am doing

1. get all values

https://xxxxx-sandbox.atlassian.net/rest/api/2/issue/{{issueKey}}?fields=description,customfield_12131,customfield_12119,customfield_12117,customfield_12107,customfield_12092,customfield_12127,customfield_12129,customfield_12100,customfield_12125,customfield_12123,customfield_12113

Post Response Script

const response = pm.response.json();

const f = response.fields;

// 1. Capture existing description safely

let existingDesc = "";

if (f.description) {

// If it's a string, use it; if it's an object (ADF), try to extract text or note it

existingDesc = typeof f.description === 'string' ? f.description : "--- Existing Rich Text Description Above ---";

}

// 2. Mapping IDs to your specific "old_" labels

const migrationMap = [

{ id: "customfield_12131", name: "old_closed_date" },

{ id: "customfield_12119", name: "old_intial_estimate" },

{ id: "customfield_12117", name: "old_milestone" },

{ id: "customfield_12107", name: "old_module" },

{ id: "customfield_12092", name: "old_project_id" },

{ id: "customfield_12127", name: "old_resolution" },

{ id: "customfield_12129", name: "old_resolution_desc" },

{ id: "customfield_12100", name: "old_severity" },

{ id: "customfield_12125", name: "old_status" },

{ id: "customfield_12123", name: "old_ticket_number" },

{ id: "customfield_12113", name: "old_version" }

];

// 3. Extract values and format the block

let migrationText = "\n\n--- MIGRATED FIELD DATA ---";

let hasData = false;

migrationMap.forEach(item => {

let val = f[item.id];

if (val !== null && val !== undefined && val !== "") {

// Handle Jira objects (Dropdowns, Labels, etc.) vs Strings

let displayVal = (val && typeof val === 'object') ? (val.value || val.name || JSON.stringify(val)) : val;

migrationText += `\n${item.name}: ${displayVal}`;

hasData = true;

}

});

// 4. Update the variable for the next request

// If no data was found in the 11 fields, we keep the original description

let finalDesc = hasData ? (existingDesc + migrationText) : existingDesc;

pm.collectionVariables.set("new_description", finalDesc);

// ... (previous logic for building finalDesc stays the same)

// 4. Update the variable for the next request

// We use JSON.stringify and then slice off the quotes to ensure

// all newlines are escaped correctly as \n

let escapedDesc = JSON.stringify(finalDesc).slice(1, -1);

pm.collectionVariables.set("new_description", escapedDesc);

2. PUT https://XXXXX-sandbox.atlassian.net/rest/api/2/issue/{{issueKey}}

body of the call

{

"fields": {

"description": "{{new_description}}"

}

}

[Benjamin]

HI @Jeffrey Bistrong ,

Have perform various solution in the past whether putting them in description or notes or some kind of long text field for the sake of retaining information that usually is not use but just in case. Or sometimes there's a team that suddenly wants the field back for ease of searching and narrowing ticket scope. 

I find it's easier to hide the fields and keep track later to clean it up when no active projects use them. At that point, delete them for good if it aligns with organizational policies. Before, then have the opportunity to unhide them to rollback if neccessary. The main thing to consider how many field configuration schemes are there and is it feasible. 

Of course, this is a very simplistic approach but there's other angles to consider. like moving to another field instead that's basically use very often and doing the same exact thing. Or finding a field hardly used and talking the stakeholders to get approval for deletion. 

One thing to note, you may want to move it another field other than description incase the original description gets bloated because of the all field values. You may want to add it to a field, for example, additional info and add it to another tab so it doesn't get in the way of existing tickets. More of background infomation if anyone wants to see it. 

-Ben