Handling User Identity Changes in Atlassian: From Data Center to Cloud

The Challenge

Imagine this scenario: Sarah Johnson gets married and becomes Sarah Martinez. Her email changes from sarah.johnson@company.com to sarah.martinez@company.com. Without proper configuration, your Atlassian systems might:

• Create a completely new user account for "Sarah Martinez"
• Lose all historical associations with tickets, comments, and projects linked to "Sarah Johnson"
• Generate provisioning errors and duplicate accounts
• Create confusion across teams about which account is current

The root cause? Most default configurations match users based on mutable attributes like email addresses or usernames, rather than using persistent, unchanging identifiers.

The Data Center Story: Why Your Library Card Number Matters More Than Your Name

Let me tell you a story that perfectly illustrates why proper user identification matters. While the company and people are fictional, this scenario has played out countless times in organisations running Atlassian Data Center products—whether Jira, Confluence, Bitbucket, or Bamboo—as well as those using Atlassian Crowd for centralised user management. All of these products rely on the same underlying user directory mechanism (Embedded Crowd), so they all face the same challenge.

The Wedding Announcement Turned IT Nightmare

Sarah Johnson was a lead developer at a mid-sized tech company, with three years of history across Atlassian products behind her — hundreds of Jira tickets created, thousands of Confluence pages and comments, Bitbucket repositories she maintained, custom filters, project permissions, and boards she managed. One Monday morning, she sent an email to IT: she'd gotten married over the weekend and needed her username updated from sarah.johnson to sarah.martinez.

The IT administrator, thinking it was straightforward, updated her username in Active Directory. The next morning, chaos erupted. Sarah opened Jira and found herself looking at a completely blank slate — no tickets assigned to her, no history, nothing. When she checked Confluence, all her page contributions showed the old username. In Bitbucket, her repository permissions seemed intact, but her commit history attribution was disconnected. All her work from the past three years seemed fragmented across the Atlassian suite.

Meanwhile, the development team was confused. Who was this "sarah.martinez" person in their standup board? And why were all of Sarah's old tickets still showing "sarah.johnson" as the assignee—someone who apparently no longer existed in the system?

The Library Card Analogy

Think of it like a library system. When you get a library card, you receive a unique card number — let's say #847293-A11B2-C3D4. That number never changes, even if you move houses, change your phone number, or change your name. The library uses that card number to track which books you've checked out, your borrowing history, any fines you owe, and your reservation queue.

Now imagine if the library identified you only by your name and address. When you moved or changed your name, the library would think you were a brand new patron. Your borrowing history? Gone. Those books you had checked out under your old name? The system would show them as checked out to someone who no longer exists, triggering overdue notices to an old address. The reservation you'd been waiting six months for? It would go to the "new" you at position #247 in the queue, not to the "old" you who was next in line.

That's exactly what Atlassian Data Center products did when configured to identify users by their username or email instead of by their unique, immutable identifier—the objectGUID from Active Directory.

Understanding the Data Center Approach

In Data Center environments (and Atlassian Crowd), the solution was to configure the user directory to use the equivalent of a "library card number" — the objectGUID from Active Directory. This unique identifier is assigned when an account is created and never changes, regardless of what happens to the username, email, or any other attribute.

When properly configured with objectGUID as the "User Unique ID Attribute," all Atlassian Data Center products could understand that sarah.martinez was the same person as sarah.johnson. The system would seamlessly preserve all history, tickets, pages, permissions, and contributions during name changes — just like a library tracking your borrowing history through your card number, not your name.

For organisations still running Data Center products or Crowd, this configuration was essential. But with Atlassian's announcement of Data Center's end-of-life, most organisations have either already migrated to Atlassian Cloud or are in the process of planning their migration right now.

Moving to Atlassian Cloud: The Same Problem, A Different Solution

This understanding of immutable identifiers was hard-won knowledge for Data Center administrators. But here's where the story takes an unexpected turn: as organizations migrate to Atlassian Cloud with Guard and Microsoft Entra ID, many IT teams are discovering that this critical lesson doesn't automatically carry over. In fact, the default Cloud configuration can recreate the exact same duplicate user problem — the library card issue all over again.

The Documentation Gap

Both the Atlassian Knowledge Base article on Guard attribute mappings and Microsoft's Entra ID provisioning tutorials focus primarily on mapping name, email, and UPN attributes. What they fail to emphasise is the critical importance of the Matching Precedence setting.

The Problem with Default Settings

By default, Atlassian Cloud's SCIM provisioning uses UPN or email (with matching precedence set to "1") to determine if a user in your identity provider matches an existing account. Here's what goes wrong:

