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.