Cloud migration assistant - Atlassian

My product design internship at Atlassian. I redesigned three flows in the tool admins use to move Jira from their own servers to Atlassian Cloud, so they could trust it.

Company
Atlassian, Migrations team
Role
Product design intern
Time
Two months in 2023, remote
Output
Research, a trust framework and three redesigned flows
The redesigned Choose step. Pick a section on the left and tick what to move; the summary on the right adds up size and time. Screens on this page are redrawn with made-up data.

Context

In October 2020, Atlassian announced the end of support for its Server products and began moving customers to Cloud. A migration takes months.

The Cloud Migration Assistant is the tool admins use to plan, test and run it. I worked on its flows.

Server and Data Center

Hosted by the customer. Server support is ending.

Cloud Migration Assistant

Plans, tests and runs the move. Where I worked.

Atlassian Cloud

Hosted and kept up to date by Atlassian.

  1. Oct 2020End of Server support announced
  2. MonthsPlan, test and move, one customer at a time
  3. Feb 2024Server support ends

Problem

The brief was to build trust in the migration process. I broke it into questions, answered each one, and wrote the problem out again.

Build trust in the migration process with predictable, reliable and transparent flows that help admins make decisions with confidence.

  1. What does trust mean?Trust
  2. How do you build it?Trust
  3. What is the migration process?Migration journey
  4. Who are we solving for?Users
  5. Why does the problem exist?Pain points
The problem statement, rewritten after research. Each question links to the section that answers it.

Process

Four phases over two months.

Understanding

  • Current customers
  • Trust
  • Migrations
  • Customer journey
  • Goals and results
  • Design sparring

Research

  • Blockers and frustrations
  • Trust framework
  • Interviews
  • Secret shopper
  • Trust audit
  • Problem statement

Ideation

  • Feedback from dev, PM and data science
  • Scoping down
  • Customer stories
  • How might we
  • Ideation workshop
  • Design critiques
  • New customer journeys

Design

  • Lo-fi screens
  • Hi-fi screens
  • Iterations from feedback

Trust

I read articles from NN Group and IxDF, research such as HBR’s The Neuroscience of Trust, talks by Simon Sinek and James Davis, and Atlassian’s own research and design docs. Three qualities kept coming up.

To explain them to the team, I used a story about learning to drive. Imagine a car with no indicators, steering that turns left when you turn right, and blacked-out windows. Would you feel confident driving it?

The carWhat it breaksWhat it builds No indicatorsNo one can tell what comes next Steering turns the wrong wayLeft when you turn right Blacked-out windowsYou can’t see where you are PredictableYou can tell what will happen next ReliableIt works the same way every time TransparentThe information is accurate and honest Confidencefor admins Trust
The trust framework. Predictable, reliable and transparent experiences give admins confidence in the process, and that builds trust. The car breaks all three.

Users

Migrations are grouped by the customer’s size and how complex their setup is. I focused on complex enterprise customers.

Complex SMBSmall and medium business
Complex enterpriseMy focus
Standard SMBSmall and medium business
Standard enterpriseLarge, simpler setup
Customer groups by size and by how complex their setup is.

Inside each customer, three kinds of admin take part.

Primary admin

Runs the software, and owns the tools used across the company.

Secondary admin

A technical expert who helps solve complex, specialised problems.

Satellite admin

Outside the IT team. Runs a separate instance that Atlassian has approved.

Pain points

I read reports and documents to find out why trust was low. Seven pain points came out of them. The most pressing, for the customers I focused on, was low confidence in the tooling.

Learnings from SMB migrations Top frustrations and tasks Last quarter’s analysis Team goals and strategy Customer feedback Lack of control over the migration Lack of security information Lack of transparency Low admin confidence in toolingMost pressing Unpredictability Confusing and inefficient flows Data and privacy concerns
Where the pain points came from. Low confidence in the tooling was the most pressing, based on existing reports and the customers we were designing for.

Migration journey

A migration has six stages, spread over weeks or months. Admins use the assistant in four of them. The rest happens in Atlassian’s admin console, in meetings and in documents.

My three journeys sit where admins first open the assistant, and where they create, run and fix migration plans.

Assess

Find out what the company has, what it needs, and which cloud plan fits.

Plan

Set up the cloud organisation, and agree on a plan with everyone involved.

Prep

Get the team, the environments and the data ready to move.

Test

Run test migrations to find problems before the real one.

Migrate

