How to change paid seats to guest seats?

[Missy]

Now that we are able to have five free guest seats for every paid seat, I'd like to swap out some of my paid seats to guests. These are seats for clients that didn't really need full access anyway.

From what I can tell, I can't just change the seat type in Settings; I have to delete the users and re-invite them as guests. Is that correct?

If so, what happens to the cards they are assigned to or are watching? Will those issues automatically re-associate with the new guest account if we recreate them using the same email address? What's the best way to handle this conversion without disrupting our clients or requiring them to reconfigure everything?

[Ollie Guan]

Hi @Missy ,

In Jira Cloud Standard, converting paid users to guests is a great way to save costs. The key is changing the "Product Role" in Atlassian Admin and restricting their access scope.

Key Rules & Limits

• 1:5 Ratio: 5 free guests for every 1 paid seat.

• Single Project: Guests are restricted to ONE project only.

• External Only: The user's email domain must differ from your organization's domain.

Official Reference

https://support.atlassian.com/jira-cloud-administration/docs/manage-guest-access-in-jira/

BTW：Atlassian official docs state: "Changing a user's role does not delete their profile or history."

As long as you convert them by changing their role rather than deleting the account, all assignments and watches will be preserved automatically because their Account ID remains the same. This is the smoothest way to handle the transition.

[Ollie Guan]

Use a personal email (e.g., Gmail) to verify the transition:

1. Setup: Invite as a User, assign issues, and add as a Watcher.

2. Convert: In admin.atlassian.com, change role to Guest and remove from the jira-software-users group.

3. Grant Access: In Project Settings > People, add the user to a Guest role.

4. Verify: Log in as the test user to confirm all assignments/watches remain, then check Billing to ensure the seat is released.

Goal: Confirms the Account ID stays linked to history while the paid license is successfully freed.

[Missy]

Thank you very much for this info, Ollie!

As the article you linked mentions, "You may not convert current or former paid users to guests. The purpose behind the guest feature is to invite users outside of your organization."

These users are outside of my organization, but they had to be added as fully licensed users to access their project to collaborate with us. I can change their permissions, but they still had to be fully licensed users. So it seems like I have to delete them and re-invite them so they can be actual free guests. Is that not correct? Am I confused? Jira is so confusing to me. 

[Missy]

Just in case it's helpful to mention, we have 16 users within my organization and 16 clients that have external email domains.

That's a lot of deleting and re-inviting. When I delete these user accounts, what happens to the issues they are currently assigned to? Do I need to manually reassign all open issues to other team members before deleting them, or does Jira handle this automatically? Will the issues remain unassigned, or is there another way this is handled?

I don't want to disrupt things with our clients, so I was hoping there was another way to convert these 16 paid users to guests. 

[Ollie Guan]

Hi @Missy ,

Try testing this with just one client account first. Remove their access, add them back as a Guest, and verify they can see their previous issues without consuming a seat. Once confirmed, proceed with the remaining 15.

Since they already have external domains, follow these steps to avoid the "delete and re-invite" cycle:

Bulk Remove Access

• Go to admin.atlassian.com → Users.

• Select the 16 clients.

• Remove their Jira Software access. They are now "unlicensed" and free up your seats.

Add as Guest in Project

• Navigate to the client's Jira project → Project settings → People.

• Click Add people and enter their emails.

• Crucial: Select Guest in the Role dropdown.

[Missy]

Hello again! 

I removed access to the Jira software app for one client, and then I changed her from a Guest to a Guest-collaborator in the project. Jira still shows that I have the same amount of active users despite removing her access from Jira software. It also shows her as 'Invited' and not 'Active' in the Users section.

I'm not sure that this method worked, but I emailed her and asked her to try to log in as usual. We'll see! It's worth a shot!

[Missy]

