The ultimate guide

to migrating at scale
What to expect when migrating your enterprise
to Atlassian Cloud
Table of contents
4 Executive summary

6 Phase 1: Assess and evaluate Cloud

7 Explore the differences between self-managed and Cloud

8 Cloud apps

8 Assess Cloud plans

10 Unlimited sites

12 Evaluate Atlassian Access

12 Access features and capabilities

15 Understand migration support and tools

15 Meet the A(tlassian) team

16 Migration tooling

18 Comparing migration support to your Atlassian footprint

21 Phase 2: Plan your migration

21 Review your enterprise needs

24 Understand your data requirements

24 Setup your Cloud instance

THE ULTIMATE GUIDE TO MIGRATING AT SCALE 2

27 Phase 3: Prepare your migration

27 Assemble your team

27 Solutions partners are your friends

28 Build your migration timeline

29 Migration strategy and method

30 Optimize and shift (recommended)

31 Lift and shift

32 Phased

33 Start fresh start whenever you want

33 Align with leadership

35 Phase 4: Test and migrate

35 Create, update, and review your runbook

38 What does a Cloud migration look like in action?

38 Phase 1: Assess and evaluate

40 Phase 2: Plan

41 Phase 3: Prepare your migration

41 Phase 4: Test and migrate

THE ULTIMATE GUIDE TO MIGRATING AT SCALE 3

Executive summary
There’s no denying that software as a service (SaaS) provides
numerous benefits to enterprises across the globe. Between better
IT resource allocation, a modern infrastructure, and end-user
features that keep teams productive at scale, organizations, like
yours, are making the move.

More and more of you are migrating your self-managed products to Atlassian
Cloud. And while many of you are excited to unlock the innovation that
Atlassian Cloud can provide your organization, it isn’t always clear how to
make the move.

Most of you have done some type of migration. You’ve probably had some that
have gone smoothly and others that were a bit bumpier. However, it’s often
the bumpy ones that we remember. And, as the people who are responsible
for carrying out a successful migration, those experiences can impact your
perception of what a migration might look like.

But no two migrations are the same. While there are important lessons that
you can take from your past experiences, using them to guide your approach to
an Atlassian Cloud migration isn’t always the best way forward. So, we’ve put
together this comprehensive guide - to walk you through what you can expect
when you make the move to Cloud.

· Each phase of the migration

· Migration strategies and methods

· Resources to help you with your migration

· An end-to-end example of what a migration looks like

THE ULTIMATE GUIDE TO MIGRATING AT SCALE 4

 01
Assess and evaluate Cloud
PHASE 1

Assess and evaluate Cloud

You’ve been using your self-
managed products for some time
and you’re all experts when it comes Succcess checklist
to administering your instances F Explore deployment
and supporting your teams at scale differences
- while still maintaining complex
F Assess Cloud plans and
workflows that are happening
evaluate Access
behind the scenes. But we built
Cloud from a different codebase, F Understand the support
which has enabled us to provide a Atalssian provides
more streamlined administrative
experience and end-user innovation 48PT

to your teams.

That’s why we recommend you take

the time upfront to learn more about
our Cloud products.

This includes:

· Exploring the differences

between self-managed
and Cloud

· Assessing our Cloud plans and

evaluating Atlassian Access

· Discovering what tools and

teams Atlassian supports

THE ULTIMATE GUIDE TO MIGRATING AT SCALE 6

Explore the differences between
self-managed and Cloud
Let’s start by looking at how our self-managed and Cloud products differ from
an operational perspective.

Server is the standard edition of our self-managed products, which you host
and run on your own hardware. Architecturally, when your teams are accessing
their applications, their requests are sent directly to your server, which is why
maintaining and optimizing the performance of your infrastructure is critical
as your teams grow.

Data Center is our self-managed enterprise edition built to meet the complex
needs of growing enterprises. Like Server, you can host your products on your
own hardware, or leverage a cloud provider. To help maintain the reliability and
availability of your products, you can also choose to deploy them in a clustered
architecture - adding additional infrastructure components to distribute your
user traffic.

You’ve all seen value in our self-managed products because they enable you
to maintain full control over your environment so you can meet your business
requirements. But, it also means that you’re responsible for servicing and
maintaining the infrastructure needed to support your products at scale. This,
of course, can lead to increased IT overhead and resource consumption.

Atlassian Cloud is our SaaS offering. Unlike self-managed where you manage
the infrastructure yourself, Atlassian hosts and maintains the performance,
availability, and reliability of your products. In short, we take on the
infrastructure and operational aspect of your product administration so that
you can focus on keeping your teams productive.

For a side-by-side comparison Read our Cloud architecture

of Atlassian Cloud and Data and operational practices
Center, see our deployment page in the Trust Center for
comparison page. a technical deep-dive.

THE ULTIMATE GUIDE TO MIGRATING AT SCALE 7

Cloud apps
Apps enable teams to extend the use of their Atlassian products even further.
While apps will continue to do that with your Cloud products, there are some
differences between how our Server and Cloud apps are built. The biggest
differences are that the control, connectivity, and security are different
between our Server and Cloud apps.

