With Atlassian’s new Cloud pricing in effect from October 13, 2026 PT, user and access planning should be a core part of every Data Center–to–Cloud migration.
A common mistake: connect SCIM and sync broad directory groups before deciding who actually needs access to Jira, Confluence, Jira Service Management, or Bitbucket. Atlassian supports SCIM, but you should define your target access model first.
Why this matters
Data Center instances often contain years of accounts: active employees, former employees, contractors, service accounts, test users, and dormant accounts.
You might have 8,000 users in your directory but only 6,200 actively using Jira/Confluence. Syncing everyone can create unnecessary accounts and product access. Since Cloud billing is based on users who can access an app (even if they haven’t accepted an invite), an access review before provisioning is critical.atlassian
Typical scenarios to watch
- Former employees and dormant accounts still in the directory.
- Contractors who need access to one project for a few months, not the whole environment.
- Users who only need Confluence or only need Jira/Bitbucket, not all products.
- Phased migrations (e.g., engineering first, support later) where not every business unit needs day‑one access.
- Service accounts and integrations that appear as “users” but should be managed separately.
- Duplicate accounts for same email id.
A simple, practical approach
- Review current Data Center users, groups, product access, and activity.
- Classify users as: required now, phased, needs review, or no longer needed.
- Confirm which products each user actually needs.
- Get approval from application and business owners.
- Configure SCIM around approved groups, not the entire directory.
- After cutover, reconcile Cloud users, groups, and product assignments.
- Regularly remove dormant or unnecessary access.
SCIM is still recommended for consistent onboarding/offboarding, but it should reflect an approved access model, not mirror every directory group. Atlassian also advises planning user provisioning and SSO as part of the migration process. Atlassian License
Before enabling broad synchronization, ask:
- Who needs access on day one?
- Which users need Jira, Confluence, Bitbucket, or Jira Service Management?
- Which accounts require review or belong to later migration waves?
- How will dormant access be removed after cutover?
How are other teams classifying users and designing SCIM groups before migrating from Data Center to Cloud?
Already migrated to Cloud? Don’t stop at access cleanup.
Even after migrating to Atlassian Cloud, inactive users can continue to increase you licensed seat count, create unnecessary security risks, and drive up future renewal costs. Under Atlassian’s Maximum Quantity Billing model, your bill is based on the highest number of seats assigned during the billing cycle. That means unused licenses can still impact what you pay.
Instead of manually reviewing dormant accounts before every renewal, miniOrange User Management for Jira & Auto-Deactivation helps you automate user cleanup and optimize license usage.
With miniOrange User Management, you can:
- Automatically deactivate inactive users who have not logged in for a defined period.
- Remove inactive users from licensed groups to help free up seats and control license costs.
- Identify never-logged-in users who were invited but never accessed your Atlassian environment.
- Restore access when users return, helping maintain productivity without unnecessary manual work.
- Reduce unused license costs, strengthen access security, and stay better prepared for your next renewal.
Don’t forget: who should access what data?
Once you’ve decided who moves to Cloud, the next question is: what data should they bring?
Issues, comments, pages, and attachments often contain PII and sensitive data that:
- Increase Cloud storage and licensing costs.
- Raise GDPR/HIPAA and audit risk.
- Create unnecessary exposure if migrated as‑is.
Teams that scan and clean sensitive data before migration can reduce cost, simplify audits, and move only what’s needed.
We’ve built this capability into the miniOrange DLP Sensitive Data Scanners:
