How to plan a Jira migration from Data Center to Cloud

Plan a Jira migration from Data Center to Cloud by working backward from March 28, 2029, when Data Center subscriptions for Jira, Jira Service Management, and Confluence expire and those products become read-only. Decide the destination and identity model first, then assess apps and scripts, choose a single cutover or a phased move, rehearse in the free Cloud Migration Trial, prepare your users, run the cutover, and hand over a platform someone owns.

Server reached end of support on February 15, 2024, so this guide assumes you run Data Center today.

The dates that set your schedule

Renewals cannot run past March 28, 2029, and Atlassian prorates them to that date. Until then, Atlassian continues technical support, fixes for critical security vulnerabilities, and the connectors from Data Center to Cloud. Extended maintenance after that date is offered only by exception. Bitbucket Data Center is not part of this end of life, but after that date it continues only under Atlassian's Bitbucket Hybrid License.

Work backward from those dates. If your user count will grow before you finish, buy the expansion by March 30, 2028. Leave room for a second attempt at cutover, because if it slips past March 28, 2029, your teams are working on a read-only system.

1. Decide the destination and identity model first

Before anyone runs a migration assistant, settle three things: which Cloud plan you are moving to, how many sites you will run, and how people will sign in.

If you run more than one Data Center instance, the Jira Cloud Migration Assistant does not require you to merge them before you bring them into one Cloud site. Merging is still a design decision, because two instances usually carry two sets of fields, workflows, and permission schemes that now have to share a home.

Identity works differently in Cloud. Atlassian Cloud identifies people by email address, and you cannot connect LDAP, Crowd, or another external directory to it directly. If you use LDAP, Crowd, or another external directory today, you need a cloud identity provider in between and, in most cases, Atlassian Guard Standard for SAML single sign-on and SCIM provisioning. Cloud does not support nested groups, so the identity provider has to flatten them. Okta does that natively.

Our stance: Okta is the source of truth for who people are, which groups they belong to, and when their access ends. Atlassian Guard adds the controls on the Atlassian side. Each person has one Atlassian account, and it carries their access across every Atlassian app you run.

• Verify your domains. Accounts on a verified domain become managed accounts that you can edit, deactivate, and apply security policies to.
• Find duplicate group names. Jira and Confluence groups with the same name become one group in Cloud, which can grant access to people who never had it.
• Set up single sign-on and provisioning before users move. Atlassian recommends it, and incoming users are matched to Cloud accounts by email address either way.

The migration is also the first time anyone has to write down what your permissions actually are. Our guide to where identity debt hides in a migration lists where it surfaces, from accounts of people who left to tokens held outside the directory.

2. Assess apps and scripts

Run the app assessment in the Jira Cloud Migration Assistant and the Confluence Cloud Migration Assistant before you test anything. On the "Assess your apps" screen, each installed Marketplace app shows whether a cloud version exists and what migration path its vendor offers, from an automated path through the assistant to no path at all.

You then mark each app as needed in cloud, not needed, or replaced by an alternative. Decide from real usage. An app nobody opened last quarter does not need a migration path. The assistant does not run a security assessment of app data, so check each vendor's cloud app against your own standards, and tell the vendor of every app you keep about your schedule early.

Scripts need their own pass, because ScriptRunner scripts from Data Center rarely move as they are. Read each one, work out what it actually does, and decide where it belongs: a native Jira feature, an Automation rule, a small Forge app, a ScriptRunner rewrite on Cloud, or retirement. Our guide to what happens to ScriptRunner scripts when you move to Cloud walks through that inventory.

3. Choose a single cutover or a phased move

Both assistants let you move everything at once or in stages, so the tool does not make this choice for you. Your dependencies do.

Phasing feels careful, but in Jira it has a specific cost. When the same configuration moves in more than one phase, the Jira Cloud Migration Assistant currently creates another copy with a "(migrated)" suffix, so every wave can add duplicate custom fields, workflows, and schemes to clean up. Phasing also means two live systems, two change freezes, and links and roll-ups that point across the boundary for weeks. If you do phase, ask Atlassian about dual licensing: with a qualifying annual Cloud subscription (for example, 1,000 or more users on Jira or Confluence Premium or Enterprise), it extends your Data Center subscription for up to six months.

Phasing still fits some estates: few Marketplace apps, little linking or reporting across spaces, and business units that work mostly on their own. Decide from a dependency map, not from how the word sounds in a steering meeting. We compare the two in why a phased Jira migration can be the riskier choice.

4. Test migrations in the free trial