Understanding the differences between Atlassian’s deployments is an

important part of the migration process, but it’s also important that you
understand what Cloud plan is right for you, as each plan offers specific
capabilities designed to meet your business requirements, and can impact
your migration strategy.

Assess Cloud plans

We offer a number of different plans to address the complex demands that
organizations are required to meet as they continue to grow.

As you’re learning more about Cloud, it’s important that you understand
what comes with each plan so that you can choose the one that meets
your requirements.

Here’s a list of the top differences between our Standard, Premium, and
Enterprise plans.

Standard Premium Enterprise

Up to 20,000 Up to 20,000 Up to 20,000

User limit Up to 5,000 Up to 5,000 Up to 5,000
agents agents agents

Site limit One One Unlimited

Subscription Subscription
Atlassian Access Included
required required

Admin insights —

Sandboxes —

THE ULTIMATE GUIDE TO MIGRATING AT SCALE 8

Cloud plans continued

Standard Premium Enterprise

Release tracks —

Encryption in transit
and at rest

Disaster recovery and

business continuity

Audit logs

IP allowlisting —

Data residency

250 GB file
Storage Unlimited Unlimited
storage

Local business 24/7 Premium 24/7 Enterprise

Support
hours support support

Guaranteed uptime
— 99.9% 99.95%
SLA

Centralized per-user
— —
licensing

For more information on features or to learn more about the innovation that
we’re building in our Cloud products, check out our whitepaper – Server to
Cloud: why make the move

THE ULTIMATE GUIDE TO MIGRATING AT SCALE 9

As you’re considering what plan makes the most sense for your organization,
consider the following questions:

·  What level of product support do you need to be guaranteed?

·  What storage capacity do you need?

·  Do you need to scale with unlimited sites?

·  Do you require an isolated sandbox to test apps and previous changes to your
Cloud instance?

·  Do you need to test new features before rolling them out on production?

For enterprises, both the Premium and Enterprise Cloud plans offer enterprise-
grade capabilities. However, we recommend Enterprise Cloud if your organization:

1. Has, or plans to, standardize their Atlassian products across the organization

2. Is supporting globally distributed teams and has centralized governance

and compliance needs

The reason: our Enterprise Cloud plan gives you access to unlimited sites and
Atlassian Access, which aren’t available in Premium. To help you better understand
how these features could be used, let’s dive into each in a bit more detail.

Unlimited sites
With most of our Cloud plans, a subscription grants you access to one instance
of your products. This is similar to what you have on Server or Data Center
today - your instances operate independently of each other and require you to
pay per user per instance. But as more organizations are shifting to the Cloud,
they’re seeing a lot of value in being able to centralize or decentralize their
administration depending on their business needs.

In self-managed environments, administering multiple instances of your

products is challenging. Whether they were created as part of an acquisition,
a merger, or a team who wasn’t aware of your supported tech stack, because
each product operates independently of each other, there is no unified way of
administering all of your instances at one time.

Enterprise Cloud removes those limitations. With unlimited sites, you can have
as many sites as your organization needs to meet your needs. Here are some
common examples of multi-sites in action.

THE ULTIMATE GUIDE TO MIGRATING AT SCALE 10

Top use cases for multi-sites

Grant teams autonomy by creating sites for each of your

Separate business units (BUs). For example, you can create a separate
departments or site for your sales team and development teams. This enables
teams teams to customize their sites, such as applying customized
workflows and apps, without impacting other teams.

Some of your teams have access to sensitive or

proprietary data. You can create separate sites for
Security
those teams and limit who has access to those sites to
maintain the right level of security.

Create separate sites to maintain your data privacy

requirements. For example, if you have certain data that
needs to stay within a specific region, you can create a
Data isolation
separate site and pin your in-scope data to that specified
location. You can then pin your other sites to different
locations or keep them global.

Through mergers or acquisitions, new teams may join your

Mergers and organization and you may want to continue to administer
acquisitions those teams separately. You can give those teams their
own site and still administer them in a central location.

Many organizations have a globally distributed team, so you

Geography
can create a different site for teams in those specific geos.

If you plan on adopting a multi-site strategy as part of your migration, we

recommend that you map out what users you’ll want to associate with each
of your sites. Creating new sites within your organization is simple, but by
completing this tenant mapping before you execute your migration, you can
ensure a much smoother, secure transition for you and your teams.

Within each of your sites, you can have up to 20,000 users, so this capability also
enables larger teams to embrace Cloud, while making more strategic choices
on how products and data are architected. It also grants teams the autonomy
to use apps that are specific to their role. While some apps may be used widely
across your entire organization, others may be specific to certain teams, so you
pick and choose what apps you want to be available to each of your sites.

To learn more about administering multiple sites or other parts of Cloud

administration, check out Becoming an Atlassian Cloud admin.

THE ULTIMATE GUIDE TO MIGRATING AT SCALE 11

Evaluate Atlassian Access
Security is built into the platform of our Cloud products, but you may have
additional security needs that require you to put safeguards in place. Often,
this takes the shape of strong user management processes and practices.

