Field contexts are being demoted. Who owns your Field schemes now?

[Sami Shaik]

If your site has been through the Field schemes migration already, or is waiting for it, this question is for you.

Quick recap for anyone catching up: per Atlassian's announcement on the future of fields administration, field configuration schemes and the visibility side of field contexts are being replaced by Field schemes, with progressive rollout to all customers targeted from April 2026. Contexts stay, but only for default values and options. And the migration tool includes an auto-optimisation step that detects fields unused in a space and removes the association automatically during migration.

My situation: our organisation's policy blocks beta and EAP enrollment, so we are preparing governance for a change we cannot rehearse. We will meet the migration tool on rollout day, in production, with whatever conventions we have in place by then. That concentrates the mind. 🙂

What I am working through, and where I would genuinely value your experience:

1. Ownership. Field configuration schemes had de facto owners because creating them hurt. Field schemes look easier to create and associate. Who gets that right in your org: every Jira admin, a named platform team, or request-only through a service desk?
2. The auto-optimisation step. If a field is "unused" in a space because it is seasonal (audit season, annual planning), the migration could remove an association you actually wanted. For those already migrated: did the optimisation step behave, and did you audit its removals afterwards?
3. Naming before sprawl. We enforced naming conventions on schemes for years. What convention are you adopting for Field schemes on day one, before the sprawl starts, rather than after?

War stories from already-migrated sites are worth more than theory here. What did the migration actually do to your setup?

[Shawn Stevens]

Would your company allow you to create a sandbox (depending on your plan) and then turn the EAP or Beta on in that environment and isolate it there so you can see the changes and work through the process. 

I have the EAP on in one of the sandbox environments. I don't remember seeing the Auto-Optimization feature so I might have to look at what on our sandbox.

What I found is that, in my situation we have one setup for what we are calling System of Delivery spaces so they have the exact same setup, but what I noticed is that it wanted to create "unique" schema's. 

I would also love to hear other experiences, because this has not yet rolled out to our production environment yet. I haven't done a great job of really investigating what is on our sandbox, to many other priorities. 

[Sami Shaik]

Thanks @Shawn Stevens , and the sandbox question is the right one to ask. In our case the policy blocks EAP and beta enrollment as a category, sandbox included, so the opt-in route is closed to us. What the sandbox does give us is the Preview release track, which surfaces track-released changes a few weeks before production, and that sandbox is where we expect to see the Field schemes migration first. A look before production, not a rehearsal we can shape.

Your unique schemes observation is the one I want to underline for everyone reading. Atlassian's own announcement says you may end up with more schemes than you started with, each associated with fewer spaces. So a set of spaces that share one config scheme today can come out the other side with N near-identical Field schemes. That is exactly the sprawl question 3 is about, and it starts on migration day rather than months later. If you get a chance to count schemes before versus after on your sandbox, that number would be gold for this thread.

[Gary Spross]

We received the migration in our sandbox a couple months ago and I was worried about it getting enabled in our production instance. Playing around with the feature in the sandbox, it was pretty good. Definitely seemed more intuitive than config schemes.

We just enabled it in our production instance about 2 weeks ago. Haven't run into any problems or received any negative feedback. Fingers crossed though now that I'm saying that out loud...

[Sami Shaik]

@Gary Spross , that is the most reassuring data point in this thread, thank you: two weeks in production with no negative feedback is worth more than any doc. Two follow-ups, since you are the only one here on the far side of the migration:

1. Did you audit the auto-optimisation removals afterwards, or did the tool report what it removed in a way you could review? The seasonal-field case is what I am watching for.
2. Roughly how did your scheme count change, config schemes before versus Field schemes after? Shawn is seeing the tool want to create unique schemes for identically configured spaces, and I would love to know whether that consolidates or multiplies at scale.

[Gary Spross]

@Sami Shaik, 

1. I did not receive a report and I did not attempt to audit any removals.
   1. With fields they can remain included for convenience, not because they're actually in use. This being the case, instead of wasting my time ensuring everything was the way it had been, I put trust in Atlassian's auto-optimization tool. My calculus was that if there were complaints, I would just add the field back into the scheme.
2. There were a few schemes broken out, but not a ridiculous amount. I haven't gone through them yet to understand why exactly they got broken out.

[Shawn Stevens]

@Sami Shaik I took a look and because we don't use Context a lot, I think that minimized the number of schema's. 

Production =  16 

Sandbox = 12

