Vinoth.
Atlassian · Jira Data Center · 2017–2018Shipped product

Designing a safer Jira Data Center upgrade experience.

I designed the end-to-end administrator experience for Jira Data Center's Zero Downtime Upgrade workflow, from checking whether an environment was ready to monitoring individual nodes during an active upgrade.

Role
UX Designer · Primary Designer
Scope
UX · UI · Research
Team
Product Manager · Tech Lead · UX Lead · Developers
Product
Jira Data Center
Shipped UIThe Zero Downtime Upgrade experience in Jira Data Center — the shipped administrator screen for readiness checks, update mode, and live cluster monitoring.

The problem

An upgrade affected a live clustered environment.

Jira Data Center customers ran Jira across multiple nodes to support large organizations and maintain availability.

Upgrading these environments was different from updating a conventional application. Administrators had to coordinate changes across a cluster while Jira continued serving users.

The challenge was that an upgrade affected a live clustered environment. Administrators needed to understand compatibility issues, node states, exceptions, and when it was safe to move forward without taking Jira offline.

Before beginning an upgrade, they needed to know:

  • whether the environment was ready
  • whether installed add-ons were compatible with the target Jira version
  • whether database changes could introduce downtime
  • what would happen to individual nodes during the upgrade
  • when the cluster had reached a state where the upgrade could safely be completed

This made the experience as much about understanding system state as performing the upgrade itself.

System model

Before designing the interface, we modeled the operation.

Before designing the interface, I worked with the Product Manager and developers to understand how the upgrade actually behaved.

We mapped the operation from preparation through completion, including:

  • readiness conditions
  • add-on compatibility
  • Jira version requirements
  • database changes
  • node-level operations
  • warnings and exceptions
  • intermediate cluster states
  • completion conditions

The system flow became the reference for deciding what administrators needed to see at each stage and which conditions required action before they could continue.

Shared modelCollaborative system flow used to work through the upgrade experience with product and engineering.

Shown as evidence of the working process; it is not intended to be read end-to-end.

Decision area · compatibility.
Decision area · downtime exception.
Decision area · finish conditions.

Research

Three practical questions about readiness and confidence.

We tested the workflow with Jira administrators while the product and technical model were still evolving.

The research focused on three practical questions:

  1. 01Can administrators determine whether their environment is ready?
  2. 02Do they understand what will happen when the upgrade begins?
  3. 03During the operation, can they tell whether the cluster is progressing normally and when it is safe to finish?

The sessions helped us identify where technical system behavior needed to be made more explicit in the interface, reducing reliance on documentation and administrator interpretation.

I planned and conducted the research, with the Product Manager participating in sessions, and documented the findings for the team.

The upgrade experience

Three stages kept the operation navigable.

I organized the administrator experience around three stages:

  1. 01

    Prepare

    Understand readiness, compatibility, and anything that could prevent a safe upgrade.

  2. 02

    Upgrade

    Monitor the cluster and individual nodes while Jira versions change.

  3. 03

    Finish

    Confirm that the cluster has reached the required state and explicitly complete the operation.

This gave administrators a stable structure even though the technical operation underneath it contained multiple conditions and branches.

01 · Pre-upgrade

Readiness surfaced before anything changed.

Before entering upgrade mode, administrators needed a clear view of anything that could make the operation unsafe.

The pre-upgrade experience surfaced the conditions that mattered before anything changed in the cluster, including instance health, Jira version requirements, and add-on compatibility.

The interface brought these problems forward during preparation, before administrators started the upgrade.

Stage 1Pre-upgrade readiness — instance health, add-on compatibility, version readiness and cluster monitoring gathered before the administrator enters update mode.
DetailEnlarged detail — readiness information organized before the administrator enters the active upgrade.

Add-on compatibility

Compatibility became part of readiness.

Installed add-ons could behave differently against a newer Jira version, so compatibility had to be checked before the cluster was upgraded.

The compatibility experience showed administrators which add-ons had been checked against the target Jira version and where action might be required.

This turned compatibility from a background technical concern into an explicit part of upgrade readiness.

ChecklistCompatibility as readiness — the 'Before you start' checklist surfaces instance health, add-on compatibility, environment changes and version readiness before the administrator enters update mode.

The zero-downtime exception

"Zero downtime" still had an exception.

Certain upgrades could require database index changes that introduced downtime. That created an important exception inside a feature explicitly designed around zero downtime.

The interface made the condition explicit by telling administrators:

  • why downtime might occur
  • what part of the upgrade required it
  • whether the change could be handled automatically
  • when manual intervention was required
  • what would happen if they continued

Administrators could then make the decision with the operational consequence visible before committing to it.

Design explorationDowntime communication — the exception made visible, including the choice between manual and automatic handling of the required upgrade work.

Multiple CTA and message variations document exploration; only selected variations shipped.

02 · Upgrade