You can think of Atlassian Access as the tool that bridges the gap between
your Atlassian products and your identity management providers (IdPs). It
gives you a single place to view and manage all of your users and product
instances and enforce your company’s security policies (including SSO).

Access is an enterprise-wide subscription that covers all of your cloud-based

Atlassian products used by your organization. It works by first identifying what
users are in your organization by their email address domain. You can claim as
many domains as your users might use. As you claim a domain, you gain control
of all users that use that domain in their email address. You can then enforce
security on this group of managed users like SSO and user provisioning. Note,
Bitbucket currently doesn’t include user provisioning or SCIM capability.

For those of you using Opsgenie, Access works on Opsgenie instances that
are on an Atlassian account. Because these users are typically associated
with some of your other Atlassian products, such as Jira Software or Jira
Service Management, they’re already counted as users within Access.

Access features and capabilities

Enables your teams to log into their Cloud products using

SAML / SSO
a company username and password

Our SAML API enables us to support nearly all SAML providers, but we offer
more streamlined integrations with:

· Okta · Idaptive (previously Centrify)

· OneLogin · Google Cloud Identity

· Microsoft Azure AD · PingFederate

· Microsoft ADFS

THE ULTIMATE GUIDE TO MIGRATING AT SCALE 12

We also offer the ability to create a custom SAML integration that you can use
to manually integrate with any provider. If you have a partner, they can help
you build this.

For those using Google Workspace, there is an option that forces your teams
to use the social login button.

Allows you to grant access to an entire group of users at

User provisioning
one time. This streamlines and de-risks onboarding and
User lifecycle
offboarding teams because access is granted to all the
management
relevant systems in one place - reducing time and effort
SCIM
while upholding security.

We support nearly all cloud identity providers through our customer SCIM API.
However, the integration is more streamlined with:

· Okta · Microsoft Azure AD

· OneLogin · PingFederate

You can also create a custom SCIM integration that allows you to integrate
with nearly any provider manually.

For Google Workspace, you can sync users from selected groups, revoke
site access, and deactivate Atlassian accounts if a user has been deleted or
suspended from your workspace.

Create multiple authentication policies for different users,

Authentication
which allows you to set the right level of security and
policies
exclude any managed users.

With Access, you can configure authentication policies through:

· single sign-on (SSO) · password policies (password

strength, password expiry)
· enforced two-step verification
(2SV) · session duration

THE ULTIMATE GUIDE TO MIGRATING AT SCALE 13

You also have the flexibility to set these for your entire organization or for
specific groups and users.

Auditing logging
Track events that occur within your organization and
Organization
across your sites to maintain your compliance position,
insights
along with user activity and license consumption.
CASB integrations

Audit logs provide a digital record of everything that’s happening within your
instance. Because Cloud is more interconnected, these audit logs are pulled at
the organization level, which means that you can see what’s happening across
all of your sites and instances.

You can also leverage the McAfee MVISION Cloud and Atlassian Access
integration for greater protection of your important data and increased
protection from threats through activity monitoring.

Enforce security Assign your company’s security policies, such as two-factor

policies authentication or password strength requirements.

API token Manage the users within your organization who have
controls API access

Your teams can create an API token to authenticate a script or process from
their Atlassian account.

To ensure that your security needs are met, you can see exactly what API
tokens a user has created and manage them directly from their user account.

“ With the use of Atlassian Access (almost) everything

is now automated and the admins only have to
intervene in a few cases.
PETER GRUBE
Software Engineer, Homegate AG

With Atlassian Access, you can ensure that your user management needs
are met.

THE ULTIMATE GUIDE TO MIGRATING AT SCALE 14

Understand migration support and tools
Once you’ve assessed the differences between our Cloud plans and identified
if you need Access, it’s now time to understand what migration support and
tools you have available to you.

You may be using multiple Atlassian products as part of your tech stack.
While we do provide a number of resources and tools to help you migrate your
products to Cloud, the type of support we provide does vary by product.

Meet the A(tlassian) team

As we say, migrating is a team sport. To make it easier for enterprises to make
the move, we provide an A-list team of Atlassian’s to help them along the way.

First, you’ll have a dedicated Cloud migration manager (CMM). Once you’ve
committed to planning your migration by submitting a MOVE ticket, CMM will
be with you throughout the entire migration. They help:

· Review your current set-up

· Assess Cloud plan considerations

· Create a production timeline for your migration

· Keep your teams operating smoothly during the migration

In short, they’re the person that keeps your migration on track and ensures
that you’ve picked the right options to meet your needs.

THE ULTIMATE GUIDE TO MIGRATING AT SCALE 15

If your organization has a technical account manager (TAM), they’ll be working
alongside the CMM to answer any technical questions and help you define
your overall strategy.

And for those that don’t have a TAM, a sales engineer (SE) may be brought in
to help you assess your needs, answer any technical questions that you may
have surrounding your migration, and ensure that the right technical solutions
are in place so that your needs are met.

To help you execute the migration, you’ll have a migration support engineer by
your side to help you test your migration before you roll it out on production.
They’ll be helping you run your pre-migration testing. If there are areas that
require additional technical support during the planning and prep stages of
your migration, your CMM may bring them in to provide a consultation.