Move the production data, with support on hand.

Launch

Switch users over to Cloud, and review the move.

Work
  • Assess requirements
  • Compare cloud options
  • Build a migration team
  • Demos and customer prep
  • Finalise the contract
  • Set up the organisation
  • Connect and verify the domain
  • Refine the plan with stakeholders
  • Draft a runbook
  • Check each app’s features and security in Cloud
  • Prepare the team
  • Prepare environments
  • Clean up and optimise data
  • Run several test migrations
  • Find risks and blockers
  • Resolve customer tickets
  • Fix last-minute issues
  • Run the production migration
  • Support around the clock
  • Tell users what changed
  • Review the migration
  • Help users switch over
In the assistant
Assess your apps
Outside the assistant
Prepare your appsPrepare your usersReview email domains
Create a migration planRun it on a test site
Run the migrationMigrations dashboard
Outside the assistant
My journeys
2First impressions
1Creating a plan3Changing a plan
1Creating a plan3Changing a plan
The six stages of a migration: what happens in each, the work involved, and where the assistant and my three journeys come in.

Three journeys

Inside the assistant, I worked on three journeys.

2First impressions 1Creating a migration plan 3Saved plans Home Connect Choose Check Review Migrate Dashboard Edit a saved plan
Where each journey sits in the assistant. App migration is a topic of its own, since other companies make the apps, so I left it out.
1

Creating a migration plan

“As an admin, I want to create a migration plan after preparing my instance, by choosing the data to move and the cloud site to move it to.”

 2

First impressions

“As an admin, I want an overview of the data in my instance and access to the policies, so I can see the overall status.”

 3

Changing a saved plan

“As an admin, I want to change a saved plan, because it failed and I want to move what’s left, or because our strategy changed.”

Creating a migration plan

Five steps: connect to a cloud site, choose the data, check it, review the plan and migrate.

Current flow

Admins create a plan from the assistant’s home: Migrate your data, then Create a migration. Five steps follow, from picking the cloud site to running the migration.

I went through each step as an admin and noted what got in the way of trust. Here is each step as it was.