@Ollie Guan  Unfortunately, this did not work. The client tried to log in, and I received an email from Jira letting me know that she did not have access to any products. I had to add her back to the Jira software app, and then her only options are 'User' or 'User Access Admin'. So, she is still a paid user. 

Any other suggestions?

[Dejan V _DVLS Labs_]

Hi @Missy,

Short answer: you do not need to delete and re-invite anyone, and that is exactly what you should avoid.

The important thing is that an Atlassian account is identified by an accountId, which is global and belongs to the person, not to your site. Assignee, reporter, watchers, comments and issue history all store that accountId. So when you remove product access, or even remove the user from the site, none of those references are cleared. If you grant access to the same account again later, everything is still connected — the cards stay assigned and the history stays intact.

What actually destroys data is deleting the Atlassian account itself, which is possible for managed accounts through your organization. That triggers a personal data scrub and the display name is anonymized. This is the difference that matters here: removing access is reversible, deleting the account is not.

So the path is:

Atlassian Administration → Products → User access
Remove the paid product access from the user
Grant guest access to the same account
Same account, no re-invite, no data loss.

A few side effects worth knowing before you do it:

If a user loses browse permission on a project, they stay assigned to existing work items, but they no longer appear in the assignable-user picker.
Watchers stay on the issue, but they stop receiving notifications.
JQL and automation that match on the user keep working, because they match on accountId.
Before you convert client accounts, I would check what guests can actually do in your setup, because guest access is scoped to what they are invited to. It may be narrower than what your clients need today.

You can confirm the change in Atlassian Administration → Security → Audit log. Billing normally prorates on the next cycle.

[Missy]

Hi @Dejan V _DVLS Labs_ ,

Thank you for the additional info. I have already tried these exact steps, but as Jira’s documentation states: “You may not convert current or former paid users to guests.” I believe that’s why the process isn’t working.

I removed the client’s access to our Jira product as a User, then granted her access as a Guest (non-billable). I also confirmed she is already assigned the Guest-collaborator role in the only project she needs. Her account status is now stuck on Invited instead of Active, and when she tries to log in I receive an email from Jira saying she doesn’t have access to any Jira product.

It appears the system will not allow a former paid user to be converted to a free Guest, as their documentation states. So now I have to keep paying for all 16 client licenses, which feels pretty absurd given the free guest feature exists.

[Dejan V _DVLS Labs_]

Hi @Missy ,

You are right, and thank you for quoting the policy line — that is the part I missed in my first answer.

What you describe did not match what I expected, so before replying again I spent some time going through the guest documentation and the open tickets on jira.atlassian.com. Guest access is quite new, and the documentation around it is thin, so some of this is what I could piece together rather than settled knowledge. Two separate problems may be mixed together here, and I think the first is worth ruling out before you accept the policy as the cause.

The "Invited" status is most likely a red herring. There is an open Atlassian suggestion, JRACLOUD-98866, describing guests whose access works normally but whose status still shows "Invited" with no "Last seen" data. Guests seem to stay on "Invited" in general, so I would not read anything into that label. The login failure email is the only real signal.

Leftover permissions from the licensed period can block the guest space assignment. You mentioned she is "already assigned" the Guest-collaborator role. That is worth checking closely, because there is a known issue (CONFCLOUD-84428 — Confluence side, but the same guest mechanism) where a converted user cannot be properly added to a space because permissions from their licensed era are still in place. If that assignment is left over from when she was a licensed user, rather than added fresh after the conversion, it may not be registered as guest access at all. Removing her from the project completely and adding her again as Guest - Collaborator would rule this out.

Also, if you tested this before mid-June, it is worth one more attempt. JRACLOUD-98545 was a real bug where converting a user to Guest caused a complete loss of access with an "Access Denied" error. It was fixed on 15 June 2026.

On the policy itself, I do not want to give you false hope. Atlassian does not document what "former paid user" means in practice — whether the flag is per account, per site or per organisation, whether it ever expires, or whether removing the user from the organisation entirely changes anything. I could not find a single case of Support lifting it, and no one who confirmed a working way around it.