The standard for most of spaces, after our Agile reset, remained the same which tells me that we didn't have any Context differences. 

The one that did cause the adjustments was an old schema for some older spaces, not in the new format, that are still being used. It look like it split that from 1 to 4 or 5. 

We don't have a lot of schemas to begin with, for our 1200 enterprise licenses, (now this is just our main instance). I have two others that I haven't turned on the EAP access. 

[Sami Shaik]

Thanks @Gary Spross , that is a useful data point in itself, a Champion running it in production for two weeks, choosing to trust the automation rather than audit it, and seeing no fallout. For most teams that is probably the right trade, and I would rather have your "nothing broke" on record here than a hundred hypotheticals. The one case I will still watch for on our side is the seasonal field, because "unused for 90 days" and "unused" are not the same thing in a bank. If you ever do spot a field that went missing from a space after the fact, this thread is the place to say so.

[Sami Shaik]

@Shawn Stevens , thank you, those are the first real numbers anyone has posted: 16 Field schemes in production, 12 in the sandbox, from a set of spaces you describe as mostly identical. That is the sprawl question 3 was about, made concrete: the tool optimised for correctness per space rather than for reuse across spaces, so you get one scheme per distinct combination even when the combinations are nearly the same. Two things I would love to know if you have a minute: how many field configuration schemes did those spaces share before migration, and do the 16 have names you can tell apart, or are they auto-generated? That second one decides whether the naming convention in question 3 has to be applied before the tool runs or can be applied after.

[Shawn Stevens]

just a correction, In production (not on the new field EAP) we have 12 schemas. In sandbox that has the EAP (we have 16), schemes. 

Example: 
Bug Field Configuration scheme (production) (39 spaces)

Sandbox:
Bug Field Configuration scheme EJMIT space (1 space)
Bug Field Configuration scheme HRP space (1 space)
Bug Field Configuration scheme XM and 36 others (37 spaces)

Same model follows: 
Scheme name with some additional details like XXX Space. 

Another example: 
Jira Service Management Field configuration scheme for project CSS (2 spaces CSS/IAM)

Sandbox, it split the scheme into two. 
Jira service management field configuration scheme for Project CSS CSS Space
Jira service management field configuration scheme for Project CSS IAM Space

For use, and I think is because we didn't use field context heavily, that most of our schemes are grouped and there are a few that have diverged. I haven't dug into the differences yet on the ones that were split out but from what I remember context would cause the difference? 

[Sami Shaik]

@Shawn Stevens , thank you, this is the most useful comment on the thread and it settles question 3 in a way I did not expect. Three things jump out of your numbers.

The tool splits by divergence, not by space count. "Bug Field Configuration scheme" went from one scheme over 39 spaces to three: two single-space splits and one covering the remaining 37. That is the migration preserving exact field visibility per space: wherever a context made a field behave differently in EJMIT or HRP, those spaces got their own scheme so nothing changed for them on migration day. Your "we didn't use contexts heavily" is exactly why most of it stayed grouped. Sites that leaned on contexts should expect far more splits.

The names are auto-generated, so naming happens after, not before. "Scheme name plus XXX space" and "XM and 36 others" are machine names. That answers my question 3: you cannot pre-name your way out of sprawl; the convention has to be applied as a rename pass after migration. The good news is the "(37 spaces)" counter gives you the audit handle for free.

The splits are your consolidation list. Every single-space scheme the tool created is a question: is EJMIT's Bug scheme actually different from the 37, or did one context option differ on one field? If it is the latter, that is a merge candidate once you have decided whether that difference was intentional. Your JSM scheme splitting into CSS and IAM is the same question at smaller scale.

When you do dig into the differences on the split-out ones, I would love to see what the actual delta was. My bet is a single field with a project-scoped context in most cases.

[Shawn Stevens]

I will try to take a look as soon as I can. 

[Ben Dangelmayr _Dangel Studio_]

The seasonal field point is the one that would worry me too. "Unused in a space" is a snapshot judgement about something that is not a snapshot property. A field that is empty in August because audit season is in February is not unused, it is just quiet, and an optimizer cannot tell the difference.

What i would want before meeting that migration in production is a baseline i can hold against the removal list afterwards: for every project, which fields actually carry data and at what rate. Then the post-migration audit is a diff instead of a guessing game. You can build a rough version natively, JQL per field with "field is EMPTY" counts, it just gets painful when the field list is long, and it is stale a week after you build it.