Note

This dedicated team is focused on migrating Jira Software and

Confluence. If you have other products that you want to migrate
to Cloud, such as Bitbucket or Jira Align, you’ll need to work with
additional teams at Atlassian for migration support. Your team can help
you open a support ticket to get in touch with these other teams, or
you can create one yourself through the Support portal.

Migration tooling
Your dedicated team of Atlassians will help you on the road to success, but
migrating data and identifying the apps that you want to take with you can
be a manual process without the right tools. We’ve all been there and want
to make this process as smooth as possible for you, which is why we built our
migration assistants.

The Jira Software and Confluence migration assistants help you migrate
multiple projects, spaces, and users from your self-managed products to Cloud
all at once. And if that wasn’t enough, they provide visibility into the migration
process by walking you through each step along the way.

THE ULTIMATE GUIDE TO MIGRATING AT SCALE 16

 Coming soon

We’re always iterating on these so that they can migrate more of your
data. Currently, we’re working on building migration support for:

·  Advanced Roadmaps

·  Jira Service Management

In Confluence, we’re working on:

·  Team Calendars

·  Questions

For all you Bitbucket users out there, the Bitbucket Cloud migration
assistant is in the works. Keep an eye on our roadmap for the latest.

Apps are an important part of your Atlassian ecosystem, so we’ve made

assessing your apps easier. Through the migration assistants, you have a
complete view of all the apps that are currently being used within your
instance, if there is a Cloud equivalent, the number of users, and the
migration path.

THE ULTIMATE GUIDE TO MIGRATING AT SCALE 17

This view enables you to see what apps have a corresponding Cloud
equivalent and identify if there are other options available to you. As you
continue through planning, you’ll use this information to help inform how you
approach the following phases of your migration.

While your migration team can also help you finalize the app assessment,
they don’t have visibility into your app data, which means that you’ll need to
work with your app vendors to understand what the migration path looks like.
However, we’re working in collaboration with our Marketplace partners to add
the ability to migrate app data using our migration assistant tools.

We are continuously working with app vendors to make the app migration
process easier for you. Read our post to learn more about the time frames
in which we’re rolling these out.

Take stock of your Atlassian footprint

Now that you’ve seen what migration support and services are provided, you
need to compare them to your current Atlassian footprint.

Work with your IT team to take stock of all the Atlassian products - and by
extension the instances - that you have. You’ll want to be able to answer the
following questions:

· Are they all self-managed, or do you already have some Cloud products?

· How many employees are using each product and for what purpose?

· How often are they being used?

· Are there any instances you weren’t previously aware of? If so, do you plan
on keeping them alongside your Cloud site, or archiving them?

· What version of Atlassian products are you running?

· Have you built customizations into Atlassian products? How often do you
or your team maintain workflows and custom fields in your instances?

THE ULTIMATE GUIDE TO MIGRATING AT SCALE 18

 Product discovery — available in Atlassian Access — enables you to identify
all Atlassian Cloud instances that were created by people within your
domain. As you’re taking stock of your Atlassian products, download a trial
to help you discover any Cloud instances that may already exist.

You’ll also want to use this as an opportunity to look critically at your app
usage. While we’ve continued to add more and more apps to our ecosystem,
not every app has a Cloud equivalent today. So, there may be some apps that
you don’t want to migrate or different apps that you’ll want to leverage as
part of your migration.

At this stage, interviewing your teams will be extremely useful because Cloud
migrations don’t just impact IT. We’re all creatures of habit and change can
be hard. Getting buy-in from your teams is what’s going to make your Cloud
migration truly successful. It’s the pivotal - what’s in it for me - moment.

Using the data that you collected in your audit, interview your teams to
understand how they’re using them. Ask your teams to share how they’re
using the products day-to-day, if they have any pain points that they’re
experiencing, or if there are certain features that are important to them. The
team innovation we’ve built-in Cloud may already address these concerns or
be on the roadmap, so you can get them excited about what’s on the horizon.

THE ULTIMATE GUIDE TO MIGRATING AT SCALE 19

 02
Plan your migration
PHASE 2

Plan your migration

Now that you’re caught up to speed on Cloud and some of the fundamentals,
it’s time for you to do some pre-migration homework. While you can’t plan for
everything, taking stock of where you are today and how this will impact your
future state can help to mitigate issues later in the process.

Succcess checklist
F Review how Cloud meets your enterprise needs

F Evaluate your data requirements

F Set-up your Cloud instance and claim your domains

Review your enterprise needs

Our deployment comparison highlighted some of the differences between
our self-managed and Cloud products, but chances are, you’ve already been
comparing Cloud to your current scenario to see if it meets your needs even
before you sat down to read this. However, there’s a lot of value in formally
identifying what your requirements are and if and how they’re met in Cloud.

Your team of Atlassians will help you through this assessment, but you might
be curious what types of questions they’ll ask. We’ve pulled together this
handy list, along with some resources that you can use to further investigate.

THE ULTIMATE GUIDE TO MIGRATING AT SCALE 21

Example enterprise requirements questionnaire

User count and products

