Feature spotlight
In This Blog
An custom field usually isn’t unsecured on purpose.
Someone added a Salary or Contract Value field to a project years ago, before anyone thought about who else could see it. By the time it becomes a problem, the field has screens attached, historical data in hundreds of issues, and no admin wants to touch it. Recreating it from scratch means rebuilding every screen association and finding a way to backfill the data without breaking reports.
Secure Custom Fields for Jira handles that migration directly.
From the app’s homepage, an admin selects Migrate, picks the existing custom field, and maps it to a new secured field, keeping the original name or renaming it.
A checkbox controls whether existing data comes along for the ride, and that choice can still be changed on the review screen before anything is confirmed.
Screen associations carry over automatically, so there’s no separate step to reattach the field to its projects.
Picture a Jira admin who’s been asked, again, why the Contract Value field on the Legal team’s projects is visible to the whole company. Instead of scheduling a project to rebuild it, she opens the migration wizard, selects the field, checks the box to bring the data along, and confirms. A few minutes later, the same field (same name, same history) only shows values to Legal. No screen rework, no re-entering two years of contract amounts, no separate cleanup project.
This is the fastest path from “we should really lock that down” to actually doing it; Which matters most for the fields that have been exposed the longest, since those are usually the ones nobody wants to rebuild.
The migration wizard is currently in beta, with a cap of 25 fields migrated per rollout. For the full walkthrough (including how field mapping and the data-migration checkbox work) see How to migrate custom fields to Secured Custom Fields.
Not using Secure Custom Fields for Jira yet? Start a 30-day free trial to see how it works on your own custom fields.