In most migration plans, users are the last chapter
With Data Center support set to end on 28 March 2029, many organizations have started planning their move to Cloud. Open one of those plans and the running order is usually the same: app compatibility, the list of projects and spaces, custom fields and workflows, the schedule and the cutover weekend. Users and groups tend to sit near the back, as a single page.
That order is backwards. Tools move the data. Cleaning up users is a judgement task — and judgement takes people and time. You cannot ask "does this person still need an account?" on cutover weekend.
First, a common misconception
You often hear that inactive accounts sitting in Data Center will simply turn into Cloud billing. That is only half true.
According to Atlassian's documentation, users who are disabled on your Data Center site are migrated as accounts, but without product access — and those accounts are not counted towards your billable Jira users.
In other words, users properly disabled in Data Center are generally migrated without product access and do not count toward billing. Existing Cloud accounts that already have product access should be reviewed separately.
The problem is on the other side.
The real exposure is the accounts nobody disabled
1. Accounts still active because no one got round to them
Leavers, contractors whose contracts ended, people from projects that closed. A large share of them were never marked inactive and are still active in Data Center — because creating an account is always urgent and reclaiming one never is.
These accounts look exactly like legitimate active users. They can carry unnecessary access into Cloud and become billable once that product access is applied. The migration does not create the problem; it converts deferred cleanup into an invoice.
2. Duplicate email addresses — often found among leavers and external collaborators
Cloud does not support duplicate email addresses, and Atlassian lists this as a mandatory preparation step. It is not optional: leave it and the migration does not proceed.
And duplicates tend to come from the same two places.
Leaver accounts. Many organizations keep accounts rather than deleting them, which is the right call if you want to preserve history. It becomes a problem when that person is rehired, or moves to an affiliate and comes back. A second account appears under a new employee number, with the same email address. The older the instance, the more of these pairs have piled up.
External collaborator accounts. When a partner contact, consultant or outsourced developer needs access quickly, people rarely wait for a corporate account — they invite a personal address or a partner domain first. When the proper account is issued later, a second account appears, and the first one is never removed. The contact changes; the account stays.
In both cases, IT cannot decide alone whether two accounts are the same person. That question goes to HR or to the business, and answers take days. External collaborators are harder still: the person who could confirm may have left, or the contract itself may have ended, leaving no one to ask.
Which is why this cannot be touched just before cutover. Producing the list of duplicates takes a day. Adjudicating it takes weeks.
3. Group name conflicts — matching can widen access
If a group with the same name already exists in Cloud, migrated users are matched into that existing Cloud group. If the memberships or permissions differ, users may end up with unintended access. Atlassian lists this as a mandatory preparation step too.
The name match itself is not the problem. The risk is failing to review the resulting membership and permissions. If a group called developers existed on both sides with different members, the resulting access may be broader than either side intended. Unless you reconcile names and membership beforehand, you may not discover the issue until after the migration.
4. At scale, moving users is a project of its own
Atlassian recommends that instances with more than 2,000 active and inactive users migrate users and groups separately, ahead of the data, to cut down the work on cutover day. Above 1,000 users, they recommend working with a Cloud specialised partner.
It is worth noting that the threshold counts active and inactive users together. Accounts you never cleaned up do not just cost money — they add to the migration workload itself.
So we suggest reordering the plan
60 days before cutover — build the picture
Split the full user list by type: permanent employees / contractors / system accounts / unclassified
The unclassified column matters most. Its size determines how much time you are about to spend
Pull last-login dates alongside it. Count how many sit beyond six months and beyond twelve
Scan for duplicate emails and group name conflicts now. They are mandatory items, so there is no reason to defer them
Send the duplicate list to HR and the business the moment you have it. Rehire cases and external collaborator accounts often take the longest to resolve
30 days before cutover — set the criteria and get them approved
Document reclamation criteria per user type: "permanent employees, twelve months without a login", "contractors, at contract end"
Once approved, case-by-case judgement disappears. That is what determines how fast the cleanup runs
Disable accounts that meet the criteria rather than deleting them. As above, disabled users are generally migrated without product access, allowing you to preserve history without carrying unnecessary product access into Cloud
Send only the genuinely ambiguous accounts to the business for confirmation. That list has to be short enough to answer inside 30 days
Cutover — verify only
Check the number of users being migrated and the number receiving product access separately. They are different numbers
Check the membership and permissions of matched groups
Do not do cleanup work at this point
The same problem builds up again after the migration
One more thing worth noting: a pre-migration cleanup is a one-time event. If it remains just that, the same backlog can build up again within two or three years. In Cloud, creating an account is still urgent, while reclaiming access rarely is.
The difference is that in Cloud, that gap directly affects your subscription cost and the user tier you need.
That is why user cleanup needs to become an ongoing operational process, not a one-time task. Three things make that possible:
A clear view of user types and last activity at any time
Defined reclamation criteria for each user type
A workflow that automatically identifies and acts on accounts that meet those criteria
As the organization grows, it becomes increasingly difficult for administrators to manage all three manually. One option is to use Marketplace apps that support automated license management, giving administrators a clear view of usage and helping them continuously manage inactive users based on predefined policies.
Flexible User License is built to automate user and license management across Jira and Confluence. Before migration, it can help identify users and access that need to be cleaned up. After migration, it helps prevent the same backlog from building up again by supporting ongoing license governance.In short
Move the user section of your migration plan from the back to the front. The reason is simple.
Tools migrate data. People clean up users. And anything people do needs lead time.
Users properly disabled in Data Center are generally migrated without product access. The risk is the accounts nobody has touched yet. Pulling that list is where this starts.
Sources
Atlassian Support
In most migration plans, users are the last chapter
With Data Center support set to end on 28 March 2029, many organizations have started planning their move to Cloud. Open one of those plans and the running order is usually the same: app compatibility, the list of projects and spaces, custom fields and workflows, the schedule and the cutover weekend. Users and groups tend to sit near the back, as a single page.
That order is backwards. Tools move the data. Cleaning up users is a judgement task — and judgement takes people and time. You cannot ask "does this person still need an account?" on cutover weekend.
First, a common misconception
You often hear that inactive accounts sitting in Data Center will simply turn into Cloud billing. That is only half true.
According to Atlassian's documentation, users who are disabled on your Data Center site are migrated as accounts, but without product access — and those accounts are not counted towards your billable Jira users.
In other words, users properly disabled in Data Center are generally migrated without product access and do not count toward billing. Existing Cloud accounts that already have product access should be reviewed separately.
The problem is on the other side.
The real exposure is the accounts nobody disabled
1. Accounts still active because no one got round to them
Leavers, contractors whose contracts ended, people from projects that closed. A large share of them were never marked inactive and are still active in Data Center — because creating an account is always urgent and reclaiming one never is.
These accounts look exactly like legitimate active users. They can carry unnecessary access into Cloud and become billable once that product access is applied. The migration does not create the problem; it converts deferred cleanup into an invoice.
2. Duplicate email addresses — often found among leavers and external collaborators
Cloud does not support duplicate email addresses, and Atlassian lists this as a mandatory preparation step. It is not optional: leave it and the migration does not proceed.
And duplicates tend to come from the same two places.
Leaver accounts. Many organizations keep accounts rather than deleting them, which is the right call if you want to preserve history. It becomes a problem when that person is rehired, or moves to an affiliate and comes back. A second account appears under a new employee number, with the same email address. The older the instance, the more of these pairs have piled up.
External collaborator accounts. When a partner contact, consultant or outsourced developer needs access quickly, people rarely wait for a corporate account — they invite a personal address or a partner domain first. When the proper account is issued later, a second account appears, and the first one is never removed. The contact changes; the account stays.
In both cases, IT cannot decide alone whether two accounts are the same person. That question goes to HR or to the business, and answers take days. External collaborators are harder still: the person who could confirm may have left, or the contract itself may have ended, leaving no one to ask.
Which is why this cannot be touched just before cutover. Producing the list of duplicates takes a day. Adjudicating it takes weeks.
3. Group name conflicts — matching can widen access
If a group with the same name already exists in Cloud, migrated users are matched into that existing Cloud group. If the memberships or permissions differ, users may end up with unintended access. Atlassian lists this as a mandatory preparation step too.
The name match itself is not the problem. The risk is failing to review the resulting membership and permissions. If a group called developers existed on both sides with different members, the resulting access may be broader than either side intended. Unless you reconcile names and membership beforehand, you may not discover the issue until after the migration.
4. At scale, moving users is a project of its own
Atlassian recommends that instances with more than 2,000 active and inactive users migrate users and groups separately, ahead of the data, to cut down the work on cutover day. Above 1,000 users, they recommend working with a Cloud specialised partner.
It is worth noting that the threshold counts active and inactive users together. Accounts you never cleaned up do not just cost money — they add to the migration workload itself.
So we suggest reordering the plan
60 days before cutover — build the picture
Split the full user list by type: permanent employees / contractors / system accounts / unclassified
The unclassified column matters most. Its size determines how much time you are about to spend
Pull last-login dates alongside it. Count how many sit beyond six months and beyond twelve
Scan for duplicate emails and group name conflicts now. They are mandatory items, so there is no reason to defer them
Send the duplicate list to HR and the business the moment you have it. Rehire cases and external collaborator accounts often take the longest to resolve
30 days before cutover — set the criteria and get them approved
Document reclamation criteria per user type: "permanent employees, twelve months without a login", "contractors, at contract end"
Once approved, case-by-case judgement disappears. That is what determines how fast the cleanup runs
Disable accounts that meet the criteria rather than deleting them. As above, disabled users are generally migrated without product access, allowing you to preserve history without carrying unnecessary product access into Cloud
Send only the genuinely ambiguous accounts to the business for confirmation. That list has to be short enough to answer inside 30 days
Cutover — verify only
Check the number of users being migrated and the number receiving product access separately. They are different numbers
Check the membership and permissions of matched groups
Do not do cleanup work at this point
The same problem builds up again after the migration
One more thing worth noting: a pre-migration cleanup is a one-time event. If it remains just that, the same backlog can build up again within two or three years. In Cloud, creating an account is still urgent, while reclaiming access rarely is.
The difference is that in Cloud, that gap directly affects your subscription cost and the user tier you need.
That is why user cleanup needs to become an ongoing operational process, not a one-time task. Three things make that possible:
A clear view of user types and last activity at any time
Defined reclamation criteria for each user type
A workflow that automatically identifies and acts on accounts that meet those criteria
As the organization grows, it becomes increasingly difficult for administrators to manage all three manually. One option is to use Marketplace apps that support automated license management, giving administrators a clear view of usage and helping them continuously manage inactive users based on predefined policies.
Flexible User License is built to automate user and license management across Jira and Confluence. Before migration, it can help identify users and access that need to be cleaned up. After migration, it helps prevent the same backlog from building up again by supporting ongoing license governance.In short
Move the user section of your migration plan from the back to the front. The reason is simple.
Tools migrate data. People clean up users. And anything people do needs lead time.
Users properly disabled in Data Center are generally migrated without product access. The risk is the accounts nobody has touched yet. Pulling that list is where this starts.
Sources
Atlassian Support
https://support.atlassian.com/migration/docs/migrate-users-and-groups/
https://support.atlassian.com/migration/docs/clean-up-your-server-instance-before-migration/
https://support.atlassian.com/migration/docs/determine-your-user-migration-strategy/