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}}"

}

}

[Akash Singh · Accepted solution]

@Jeffrey Bistrong 

You’ll need to develop a script that can execute these actions concurrently. I’m not certain whether this level of concurrency can be effectively achieved using Postman scripts. However, if you have some familiarity with Python or JavaScript, implementing this should be quite straightforward.

Be sure to incorporate a semaphore (or similar concurrency control mechanism) to limit the number of parallel requests and prevent hitting API rate limits. It’s also recommended to implement retry logic with exponential backoff to gracefully handle situations where rate limits are exceeded.

With these optimizations in place, you should be able to build a sufficiently fast solution that can complete the entire process within an hour or less. Additionally, you can leverage an AI coding assistant or model to help you quickly generate or refine the script if needed.

[Ethann Castell]

I wonder if the Postman script could be exceeding the api rate limit?
Do you get any 429 errors or do you have anything in your test script that checks for a 429 response and then has multiple retries, for example:

if (pm.response.code === 429) {

As an alternative, you could consider exporting the data to csv, manipulate the data in excel or with a python script, and then just re-import the updated Description field.

I honestly don't know how it will perform with 130k work items - maybe do a small test first. And make sure to take a backup of your data before making any changes.

[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

[Arkadiusz Wroblewski]

@Jeffrey Bistrong 

I would be careful with external apps as the solution here. Atlassian says that once a custom field is tagged for deletion, it is also removed from automations, workflow functions, and third-party apps that use it.  

So this is really more a preserve-the-data-before-deleting-the-field task than an app problem.

Your approach of moving the values into another retained field is valid. I would just consider using a dedicated long-text archive field instead of Description, so the ticket description does not become overloaded.

If the historical values matter for audit/reporting, I would also make sure you export or back up that data before deleting the fields, since Atlassian explicitly recommends backing up Jira if you want to keep field data for historical records.