What products do you plan on migrating to Cloud?

How many users do you need to license per product?

Based on the number of users you have and business requirements, do you need
Enterprise Cloud so that you can federate your instances?

Are you planning on consolidating any of your instances into one site?

Security, Legal, Compliance/Regulatory, Privacy

What are your compliance requirements? Do you have any regulatory needs for
your data?
· Because Atlassian is managing your instances, it’s our responsibility that you
remain in compliance. Review the Trust site and compliance reports to ensure
that your compliance requirements are met.
· Note, while we do meet most requirements today, our Cloud products do not
meet PCI or HIPAA requirements. If you’re storing this type of data in your
products, you would not want to migrate this instance to Cloud. Read our blog
to learn more about administering between multiple platforms.

What are your security needs and do you need to complete a security review?
· We know that many of you have vendor risk assessments that you need to
complete. You can submit your questions and our support engineers will help
you answer them, or leverage our pre-filled questionnaires with answers to the
most common security questions.

What are your privacy requirements?

· We know that you want to protect your sensitive data and have control over
how it’s used. We’ve outlined this in our privacy policy. Additionally, we offer our
Cloud customers a separate Data Processing Addendum (DPA) which addresses
EU data protection and processing concerns.
Learn more about how to approach security and compliance - specifically from a
GDPR perspective - in our webinar.

THE ULTIMATE GUIDE TO MIGRATING AT SCALE 22

Once you’ve filled out this section of the questionnaire, you’ll want to work with your
legal team to review our Cloud Terms of Service.

Apps and customizations

How many apps are you currently using today?

Of these apps, how many of them are critical to your organization?

Do you have any customizations that you’ve built on Server or Data Center?

Do you need all of these customizations?

· The app assessment will help you identify what apps have a Cloud equivalent
and what migration path you need to take. While apps are an important part
of your Atlassian ecosystem, some of you may have built your own apps and
customizations. On Cloud, we offer Forge - our app development platform -
which you can use to rebuild those customizations and something that you
should consider as you’re planning your migration.

User Management

Are you using a SAML IdP?

Are you part of the organization that manages all of your company’s users?

Do you use multiple IDPs?

How are you currently managing users/groups on-prem?

Data locality

Are there constraints on where the data will be located?

· As we mentioned above, our Cloud architecture is designed to not limit data
movement. However, some of you may have requirements on where your data
can be located. If this is your organization, then you’ll require data residency.

THE ULTIMATE GUIDE TO MIGRATING AT SCALE 23

Understand your data requirements
Data requirements are one of the reasons people shy away from moving to the
Cloud or think it isn’t possible. However, a move to Cloud isn’t necessarily out
of the question if you have strict data privacy requirements.

Ultimately, it comes down to whether all of your instances have these data
requirements or just some of them. For example, your legal team may use a
separate Confluence instance and the data in that instance might need to be
fully under your control for privacy reasons. Although it might be impossible
for you to move that team’s Atlassian instance to Cloud, it may be possible for
you to move other teams over to Cloud - especially those who don’t have the
same strict data privacy requirements.

For organizations that are considering leveraging both self-managed and

Cloud deployments, we’re optimizing the experience so that you can more
easily administer them together, thus keeping control of your sensitive data.

At this stage, we recommend doing a tenant mapping exercise. As we

mentioned above, you will want to look critically at your setup and decide how
you want to structure your Cloud sites and what data and users you will be
keeping on your self-managed instances. This will allow you to make sure that
you plan what data is going to be migrated where, what users will need to be
licensed for those sites, and ultimately how to best safeguard your data with
the right practices.

Setup your Cloud instance

Before moving on to the next phase, you need to set up a Cloud site so that
it’s ready for when you migrate. While this step isn’t a requirement, it is a
prerequisite for Atlassian Access.

There are two parts to this: setting up your organization and claiming
your domain.

To set up your organization, we recommend that you use our free Cloud
migration trial. Each trial lasts up to 12 months and matches the remaining
duration and user tier of your current self-managed license. It’s designed
specifically to help you explore, evaluate, test, and migrate your instances over
time - without disrupting your teams.

THE ULTIMATE GUIDE TO MIGRATING AT SCALE 24

The Cloud migration trial automatically generates an organization alongside
your site. You’ll be able to access your organization at admin.atlassian.com.
Moving forward, this is where you will view and manage all of your Atlassian
Cloud users and set up security features like SSO. We strongly recommend
signing up with a URL you plan to keep as your new production site once your
migration is complete. You can find more information on how to change the
name here.

Once you have your organization in place, you need to verify your company’s
domain to claim your managed user accounts. You can do this by either
uploading an HTML file to the root folder of your domain’s website (HTTPS), or
you can copy a TXT record to your domain name system (DNS). You’ll then see
all of your managed accounts within your organization’s admin console.

THE ULTIMATE GUIDE TO MIGRATING AT SCALE 25

 03
Prepare your migration
PHASE 3

Prepare your migration

Succcess checklist It’s time for you to prepare for your

migration. In the previous phase, you
F Assemble your team
reviewed all of your requirements
F Build a migration and set up your organization. In this
timeline next phase, you’ll be focused on:

