Designing Atlassian’s cloud-to-cloud data portability experience
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
The two strongest contenders were:
Product data copy
This followed Atlassian Admin’s noun-first navigation rules and worked structurally as a category label. However, in internal reviews, team members hesitated. They were unsure whether this meant a place to view existing copies or an action to create one. The label required interpretation and introduced cognitive load.
Copy product data
This immediately communicated intent. It described exactly what would happen when clicked and matched how admins already talked about the task. It also aligned with existing Atlassian patterns like “Copy production data” in Sandbox.
The trade-off was clear:
structural correctness versus action clarity.
Between grammatical purity and setting expectation, we optimised for clarity. “Copy product data” won because it reduced ambiguity, lowered cognitive load, and made the action predictable and safe.
Information architecture pivot
I worked with my product designer and Atlassian Admin designers to explore how we could:
Keep a verb-first label for clarity
Still respect Atlassian’s architecture principles
Avoid cluttering the left navigation
We ran a design jam and explored different grouping strategies for portability features. Two main options emerged.
Option 1
Introduce Data management as a new category, with Copy product data as the first feature inside it.
Option 2
Introduce Data management at Level 2, with related actions like copy, merge, and backup at Level 3.
Both options were reviewed with designers and engineering partners.
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 IA conversations in Atlassian Admin around grouping by frequency and impact, not just by product area.
Implementation constraints and phased rollout
A full IA update required more screens and more engineering work.
With tight timelines and limited bandwidth, we agreed on a phased approach.
Phase 1: EAP
We shipped Copy product data at Level 2 under Org settings, even though it broke IA rules. This was enabled only for around 10 customers.
The goal was to move fast and validate how users interpreted the label in real usage.
Phase 2: GA
We implemented the long-term IA solution with Data management and related actions grouped inside it.
By that point, there were multiple data portability features, which made the structure meaningful and scalable.
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 and right..