Once it started, the job changed from preparation to monitoring.

Once upgrade mode started, the administrator's job changed from preparation to monitoring.

A conventional progress indicator wasn't enough because different nodes in the cluster could be in different states or running different Jira versions.

Progress depended on system state, not a single percentage.

The interface exposed the state of individual nodes so administrators could understand what was happening across the cluster without relying on a single progress number.

They could see which nodes had moved forward, which version each node was running, and whether the cluster had reached the conditions required for the next step.

Stage 2Data Center upgrade in progress — cluster-level state while nodes move through the upgrade.
Magnified detailMagnified detail — cluster/node monitoring: node, status, Jira version, updated state and update indicators give administrators the per-node visibility they need to decide what to act on next.

Intermediate states

Everything meaningful between start and done.

The upgrade passed through several meaningful states between starting and completion.

The experience distinguished between states such as Starting → In progress → Ready to finish.

These states gave administrators clear feedback about whether the system was still changing, whether additional node operations were required, or whether the cluster was ready for completion.

This was particularly important because an apparently stable Jira instance did not necessarily mean the upgrade itself was finished.

StartingStarting — the system establishes that the active upgrade has begun. Long-running tasks are suspended, the cluster is marked 'READY FOR UPDATE', and each node shows its version, status, and update readiness.
In progressIn progress — administrators can observe the changing state of the environment. The cluster reads MIXED: one node offline, one ready to update, one already updated, with '1 of 3 nodes updated' progress.
Ready to finishReady to finish — the interface communicates that the operation has reached its final stage. Every node is updated to a consistent version and the cluster status reads 'READY TO RUN UPDATE TASKS'.

03 · Finish

Finishing was an explicit action.

Finishing the operation was an explicit administrator action.

Once the required nodes were upgraded and the cluster reached the correct state, the interface changed from monitoring progress to confirming that the upgrade could be completed.

The final state made it clear that the operation was finished, avoiding a state that left administrators to infer completion from the absence of activity.

Finish promptReady to finish → Finish update — the administrator confirms the final step. The 'Run upgrade tasks' modal makes completion an explicit, deliberate action rather than an implicit one.
CompletedCompleted — the environment returns to normal operation, explicitly. A green success banner confirms the update and links to a post-upgrade report, making the end of the upgrade unmistakable.

Iteration

The interaction model evolved with the technical behavior.

The interaction model evolved as we learned more about the technical behavior of the upgrade.

Earlier versions treated readiness information more independently. As the workflow developed, instance health, add-on compatibility, Jira-version requirements, and upgrade readiness became more tightly connected.

The later design brought these conditions together so administrators could understand the state of the environment before entering upgrade mode.

The changes were not primarily visual. They reflected a clearer model of what administrators needed to know before starting and what the system needed to communicate while the upgrade was running.

EarlierEarlier iteration — the pre-upgrade experience relied on three flat, unstructured panels with loose reminders, leaving administrators to confirm readiness themselves before entering the active upgrade.
LaterLater iteration — readiness is reorganized into a structured, collapsible 'Before you start' checklist of six panels, separating pre-upgrade preparation from the numbered upgrade execution steps and surfacing instance-health errors and warnings at a glance.

Ownership

My role

I was the primary designer for the Zero Downtime Upgrade experience.

I owned the end-to-end UX and UI across preparation, compatibility checking, active upgrade monitoring, exception handling, intermediate states, and completion.

I also planned and conducted administrator research and produced the research reports used by the team.

The Product Manager participated in research sessions, and I worked closely with the Product Manager, Tech Lead, UX Lead, and developers to understand the underlying cluster behavior and translate it into the administrator experience.

Technical architecture and implementation decisions remained with engineering.

Outcome

Shipped as part of Jira Data Center.

Zero Downtime Upgrade shipped as part of Jira Data Center, giving administrators a structured way to prepare for, monitor, and complete upgrades while keeping Jira available through the supported upgrade path.

The delivered experience included:

  • pre-upgrade readiness checks
  • add-on compatibility visibility
  • explicit handling of downtime exceptions
  • node-level upgrade monitoring
  • meaningful intermediate states
  • explicit upgrade completion

Reliable historical product metrics from this work are not available to me today, so I don't attribute numerical improvements to the redesign.

The evidence I can stand behind is the shipped workflow and the interaction model developed with the product and engineering team.

Shipped · Jira Data Center

Reflection

What this project taught me

This project changed how I thought about complex enterprise interfaces.

Consequential operations may require more of the system to be exposed to users.

Users may need to see the current state, exceptions, consequences, and what needs to happen next. The designer's job is deciding which of that complexity users actually need in order to act safely.

Atlassian archive

More from Atlassian

JQL Search

Designing a more approachable way to construct powerful Jira queries.

Case study coming next

Shared Filters & Dashboards

Designing information-management workflows for complex Jira environments.

Case study coming next