Since i have skin in this: i build a free app that does exactly this snapshot (Field Health, per-project fill rates). It knows nothing about schemes or contexts, so it answers none of your ownership questions, but it gives you the "which fields actually carry data" list to challenge the optimizer with. https://marketplace.atlassian.com/apps/46032572/field-health-field-completeness-score-for-jira

On ownership: my experience is that ownership followed friction. Once creating a scheme is cheap, the only thing left is convention plus a registry of record, and that is a people process, not a Jira setting. Request-only through a service desk sounds bureaucratic but it is the only variant i have seen survive longer than a year.

[Sami Shaik]

@Ben Dangelmayr _Dangel Studio_ , welcome, and thanks for being upfront about the app; that makes the point easier to take on its merits, and the merits are real. "Unused is a snapshot judgement about something that is not a snapshot property" is the best one-line summary of the seasonal-field risk on this thread.

The baseline-then-diff idea is the piece I would add to the checklist. Natively it is exactly as painful as you describe: one JQL per field per project, "Field name" is not EMPTY counted against the project total, and it is stale the week after you build it. Two things make it bearable: run it only for the fields the migration flags as removal candidates rather than the whole catalogue, and take it twice, once before and once at the seasonal peak you already know about (Shawn's audit season, a quarter-end close), so the second snapshot is the evidence you hold against the removal list.

And I agree with your last point more than the first one: the tool decides what a field configuration looks like on migration day, but who is allowed to change it afterwards is a process, not a setting. Request-only through a service desk is bureaucratic on paper and it is the only ownership model I have seen still standing a year later, because it leaves a trail.

[Julia Foden]

'Unused in a space' is what would concern me too. In a previous job I created a lot of complex automation and sometimes had to 'chain' the rules (flows) so that the completion of one rule would trigger the next. (This could be because I had reached the maximum number of rule components (steps) or because you can't branch on a branch). I would accomplish the chaining by setting a field value as the last step in the first rule, and the second rule would be triggered by that field value being set. The final step in the second rule would wipe the field. The field did not appear on any screens in the space.

So this field that I used for chaining was an essential part of automations that were themselves part of essential business processes. But the field only ever held a value momentarily - for the length of time it took for the automation rule to run!

If I was still working there I would be very concerned about this. I would also be concerned about the new automation usage pricing but that's another story ;) 

[Sami Shaik]

@Julia Foden , that is the sharpest example on this thread of why "unused in a space" is the wrong test, because your chaining field is not seasonal, it is transient by design: it holds a value for the length of one rule run and is empty at every other moment, so any snapshot, before or after migration, shows it as unused while it is load-bearing for a business process. It also never appears on a screen, so the screen-based audit misses it too.

The audit that catches it is not "does this field have values" but "is this field referenced by an automation rule." Natively, that is an export of the rules to JSON (global Automation, Export) and a search for the field's customfield_ ID; anything that turns up is off limits regardless of what the migration flags. I would add that to Ben's baseline as a third column: fill rate, seasonal peak, and referenced-by-rule. If you have a name for the pattern, I would happily credit it; "chaining field" is what I have been calling it too.

[Hugo Mora]

Hi @Sami Shaik 

Since your constraint is that you can't rehearse, I'd focus everything on the one thing you can do without EAP access: capture the before state while it still exists.

The reason your question 2 is hard is that you're depending on the tool to tell you what it removed. You don't have to. Before migration day, dump the current model to files and commit them somewhere:

• /rest/api/3/fieldconfigurationscheme and /fieldconfigurationscheme/project — schemes and their project associations
• /fieldconfigurationscheme/mapping — scheme to configuration per work type
• /fieldconfiguration/{id}/fields — the hidden/required flags per field
• /field/{fieldId}/context — contexts and their project scoping

That's an afternoon of scripting and it turns the auto-optimisation question into a diff rather than a trust exercise. Re-pull the equivalent after migration, compare, and you have an exact list of associations that disappeared — including the seasonal ones, whether or not the tool reported them.

On the seasonal case specifically: build that list before migration, not after. A query per candidate field for "has ever been populated in this project, at any point in history" gives you a small set of fields that would look unused in whatever recency window the optimiser uses but matter annually. In every instance I've audited, that list is short — audit flags, annual planning fields, a compliance date or two. Short enough to hand-check on day one.

On ownership (Q1): worth naming the actual mechanism you're losing. Field configuration schemes had owners because creating them hurt — the friction was the governance. Removing the friction doesn't create a need for an approval process, it creates a need for detection. A scheduled job that counts schemes weekly and flags new ones costs you nothing in delivery speed and catches sprawl in days. Approval queues catch it too, but you pay for that in every legitimate request forever.

On naming (Q3): the twist here is that you don't get to name the schemes the migration creates. So design the convention around that: a prefix or marker that means "curated and reviewed by us", with everything unmarked treated as migration output awaiting consolidation. Then your cleanup backlog generates itself, and Shawn's near-identical-schemes problem becomes a visible queue rather than an archaeology project in 2027.

Cheers,

--Hugo

[Sami Shaik]

@Hugo Mora , this is the most useful thing anyone has posted on this thread, and I want to say why before I add to it. Every earlier answer, mine included, was about what to do after the tool reports; yours removes the dependency on the report altogether. If the before-state is in files, the optimiser's summary becomes a diff you check, not a claim you trust. Five endpoints and an afternoon is a cheap price for that.

Two additions from having run similar dumps:

1. Add the screen schemes to the dump. /rest/api/3/screenscheme and /issuetypescreenscheme (with their project mappings) are not part of what the field migration touches, but they are where a "removed" field configuration association shows up as a user-visible symptom, because a field that lost its configuration still sits on a screen and now renders with default behaviour. Diffing field configurations alone tells you what changed; diffing the screens alongside tells you where users will see it.
2. On the seasonal query: agree it is short, and I would make it shorter still by scoping "has ever been populated" to the space rather than the site, because a field that is annual in one space and dead in another should stay flagged for the dead one. Ben's fill-rate baseline earlier in the thread and your "ever populated" query are the same idea at two resolutions; together they are the pre-migration list.

On detection versus approval: you have changed my mind on the mechanism, if not on the outcome. I had been arguing for request-only ownership; your point that the friction was the governance, and that removing friction creates a need for detection rather than a queue, is right, and cheaper. A weekly scheduled rule that counts schemes and posts the delta to an admin channel is ten minutes to build. The place I would still keep a human gate is not creation but deletion: an automated cleanup that removes a scheme the detector considers idle is the one action that cannot be undone from a dump.

I am collecting this thread into a follow-up article once the platform migration settles; with your permission I will credit this method by name.

[Hugo Mora]

Thanks @Sami Shaik  — and your framing of it is better than mine was. "A diff you check, not a claim you trust" is the whole idea in one line, and it generalises past this migration: any vendor-run change you can't rehearse, the report tells you what the tool believes it did.

Four things I'd add, because they're what makes the difference between a snapshot and a usable one:

Pagination will bite you. Those endpoints page at 50 by default. It's easy to capture two-thirds of an instance and not notice until you're diffing. Assert the returned total against your collected count and fail loudly if they disagree.

Sort before you write. API response ordering isn't guaranteed, so sort by ID and serialise deterministically. Otherwise your diff is 90% noise and you'll stop reading it.

Snapshot the project list alongside it. The scheme endpoints return project IDs, not keys. If a project gets renamed or archived between your two captures, the diff becomes unreadable exactly when you need it.

Capture twice. Once now, once as close to rollout as you can get. Config drifts in between, and with only one baseline you'll spend the post-migration review arguing about whether the tool did something or a colleague did.

And a request, since your policy puts you in an unusually rigorous position: if you do run this, a redacted before/after diff — association counts, scheme counts, and what the optimiser dropped — would be the single most useful artefact anyone could post here. Gary and Shawn have the experience; nobody yet has the numbers.

Cheers,

--Hugo

[Sami Shaik]

@Hugo Mora , all four go straight into the runbook, and the pagination one is the trap I would have walked into: a two-thirds snapshot that diffs cleanly against another two-thirds snapshot is worse than no snapshot, because it looks complete. Asserting the returned total against the collected count and failing loudly is the right shape. Sorting by ID before serialising and capturing the project list alongside (IDs, not keys, on the scheme endpoints) are the two that turn a dump into something a second person can read. Capture twice is the one that settles the argument you describe, and I have seen that exact argument.

On the request: yes. I will run the capture on a site I control, once now and once as close to rollout as the release track allows, with the assertions and sorting you describe, and post a redacted before and after here: scheme count, association count, contexts per field, and the list of what the optimiser removed against what the dump says existed. No client data, keys anonymised. If the numbers say the tool was right, that gets posted too; the point is the diff, not the verdict.

I will credit the method to you when it goes into the follow-up article. Thank you for turning a governance question into a measurement.