When Sarah Johnson becomes Sarah Martinez and her UPN/email changes, the next provisioning run searches for sarah.martinez@company.com in Atlassian Cloud. It doesn't find a match because only sarah.johnson@company.com exists. So what does it do? It attempts to create a brand new account.

The result? Either a duplicate user account or provisioning errors like:

Resource [USER]: with email[sarah.martinez@company.com] already exists.

It's the library card problem all over again—but this time in the cloud.

The Correct Configuration for Atlassian Cloud

To prevent this scenario, you need to configure Entra ID's SCIM provisioning to use a persistent, unique identifier:

1. Map to a Persistent Identifier In your Entra ID provisioning attribute mapping, ensure that the user's objectId (the immutable unique identifier in Entra ID—essentially the cloud equivalent of objectGUID) is mapped to the externalId attribute in Atlassian's SCIM schema.

2. Set the Matching Precedence This is the critical step that both Microsoft and Atlassian documentation gloss over: Set the Matching Precedence to "1" on the objectId/externalId mapping. This makes Atlassian Cloud use this persistent ID for identity matching instead of email or UPN.

With this configuration, even when Sarah's email and UPN change, her objectId remains constant—just like her library card number. Atlassian Cloud will correctly identify her as the same user and simply update her email and name, rather than creating a duplicate account.

Getting Your Cloud Migration Right From the Start

Whether you're dealing with existing duplicate users, planning your migration to Atlassian Cloud, or already running Cloud but want to ensure your configuration is optimal, these nuances in identity management can make or break your user experience.

At Ambientia, we specialise in Atlassian Cloud migrations and understand the critical details that official documentation often overlooks — like the matching precedence configuration we've discussed here. We've helped numerous organisations transition from Data Center to Cloud while avoiding common pitfalls like duplicate users, lost historical data, and provisioning errors.

How We Can Help

Our Atlassian Cloud migration services include:

• Pre-migration assessment of your current user directory configuration and identification of potential issues
• Proper identity mapping setup ensuring objectId/externalId matching is configured correctly from day one
• Duplicate user remediation working with you and Atlassian Support to clean up any existing issues
• SCIM provisioning configuration with Entra ID (Azure AD) or other identity providers
• Post-migration validation to ensure user updates flow seamlessly without creating duplicates
• Ongoing support for user management and directory synchronisation best practices

Don't let technical oversights in identity management create frustration for your teams or headaches for your IT department. The "library card number" principle we've discussed here is just one of many critical configuration details that need attention during a cloud migration.

Ready to ensure your Atlassian Cloud migration is done right? Contact Ambientia today to discuss your migration plans or to get help resolving existing user provisioning issues. We'll make sure your users' identities—and their valuable work history—are preserved seamlessly in the cloud.

About the Author and Development Team

This article was written by Rafael Pinto Sperafico, Senior Atlassian Consultant at Ambientia, who brings extensive expertise in Atlassian DataCenter platform architecture and enterprise integration patterns.

The insights shared here are built on the foundational work of Antti Salo, whose expertise and attention to detail have been instrumental in uncovering critical edge cases in modern cloud identity management. Antti was the first to spotlight the risks of duplicate user provisioning due to misconfiguration between Entra ID and Atlassian Guard. As organisations push for seamless SSO and user automation, Antti identified that matching on mutable attributes like email or UPN alone can yield organisational disruptions: when users undergo personal changes — like a surname update — misaligned attribute mappings often lead to duplicate accounts and downstream access issues, a scenario too often overlooked in official guidance.

With hands-on knowledge of Atlassian Cloud, identity synchronisation, and real-world enterprise migrations, Antti emphasised the importance of using immutable identifiers—such as objectId or externalId—as the definitive reference key in SCIM provisioning. His insights have led to changes in best-practice documentation and have helped organisations prevent costly provisioning mistakes, reduce operational friction, and maintain both identity integrity and compliance across systems.

At Ambientia, Antti and Rafael collaborate with a team of cloud integration and security professionals. The recommendations and technical strategies outlined in this article are built on firsthand experience troubleshooting complex user lifecycle challenges and promoting robust architecture in the Atlassian ecosystem.

Connect With Us

Whether you're dealing with duplicate user issues, planning your Atlassian Cloud migration, or need expert guidance on identity management and SCIM provisioning, we're here to help.

Our team has successfully helped numerous organisations transition to Atlassian Cloud while avoiding the pitfalls described in this article. Let us help ensure your migration is smooth, secure, and properly configured from day one.