F Choose a migration ·  Assembling the rest of your

strategy and method migration team

·  Choosing a migration strategy

and method

·  Building a migration timeline

Assemble your team

Migrating to Cloud is a team sport, so you’ll want to make sure that you have
the right people seeing you through to the end. We showcased the Atlassian
team members you’ll have access to earlier, but you’ll also want to have people
within your organization that are dedicated to the migration.

Solutions partners are your friends

Even if moving to Cloud is a top-down ask from your leadership team,
migrations take time - something that is hard to come by with your other
responsibilities. On top of that, IT teams often operate lean (one of the reasons
you may want to move to Cloud in the first place). This makes it difficult to

THE ULTIMATE GUIDE TO MIGRATING AT SCALE 27

build up a team of people solely dedicated to your migration. That’s why we
recommend leveraging a partner to help you get across the finish line.

They are right alongside your Atlassian migration team throughout the entire
process. That means that they’re helping us work with you to do the planning
and migration prep to determine what strategy will work best for you. They’ll
also work with any other Atlassian teams that you may need to engage with,
as well as app vendors.

If that wasn’t enough, they’ve done these migrations before and they know
what it takes to successfully make the move.

“ Igood
can’t stress enough the importance of having a
quality partner. Building a relationship with our
partners is what got us over the line.
AFTERPAY

Build your migration timeline

With your team assembled, it’s time to pick a date. Now, you don’t want this
to be based on what you want it to be, but the date that you’re ready to move
forward with a migration. For some teams, this date can be a hard deadline
that your executive leadership has set out. For others, you may be aiming
for a soft launch - you might be aiming for a certain date, but you have the
flexibility to adjust the timeline.

With a deadline in mind, your CMM will work backward from that date you’ve
provided, factor in the support you have, and build out your full timeline.

Enterprise migration timelines also factor in:

· Enterprise requirements, such as security and privacy

· Amount of existing data and if it’s optimized pre-migration

· Apps and customizations

· Migration strategy and method

· Team size and if you are leveraging a partner

Don’t forget to consider renewal dates and the end of Server support, as you
will want to optimize where possible to ensure there is no disruption in
your service.

THE ULTIMATE GUIDE TO MIGRATING AT SCALE 28

Migration strategy and method
Throughout this guide, we’ve outlined tools and people that you can leverage
as part of your migration. However, every migration requires its own strategy
or the guiding principle you use to move your data from one instance
to another.

Your team at Atlassian will help you decide what strategy will work best
based on your timeline and requirements, but this is a breakdown of the
strategies that you can use as part of your Cloud migration.

These strategies apply at the instance level.

THE ULTIMATE GUIDE TO MIGRATING AT SCALE 29

Optimize and shift (recommended)

You migrate an instance all at once during the migration

How this
window. Prior to migrating, you clean-up your self-managed
method works
instance, remove old or unused data and inactive users.

· Everything in your instance is migrated all at once

· You’re only migrating what you need
· Easier navigation for your team once in Cloud
Pros · A more streamlined migration timeline and better use
of resources
· Your self-managed instance is still available if you need to
roll back your migration

· Your teams need to be onboarded simultaneously

· Requires one significant window of downtime for teams
Cons
· Requires additional planning and work to determine what
areas you need to optimize

Migration
Migration Assistant or site import
method

Timeframe 3-9 months

This option might be right for you if...

Your organization has the time and resources to clean up your instance prior
to your migration. Most organizations are carrying around a lot of enterprise
baggage - the data and users that just never got removed from the instance.
Moving to Cloud is your opportunity to start over and get rid of the baggage
that may be bogging you down.

Pro tip

Data Center offers a number of clean-up capabilities across each of

the products that you can use to clean-up your instance prior to your
migration. Check out our clean-up guides for more information.

THE ULTIMATE GUIDE TO MIGRATING AT SCALE 30

Lift and shift

You migrate an instance all at once during the migration

How this
window, but you don’t clean-up your instance before
method works
you migrate

· Everything in your instance is migrated all at once

· More streamlined migration timeline and better
Pros resource allocation
· Your Server or Data Center instance is still available if you
need to roll back your migration

· Your teams need to be onboarded simultaneously

· Downtime may be increased depending on data size
· May be moving unused data or users, which could add
to cost
Cons
· There is a longer testing period before the migration
(multiple tests and UAT need to be done to ensure all
details have been covered)
· You may have to clean-up your data post-migration

Migration
Migration Assistant or site import
method

Timeframe 1-6 months

This option might be right for you if...

If your organization is looking to move to the Cloud and you don’t want to
spend time upfront cleaning up your instance, this option will enable you to
migrate at a faster rate.

THE ULTIMATE GUIDE TO MIGRATING AT SCALE 31

Phased

Taking your instance and breaking it into 2 - 4 batches for a

How this Cloud migration. These batches are broken down based on
method works value, such as separate servers, products, or active vs
inactive instances.

· Phased user onboarding and change management

· Reduced migration downtime
Pros · You can clean-up and optimize your instance over time
· Collect feedback from your teams to apply to future phases
of migration

· Working across two platforms makes it difficult to roll back