The feature request describing your exact situation is JRACLOUD-98504 — "Allow in-place conversion of existing licensed users to Guest role without deactivation". It is Gathering Interest with very few votes, opened by someone with the same problem: external stakeholders provisioned as licensed users before guest access existed. Worth following. One warning — it is often written as "JIRACLOUD-98504", which does not exist; the correct project key is JRACLOUD.

One supported alternative, depending on what your clients actually do: if their work is request or ticket shaped, JSM portal customers are free and unlimited, and converting licensed users to portal customers carries no equivalent prohibition. That does not help if they need to work inside normal Jira projects next to your team.

Since you are planning to convert 16 accounts, I would also ask Support in writing whether a former-paid-user flag exists on those specific accounts, and keep that answer. That information genuinely does not exist publicly, and the policy wording leaves Atlassian a lot of room — a written reply protects you either way.

[Missy]

Hi, @Dejan V _DVLS Labs_! 

This is all excellent info. Thank you for the clear explanations and instructions. I will try completely removing the client from the project and adding her back in as a guest and see if that helps anything. Fingers crossed!

Thank you for directing me to the ticket; I added my vote. It seems like an obvious issue. I hope it gains more traction!

[Dejan V _DVLS Labs_]

Good luck Missy, I hope it works!

One practical thing to watch, because this is usually where it silently fails:
removing her from the project is not enough on its own. If her account still has
Jira product access - directly, or through a default access group - she stays a
licensed user, and adding her back will just make her a regular member again.

So the order matters: remove her from the project first, then go to
admin.atlassian.com > Directory > Users, open her account and make sure Jira
product access is fully removed (including any group that grants it), and only
then invite her to the single project as a guest.

How to tell it actually worked: her account should show as a guest in the
directory, and your billable user count on the billing page should go down by
one. If the count does not drop, something is still granting her a seat.

One honest caveat, since I mentioned it earlier - the licensing terms do say a
current or former paid user should not be converted to a guest. I am not saying
this to scare you off, but I would keep a short internal note of what you did
and why, in case it ever comes up at renewal. That is really why the ticket
matters.

Let me know how it goes - I am genuinely curious whether it works in practice.

[Missy]

I think it might have worked, @Dejan V _DVLS Labs_ ! 

These are the steps I used:

1. I removed her access from the project
2. I removed her as a user in our Jira app
3. I granted her access to our Jira app as a guest
4. I added her back to the project as a guest-collaborator

She emailed me this morning and said that she was able to get into the project just fine. I looked at the billing page, and the billable amount is now 31 instead of 32. Woohoo! 

Thank you again for all of your help. 

[Missy]

Oh, and I also wanted to note that you were correct about the red herring: her status does show as invited, but she confirmed that she was able to get into the project, so that's all that matters to me. 

[Dejan V _DVLS Labs_]

That is great news, Missy - and the billing count going from 32 to 31 is the part
that actually proves it. The UI status is cosmetic, the billable number is not, so
you now have real confirmation rather than a hopeful one.

Two things worth keeping in mind, since you will probably do this again for other
clients:

The change can silently reverse itself. If that account ever ends up in a group
that grants Jira product access - a default access group, or a directory sync -
she becomes a licensed user again without anyone doing it on purpose. Checking the
billable count once a month is enough to catch it, and it takes five seconds.

There is also a ceiling on guests, so if you plan to move several clients this way,
it is worth checking the guest allowance for your plan before you start, rather
than discovering the limit halfway through.

And keep that short note about why you did it. Nothing is likely to come of it, but
if the licensing terms ever come up at renewal, a two-line record of the reasoning
is much better than trying to remember it a year later.

Glad it worked out.

[Tinker Fadoua]

@Missy 

Which Atlassian App are you having an issue with?

Best,

Fadoua