INFORMATION ARCHITECTURE & PRODUCT NAMING · CONFLUENCE CLOUD · ATLASSIAN
Designing Atlassian’s cloud-to-cloud data portability experience
Defined the naming and information architecture foundation for a scalable cloud-to-cloud data portability system in Atlassian Admin
Overview
Designed the naming and information architecture foundation for a unified Cloud-to-Cloud (C2C) data copy experience in Atlassian Admin, enabling cross-product data movement from a single organization-level entry point.
The experience launched first with Confluence Cloud-to-Cloud and established the path for Jira C2C and future data portability products to move into the same scalable system.
Context
As Atlassian’s cloud ecosystem matured, enterprise admins increasingly needed to copy data between cloud sites—for mergers, org restructuring, sandboxing, and regional requirements. To enable this, we were introducing a data portability feature for cloud-to-cloud data copy in Atlassian Admin.
Before this capability existed in cloud, most admins relied on manual workarounds or raised support tickets to move data in cloud, increasing both support costs and turnaround time.
At the same time, Atlassian Admin was becoming the central place for all data portability features without a logical entry point for them.
We needed a scalable way to surface cloud data movement across products.
-
Senior Content Designer (Sept 2022 – mid 2023)
Owned naming and IA strategy, research, content audits, UX writing, wireframes, documentation, and changeboarding comms.
Balanced speed (Beta release) with scalability (GA readiness).
-
PM – roadmap, prioritization
Product Designers – UX flows, wireframes
Content Designers – naming & IA
Engineering Leads – feature flows
Support/Community – early feedback, comms
Research leadership: I led naming and IA research, paired with my product design partner.
-
Enterprise org admins & product admins managing large instances
Pain points: confusing terminology (“site,” “migration”), slow manual workarounds, ticket overhead
Goals: Self-serve data movement, unified entry point under Atlassian Admin
Problem statement
When I joined the team in mid 2022, Confluence C2C was in ideation. While Jira C2C had already launched as early Beta, it lived separately inside the Jira product as Migrate Cloud Site. The UI label was borrowed from the Server-to-Cloud (S2C) migration feature.
However, with cloud data movement for all supported products moving into Atlassian Admin, the core challenge was to:
design a name and placement that reduced admin confusion
fit Atlassian Admin’s information architecture
scale to future products
deliver quickly to meet business goals for cloud adoption
Core question being…
How might we design a clear, scalable way for enterprise admins to copy product data across cloud instances— so they can manage data seamlessly in Atlassian Admin today, while setting up a framework that supports future cloud products?
Goals
User goal - Help admins quickly find and confidently use cloud data movement in one place.
Business goal - Reduce support overhead, unblock cloud adoption, and create a scalable framework for future data portability features.
Design goal - Create a UI label and IA structure that matches cloud-to-cloud mental models, fits Atlassian Admin’s system, and can evolve without repeated renaming.
Solution overview
We introduced Copy product data as the UI label for cloud-to-cloud data movement in Atlassian Admin, aligning the experience with how admins naturally describe the task while clearly signaling non-destructive behavior.
To support long term scalability, we also defined Data management as the parent navigation category for organizing future data portability capabilities across products.
We validated the naming direction through an early EAP rollout and used those learnings to finalize a scalable information architecture for general availability, allowing the experience to evolve without requiring structural redesign.
This allowed us to move fast without locking the system into a brittle or misleading structure.
Impact overview
This work established a single, scalable entry point for cloud data movement in Atlassian Admin and introduced Data management as the long-term taxonomy foundation for future data portability workflows.
Rather than designing cloud-to-cloud as a one-off feature, we created a naming and information architecture framework capable of supporting multiple capabilities over time, including backup, organization merge, and future cross-product data tools, while maintaining a consistent and discoverable admin experience.
(Details on naming logic and information architecture decisions are covered in the sections below.)
Product north star
What experience are we optimising for?
Cloud-to-cloud data copy was designed as a self-serve capability. The experience needed to feel simple, safe, and repeatable rather than complex or expert-driven. However, the term “migration” carries a mental model of high-risk, expert-driven operations, which conflicted with how we wanted this feature to feel in cloud.
The north star principles below guided all naming decisions:
Establish what the experience must feel like before naming discussion begins
Research and framing the space
What language do users and the ecosystem already use?
Before exploring naming directions, I validated how admins understand cloud-to-cloud data movement across Atlassian and the wider ecosystem.
My research included:
Atlassian-wide terminology audits
Atlassian naming guidelines
Industry benchmarking and Google keyword analysis
Existing user interviews and community language
Internal pattern reviews across Atlassian products
Key insights
The language signals were consistent.
Industry commonly used “migration” for server-to-cloud movement or large, one-time operations
Admins used words like copying data, moving content, or duplicating setups
Internal Atlassian patterns prefer clear action-based terminology for operational workflows
Search behavior showed stronger association with “copy” and “move” than “migration” for intra-cloud activity
This made it clear that existing terminology did not match how users understood or searched for this capability.
Constraints shaping the naming space
The capability was intentionally designed as a non-branded, product-agnostic platform feature to reduce perceived complexity for users. It was referred to as cloud-to-cloud in public communication to make it scalable across products and platforms over time.
The feature name was not expected to appear in the UI much (if at all). As a result, the UI label was not meant to behave like a feature name or a tool name. It needed to describe a transient process, not a persistent system. This narrowed the space to action-oriented words that could work across products and platforms.
The name also needed to adhere to Atlassian Admin’s naming guidelines. Left navigation labels are expected to describe categories or objects, not actions. This meant that even though the feature itself was inherently action-oriented, any verb-first naming direction would challenge the guidelines.
Additional constraints included:
scalability across future portability features
alignment with how similar features are named across Atlassian Admin
Naming direction evaluated
After research narrowed the space to short, action-oriented labels, I evaluated a small set of options that represented the three structurally viable naming patterns within Atlassian Admin:
Noun-first - Follows Atlassian Admin navigation naming rules
Verb-first - Reflects a transient process
Destination-focused - Gives intent to the user to use this feature
Method
I conducted a cross-functional naming decision workshop using structured criteria scoring and group voting to align on the final feature name preference.
They were final naming patterns validated against platform constraints, scalability needs, and admin mental models before selecting the most viable option.
Snapshots of the naming options from the workshop
Key insights
After validating against the constraints and design principles, we identified the following themes:
The word “cloud” was unnecessary since the entire experience lives in a cloud environment
Focusing on the destination (“copy to cloud site”) felt intuitive, but quickly became too long and constrained future use cases
Action words like move, transfer, shift gave a false sense of data displacement after copy
Two names came up as strongest candidates - Product data copy (noun-first) and Copy product data (verb-first)
Decision: noun vs verb
Once we narrowed the space to action verbs, the final decision came down to how that action should be expressed in the UI.
This decision also aligns closely with Scott Kubie’s argument about naming generic capabilities - When actions are turned into nouns, users are forced to decide whether something is a place, a system, or an action.
Final name: Copy product data
Expanding the naming scope: action and category together
If cloud-to-cloud data copy was designed as a scalable, non-branded capability, it could not live as a one-off entry in navigation. While evaluating the UI label for the action itself, we were clear that we were not just naming a UI label, we were defining an entry point for data portability features in Atlassian Admin.
Method
In the same naming decision workshop where we compared action labels, we also evaluated potential parent categories.
Competitor analysis showed similar features grouped under object-oriented categories such as Data clustering, Manage data etc.
Internal terminology audit also showed us categorization patterns.
Data management emerged as the strongest structural fit. It aligned with competitor conventions, Admin’s naming system, and the long-term product roadmap.
Snapshots from the naming decision workshop
Naming decision flow chart
Information architecture plan
After we had the category and action level labels set, it was time to explore how we should place them in the Atlassian Admin UI. I conducted a design jam session with my product designer and Atlassian Admin designers to explore our options. Below are the shortlisted options.
Current state
No entry point for portability features under the Settings tab.
Option 1
Introduce Data management at Level 2, with related actions like copy, merge, and backup at Level 3.
Option 2
Introduce Data management as a new category, with Copy product data as the first feature inside it.
Peer review and decision
There was a unanimous vote for option 2.
Key reasons:
Data is the object being acted on, not the feature itself
Grouping actions makes space for future capabilities
These tasks are infrequent but high-impact
A cleaner Level 2 nav improves scanning and findability
It also aligned with broader architecture conversations in Atlassian Admin around grouping by frequency and impact, not just by product area.
Implementation constraints and phased rollout
Although Data management emerged as the long-term structural solution, creating a new navigation layer required additional design and engineering scope, challenging the tight EAP deadlines and limited design and engineering bandwidth.
Given the limited EAP audience of 10 chosen users, we treated this as a controlled exposure phase. We evaluated the impact-to-effort ratio and chose to deliver this in two phases:
Phase 1: EAP
We shipped Copy product data at Level 2 under Org settings. The goal was to move fast and validate how users interpreted the label in real world.
Phase 2: GA
When the experience opens to a larger user base, we will implement the planned navigation. By this time, the Data Management category would have 2-3 features ready to be shipped.
Key outcomes
Outcomes
Positive user response in EAP: Early testers reported lower confusion, fewer Jira-style “migration” expectations.
Business impact: 20% higher Jira cloud adoption than projected, as admins got clearer messaging on data movement tools.
Strategic impact: Established Data Management as the umbrella category for portability features in Atlassian Admin.
Internal alignment: PM, design, and engineering partners agreed on phased delivery - shipping fast