if you need to
· Longer migration timelines include several more rounds
of testing
· Requires careful planning and mapping of dependencies
Cons · You may need certain IPs to be allowed listed to establish a
link between your Server and Cloud instances, which could
raise security concerns
· You may experience configuration drift, which will then
require you to perform extra pre or post-migration
cleanup steps.

You can choose to migrate using either the migration

assistant or site import initially, but you’ll want to use the
migration tool for the additional batches you migrate.
Migration
method If you choose to migrate your data using site import, we still
recommend that you migrate your users with the migration
assistant, or they can be synced through Access if you have
a subscription.

Timeframe 6-12 months

This option might be right for you if...

Your organization has business requirements that won’t enable you to have
long periods of downtime, or you have complex, large data shapes that can’t
be migrated during one single migration window.

THE ULTIMATE GUIDE TO MIGRATING AT SCALE 32

Start fresh start whenever you want

How this Leave your data behind in your self-managed instance and
method works only bring users and workflows.

· There is little to no migration downtime

Pros · You can keep your data around for achieving purposes if you
have a Server license

Cons · Your teams can’t access their old data

Migration
Migration Assistant or site import
method

Timeframe As soon as you create your Cloud site

This option might be right for you if...

You don’t need access to your existing Server data, you’re spinning up a brand
new team, or you’re expediting your move to Cloud. This option can also
enable teams to streamline their Cloud footprint and implement new ways
of work.

Align with leadership

Ideally, you’ve been working with leadership and internal stakeholders
throughout this entire process, but it’s important that you fully align with
leadership before moving into the testing stage of your migration.

THE ULTIMATE GUIDE TO MIGRATING AT SCALE 33

 04
Test and migrate
PHASE 4

Test and migrate

Succcess checklist You’re ready to get testing and

ultimately migrate your production
F Create, update, and
instances to Cloud. Remember that
review your runbook
migration support engineer that we
mentioned before - this is where
they shine. They’ll be working with
you through this phase to build a
runbook and ensure that you’ve done
the right testing before your final
production migration.

Create, update, and review your runbook

Testing is one of the most important steps in any migration. So, our migration
support engineer will help you build a runbook. But don’t worry, you can use
your own runbook template if your organization has one that they prefer.

First, you’ll work together to complete a pre-migration checklist. This includes

activities such as ensuring that you’ve defined your migration strategy and set
up your Cloud instance.

Next, you’ll work together to draft your test strategy. There are some tests that
we know you’ll need to run depending on the migration strategy, but we’ll also
add tests based on your setup and requirements.

At this time, you’ll also need to provide a ZIP file that contains your instance
data. On our end, we’ll run through checks to mitigate any issues during
the actual migration process. While we can’t run all the checks on our end,
our support engineers will provide comments and feedback to help identify
any outstanding checks that you need to do on your end. This will all be
documented in your runbook.

THE ULTIMATE GUIDE TO MIGRATING AT SCALE 35

 Note

Your runbook should be your source of truth. Your support engineer will
be adding resources providing details while you do the same. This will
provide your IT team with the full migration picture.

The last step is to execute your test migration. Work with your support
engineer to align on the date and time you’re running your test. As you’re going
through each of the tasks, you’ll want to enter the amount of time that it
took (we’ll do the same on our end). Don’t forget to document challenges and
roadblocks, as they will be extremely helpful for your production runbook.

With this final bit of information in hand, fine-tune your production migration
plans and you’re off to the races.

THE ULTIMATE GUIDE TO MIGRATING AT SCALE 36

 05
What does a Cloud
migration look like in action?
What does a Cloud migration look
like action
Cando is one of the leading shoe distributors in the US - providing a wide
selection of options that range from sneakers to heels. What originally started
as a small business has now turned into a large-scale enterprise operation.
Maggie, the current CEO, has big plans of expanding their global presence.

For the past five years, Cando has used Jira Software Server to track the
software development work that they do for their website and Confluence
Server for all of their internal collaboration. Over the past five years, the
organization has gone from 250 team members to 15,000. Gaby and Alyssa,
the company’s senior admins, have spent considerable people hours and
budget building an infrastructure that can remain performant at scale, but
Cando’s organizational growth isn’t in line with what their existing on-prem
infrastructure can handle and their teams are starting to suffer.

With Atlassian announcing their end of Server support, Maggie has reached
out to Gaby and Alyssa to understand their options. While they know they can
continue to run on-prem with Data Center, they’re also aware that Atlassian
is building more innovation in Cloud. And while Maggie has also expressed
interest in adopting a cloud-first strategy moving forward, Cando has specific
data requirements that must be taken into account as they make
their decision.

Phase 1: Assess and evaluate

The first thing that Gaby and Alyssa need to do is get a better understanding of
Atlassian Cloud products.

THE ULTIMATE GUIDE TO MIGRATING AT SCALE 38

Once they’ve done their research, they now want to understand what a
migration might look like, so they start by going to the Atlassian Migration
Center.

After reading through the site and some additional resources, they still aren’t
sure if Cloud is right for them. They decide to fill out the contact form to get
more information from Atlassian. Jacob - an enterprise advocate (EA) - reaches
out to them.