Atlassian gives eligible Data Center customers a free Cloud Migration Trial. It matches your current user tier up to 20,000 users and lasts for the rest of your Data Center subscription term, up to 12 months. You need a Commercial or Academic license with 11 or more users, and the trial covers Jira, Jira Service Management, and Confluence on the Standard and Premium plans.

Know the limits. Data on a trial license is not backed up, support is limited to migration-specific help, and outbound email is capped at 100 messages a day. Atlassian recommends testing on Premium or Enterprise so you can use a sandbox and keep production clean. Atlassian Guard Standard has its own 30-day trial, which Atlassian support can extend to match your migration trial.

1. Clean up first. The more data you move, the longer and more complex each run.
2. Clear the pre-migration checks in the assistant, then run the test migration.
3. Review links between Confluence pages and Jira work items, workflows whose post functions relied on apps, migrated app data, and integrations.
4. Run user acceptance testing with every major user type. In Jira, create sprints, add work items to backlogs, and view boards. In Jira Service Management, have agents work their queues and check the portal. In Confluence, create a space, edit pages, and upload attachments.
5. Time the run and write each step into a runbook with an owner and an expected duration.
6. Reset and repeat. The assistants do not overwrite data already in your Cloud site, so delete it before each new test.

Repeat until the timing settles and the defect list stops growing. That runbook is what you execute on cutover day.

5. Plan users and training

Most of what users notice on day one is predictable, so write it down before cutover:

• A new address in the form yoursite.atlassian.net, so bookmarks need updating.
• Sign-in with an email address instead of a username. With single sign-on, people keep their usual password. Without it, they set a new one.
• New mobile apps, because the Data Center versions do not work with Cloud.
• The differences in apps, screens, and administration your testers recorded.

Pre-migrate users and groups without any space data. Atlassian recommends this, especially above 2,000 users, because later runs then move only the differences, and people keep working in Data Center while it runs. Build short training around what confused your testers, and keep office hours open for the first weeks.

6. Run the cutover

1. Pre-migrate attachments. They are typically the longest part of a migration, and the "Attachments only" option lets you move them weeks or months ahead. The final run skips the ones already moved.
2. Freeze configuration changes on Data Center.
3. Make the source read-only. Jira has no read-only mode, so apply a permission scheme that grants only the browse permission to every space. In Confluence, remove every permission other than read. Add a site-wide banner that says so.
4. Run the production migration and reconcile counts and samples against Data Center.
5. Update anything that still points at old IDs. After a Jira migration, the assistant can produce an ID mapping report that maps source IDs to Cloud IDs for scripts and integrations. It is rolling out progressively, and the same mappings are available through the API.
6. Change the Data Center banner to send people to the new site.

7. Run the platform after go-live

A migration ends with a hypercare window, not a handover email. Keep the team that ran the cutover available for the first weeks, triage defects daily, and run Atlassian's link fixing to update links between Jira and Confluence in bulk, then fix what remains as users report it.

Then decide who owns the platform. Name who can create spaces, custom fields, and workflows, and put configuration changes through review so the estate does not drift back. In Jira Cloud, any user can create a team-managed space until an admin removes that global permission, so decide that on day one. Keep joiners and leavers in Okta and provision through SCIM, so managed Atlassian accounts are created and deactivated from the identity provider, not by hand. After March 28, 2029, your Data Center data stays available read-only, with no updates, support, or security fixes, so treat it as an archive and, as Atlassian advises, keep it off the internet.

How to choose a partner for the move

If you bring in help, start with the Atlassian Partner Directory. Filter by the Cloud Migration solution to find Cloud Migration Specialized Partners, and check each partner's level in Atlassian's Solution Partner program: Silver, Gold, or Platinum. Then ask the questions this plan raises:

• When does the partner design identity, and which system owns groups and deprovisioning?
• How does the partner decide what happens to each app and script?
• How many test migrations does the partner plan, and what does the runbook record?
• Who stays on for hypercare, and what will your team own after the partner leaves?

We are an Atlassian Platinum Solution Partner, and our Atlassian Cloud Migration Services follow the order in this guide: identity and apps decided first, every run rehearsed on a test site, then cutover and hypercare.

Start with what your Jira is carrying

Every step above goes faster when you know what is in your Jira before you move it. Our free Jira health check is built for teams planning a migration. We review accounts and groups, permission schemes, custom fields, workflows and screens, and governance, in that order, then give you a written scorecard and a 30-minute walkthrough, in about a week. We change nothing, and the review covers Data Center, so you can run it before you activate your trial.