Build1 publisher2 min readPublished
Atlassian documents one of three causes behind JCMA's Custom Field Config Scheme export failure
Atlassian's knowledge base covers one of three causes of JCMA's 'couldn't export Custom Field Config Scheme' error, a dev.to post finds. The other two sit in closed bug tickets whose triggering data can still be in a Data Center database.
The Engineer · Build desk
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction
What happened
- The cause Atlassian documents is a user picker's User Filtering setting that still points at an orphaned or deleted project role ID.
- MIG-2113's first reproduction step is a null config name in the fieldconfigscheme table, followed by a project-by-project migration.
- MIG-589's log line names the context 'Default Configuration Scheme for Epic Status' and ends at a bare NullPointerException.
- Atlassian's fix for its cause is an UPDATE that points userpickerfilterrole at a real role, then a new migration for the project instead of a retry.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- decision Classifying the log line has to come before any database edit, because each of the three causes calls for a different check.
- capability Teams can sweep the whole instance for null config names before the first export attempt, instead of learning about MIG-2113 from a failed project.
- exposure Each failure stops only its own project, so a plan can land most projects in Cloud and leave one behind in Data Center.
Classify the log line before opening a SQL client. The dev.to post copies all three variants verbatim from Atlassian's own pages. It says two parts separate them: the context name in quotes and the text after "Reason:" [16]. The knowledge base cause pairs a real context name with "Parameter specified as non-null is null", thrown from ExportService.exportOrThrow [7]. MIG-2113 is the easiest to spot. The exporter prints the name it found even when there is no name, so the log reads 'null', followed by "getName(...) must not be null. [JCMA 000]" [8].
All three fail on the same kind of object. A custom field config scheme is what the Jira UI calls a custom field context: the projects and issue types a field applies to, plus its options and default value [4]. In the database it is a row in fieldconfigscheme, named in the configname column [4]. JCMA exports every context the migrating projects use. If one holds data the exporter does not expect, it throws the NullPointerException [5]. The knowledge base says JCMA "will identify that the information is corrupted and not proceed with the export of the affected projects" [6].
Atlassian's article was last updated on 26 September 2025 [2]. It ships a diagnostic query for PostgreSQL, MySQL, Oracle and SQL Server [11]. The PostgreSQL version selects from userpickerfilter, inner-joins fieldconfigscheme and customfield, and left-joins userpickerfilterrole and projectrole [11]. That query is well built for its one job. An inner join to projectrole would drop the orphan without a trace. The LEFT JOIN plus COALESCE turns it into a row labelled "Project role ID not found" [11].
It also covers only that one job. Every result starts from a User Filtering record. A null-named context with no filter never appears, and one with a filter and a live role comes back with nothing flagged [1]. The post describes where that leaves a team: the SQL finds nothing wrong, or it points at a user picker nobody has heard of, and the project still will not export [15].
The MIG-2113 data can be queried directly. Built from the ticket's reproduction step and the table layout, the check is one line: `SELECT id FROM fieldconfigscheme WHERE configname IS NULL;` [2]. The query is not Atlassian's. It finds the rows and does not repair them [2].
All of this applies to Data Center to Cloud moves. A Cloud to Cloud migration does not go through JCMA at all [14].
What to watch
- An update to Atlassian's knowledge base article that adds the MIG-2113 and MIG-589 causes and a check for each.
- Whether JCMA's pre-migration checks start flagging null configname contexts and orphaned User Filtering roles before export.
- Published cleanup steps for the 'Default Configuration Scheme for Epic Status' context behind MIG-589.