Pain pointsPredictableReliableTransparent

    The flow before my redesign, redrawn. Pick a step, then hover a pain point to find it on the screen. Each colour is the part of trust that point breaks, my reading.

    Trust audit

    Eighteen pain points in five steps. Choose had the most, so I scoped down to it.

    PredictableReliableTransparent

    Connect2
    Choose7
    Check3
    Review3
    Migrate3
    Pain points in each step of the old flow, by the part of trust each one breaks.

    Six pages

    Choose was six pages: the migration options, then one page per kind of data, each laid out differently. Admins clicked back and forth to compare them.

    Migration options Advanced Roadmaps Projects Users and groups Customers Apps Before: six pages, one after another Migration options Roadmaps Projects Users and groups Customers Apps Summary After: one page, five tabs
    Choose before and after. The six pages became one, with every section a tab away.

    Feedback

    I took the audit to engineering, product management and data science. Each saw a different side of the problem.

    Engineering

    Some errors have to block a migration, or it fails later. A recommended plan was already being built.

    Product management

    Predicted times were often wrong, and failed plans cost trust. Complex migrations needed help from solution partners.

    Data science

    Earlier PURE and click-through studies showed which features admins left untouched. They helped me test my hypotheses.

    Ideation

    From there I scoped down to the Choose screen, and ran an ideation workshop with other designers. It showed where my flow depended on theirs.

    Secret shopper Feedback from dev, PM and data science PURE analysis Choose screen Scoping down Ideation workshop Design critiques Iterate
    How the Choose screen took shape, in order.
    Secret shopper
    Use the product for the first time, through a test instance, and note everything that gets in the way.
    PURE analysis
    A group rates the mental load and effort each step of a task takes.

    Final design

    Two hypotheses shaped the final screen. The customer story behind both: as an admin, I want more context about each choice and its consequences while I pick what to migrate, so I can decide deliberately.

    Condense the flow

    A shorter, consistent flow means less friction, so trust grows.

    Vertical tabs
    Six pages become one. The tabs show the way through every section, and progress reads the same everywhere.

    Add context

    When admins see what each choice costs, they decide deliberately, fewer outcomes surprise them, and trust grows.

    Selection summary
    A collapsed summary for each section, the size and time of each, and the total time to migrate.
    1. Vertical tabsEvery section on one page, with its status.
    2. Page descriptionWhat the page is for, and why.
    3. Same optionsEvery section offers its choices the same way.
    4. Migrated columnShows what already moved, to avoid duplicates.
    5. Selection summarySize and time for each section, and the total.
    6. Cloud destinationAlways in view.
    The final Choose screen. Hover a detail to find it on the screen.

    Some of my ideas, such as uploading a file to select projects, were already being built by other designers. The workshop caught that early.

    First impressions

    The assistant’s home is an admin’s first look at the product. It listed tasks, but said little about the instance being moved.

    Home

    Three problems on the old home: little context about the instance, names that didn’t match their sections, and nothing on data access, security certification or privacy settings.

    Migration Assistant home

    This tool helps you assess and create your migration plan. You’ll then be able to test and migrate to a cloud-hosted site.

    Overview

    Your instance at a glance. Hover a part to see its size, or click it to keep it open.

    40 projects1,140 users610 customers12 apps49 GB in all

    Assess

    Assess your apps

    Assess and select the apps you need to migrate to Cloud before you prepare them.

    Begin assessing

    Prepare

    Prepare your apps

    Connect to a cloud site, install your apps and consent to app data migration.

    Begin preparing
    Prepare your users

    Check that every user has a valid, unique email address.

    View results

    Migrate

    Migrate your data

    Move users, groups, projects and apps in stages, or all at once.

    Create a migration
    The home before and after. Switch between them above.

    Show the data

    If admins can see their instance, the system feels intuitive and transparent, and their confidence grows.

    Map of the instance
    Each part sized by its data. Hover for its size; click to open it.

    Be open about security

    If security and resources are out in the open, enterprise admins avoid their biggest blockers, and trust grows.

    Resource monitor
    Current use, to spot trends and decide on them.
    Security information
    Links to the documents admins need, where they need them.

    Changing a saved plan

    Every migration starts as a plan: the cloud site, the data and the options. Plans are saved on the migrations dashboard. Admins come back to one when a run fails and they want to move what’s left, or when their strategy changes.

    Saved plans

    An example. The Q3 move had seven projects. Five migrated and two failed. The admin wants to retry the two, and add two projects that haven’t moved yet.

    The migrations dashboard before the redesign. View details was the way back into a saved plan.

    Problem

    View details opened the plan at Review, near the end of the flow. To change it, the admin walked the flow backwards, then forwards again.

    View detailsReviewCheckChooseAll 9 projectsCheckReviewMigrate1Backwards2Repeated3
    Changing a saved plan before the redesign. Every step after View details is one the admin had to sit through.
    1. 1

      Backwards

      The plan opened at Review. To change what moves, the admin stepped back through Check to Choose: the opposite of how the plan was made.

    2. 2

      Repeated steps

      After Choose, Check and Review ran a second time. Six steps for one change.

    3. 3

      No record of what moved

      Choose listed every project as if nothing had happened. The admin had to work out which five were done and untick them, or move them twice.

    Fix

    Hypothesis: a simpler flow makes the tooling consistent, so it’s easier to use, and admin confidence and trust grow.

    EditChoosePrefilledCheckReviewMigrateFour steps, forwards
    Changing a saved plan after the redesign.

    1Backwards

    Straight to Choose

    Edit opens Choose with the saved plan filled in. The flow runs forwards, the way the plan was made.

    2Repeated steps

    Four steps

    Choose, Check, Review and Migrate, each once. Two steps fewer.

    3No record of what moved

    Trimmed selection

    A Migrated column shows what already moved, and those projects leave the selection on their own. One click restores them.

    3Working out what’s left

    Recommended plan

    Suggests what to move next from the migration’s stage and earlier runs: here, the two failed projects and the two that haven’t moved.

    Choose, opened from the saved Q3 move. The five projects that migrated are already out of the selection. Try Use plan, or Restore.

    What I learned

    Documentation

    Good documentation argues for a design when I’m not in the room, and keeps everyone talking.

    Complexity

    Complex environments take patience to understand. The learning doesn’t stop.

    Challenges

    Every problem needs its own understanding. Other disciplines see what I miss.

    Outcome

    I handed the designs over at the end of the internship. It was too early to measure how they did.

    Thanks to Soo Basu, my manager, Amanda Rondonuwu, my mentor, and Nebin Biju, my buddy.

    Next projectOpenFOAM StudioDescribe a CFD simulation in plain English, and run the real solver.Read the case study →