To kick off the conversation, Jacob walks them through the investments
that Atlassian is making for both teams and admins - and specifically how
Atlassian is meeting their enterprise requirements. After hearing more about
Cloud, Gaby and Alyssa both feel like it’s the right move for their organization.
Now, Maggie needs to ensure that this works within their budget.

Jacob schedules a call with Gaby, Alyssa, and Maggie where he walks them
through the total cost of ownership (TCO) and what their return on investment
(ROI) could be by making the move to the Cloud. While the initial investment
seems high, Maggie can see that over time, infrastructure costs and licensing
fees make Cloud a much better option for Cando.

While Maggie is keen to move forward with the migration, Alyssa and Gaby
still have more questions about the migration process, such as what plan
they need, how does user management work, and if they will need to make
changes to their current setup before migration to Cloud. To address these
questions, Jacob brings in Abby, the sales engineer (SE).

Based on their specific requirements, Abby recommends taking a

decentralized approach and leveraging multi-site because they want to
continue using their external directory and SSO. So, Abby and Alyssa decide
that the Enterprise Cloud plan makes the most sense.

Before they give their final recommendation to Maggie, Gaby and Alyssa want
to understand what support and tools they need to execute their move. Jacob
walks them through what Atlassian provides them, including a CMM and
migration support engineer.

He also uses this opportunity to talk more about the Jira Cloud Migration
Assistant (JCMA) and the Confluence Cloud Migration Assistant (CCMA),
which they could leverage to migrate their data from Server to Cloud. He also
mentions that site import is another option available, but the CMM assigned
to our MOVE ticket will be able to help them decide on what tools and overall
strategy make the most sense for their organization.

THE ULTIMATE GUIDE TO MIGRATING AT SCALE 39

While they’re both happy with the support that they’re getting, they’re also
aware that this migration could take some time and they’re the only two
admins dedicated to the migration of their data. They decide that getting a
partner makes the most sense.

So, they reach out to Cloud Movers, who assigns Jess to work with them.
Throughout their initial call, Gaby and Alyssa have the opportunity to get a
sense of how Jess will work with them and Atlassian to help migrate their
data, but they require a statement of work that they can share with Maggie.
Jess works on drafting this up so that Cando can move forward.

After gathering all of this information, Gaby and Alyssa can go to Maggie
to move forward with the migration. Jacob stays with them throughout the
purchase process to ensure that Cando’s needs are met.

Phase 2: Plan
They’re now ready to move forward and begin working with Atlassian to plan
their migration. They submit a MOVE request, which is sent to the CMMs.

Hosana is officially assigned to Cando’s migration and schedules a kick-off

with Alyssa, Gaby, and Jess. She walks them through the overall process and
describes will be working with them at each stage of the journey

Gaby and Alyssa know that they need to do an official security audit. They
submit a copy of their questions to Atlassian to respond. They promptly send
responses back and they’re satisfied that Cloud meets their
security requirements.

The next step is to figure out how running multiple sites will impact their
migration and how to better prepare. Hosana recommends completing the
tenant mapping exercise to plot out what users will go to each site. In the
end, Alyssa and Gaby decide that they need a site for their development team,
sales, and marketing.

THE ULTIMATE GUIDE TO MIGRATING AT SCALE 40

With the final pieces in play, they download their free migration trial and claim
their domains. They now see all of their users and are ready to grant them
access once they’ve officially migrated.

Phase 3: Prepare your migration

Because they’ve already engaged a partner - Jess - they’re now ready to decide
on what their migration strategy should be and what method they can use.

Hosana recommends that they leverage JCMA and CCMA for their migration
and that they use a lift and shift strategy, where they migrate their entire
Jira Software instance at one time and then move their Confluence instance
shortly after.

Based on the strategy, method, and their partner, they feel comfortable
migrating their Jira Software instance over Memorial Day weekend and
Confluence will be two weeks after that over the weekend.

Last, but not least, they align with Maggie one more time to review the
timeline and confirm that they are good to move forward.

Phase 4: Test and migrate

Brian is the technical support engineer assigned to their migration. With the

THE ULTIMATE GUIDE TO MIGRATING AT SCALE 41

plan and strategy outlined, Brian works with Gaby and Alyssa to complete
the pre-migration checklist. He then works with them to outline their testing
strategy and indicates what tests they will need to run and what he will be
running on his end.

They provide Brian with a ZIP file containing their data, which Brian uses to run
through the migration checks before the official move. He gives some feedback
on what they can do to optimize their data pre-migration and documents
everything in the runbook.

The last thing that Alyssa and Gaby need to do is test their migration. They run
through the entire process and document the time it takes and highlight any
challenges they experience. This data is sent back to Brian to use as part of the
official migration.

With data-optimized, they migrate their data without any hitches.

THE ULTIMATE GUIDE TO MIGRATING AT SCALE 42

We’ve officially walked you through
the ins-and-outs of an enterprise migration

Ready to plan your move?

Schedule a migration consultation today.

©2021 Atlassian. All Rights Reserved. ENTMIG_77-08/21