Migration playbook · Atlassian

How to migrate Jira and Confluence Server or Data Center to Atlassian Cloud

Server support has ended and Data Center now has a published end-of-life date. This guide covers the dates, the Jira and Confluence Cloud Migration Assistants, apps, users and how to run test and production migrations.

Updated 4 Nov 20266 phases27 detailed steps11 official sources

Start the plan Templates (6)PDF runbook

Click by click

Detailed steps

Open a part when you reach it in the plan. Each step says where to go, what to do and what you should see.

About this migrationWhat it covers, limits at a glance

Atlassian ended support for Server products on 15 February 2024. Atlassian says Server products are no longer eligible for renewal or updates, enhancements or security patches. For Data Center, Atlassian has published an end-of-life schedule: new subscription sales to new customers ended on 30 March 2026, new sales, expansions, upgrades and Marketplace Data Center app sales end on 30 March 2028, and subscriptions expire on 28 March 2029, when Data Center products and apps become read-only.

Atlassian recommends its migration assistants for moving to Cloud. They move projects, spaces, users, groups and supported app data in phases, and they do not overwrite or delete data already in your cloud site. The work that takes time is app assessment, user planning and testing.

ServerSupport ended 15 February 2024: no updates or security patches

Data CenterNew subscription sales for new customers ended 30 March 2026. Data Center products become read-only at end of life on 28 March 2029

Jira toolJira Cloud Migration Assistant (pre-installed in Jira 8.14 and later)

Confluence toolConfluence Cloud Migration Assistant (pre-installed in Confluence 6.15 and later)

Not migratedGlobal settings and permissions, passwords (people use SSO or set a new one), application links

1Confirm your deadline

Milestone	Date (Atlassian, PST)	What it means
Server end of support	15 February 2024	No updates, enhancements or security patches for Server
Data Center: new subscriptions for new customers	Ended 30 March 2026	New customers cannot buy Data Center
Data Center: new sales, expansions, upgrades, Marketplace DC app sales	30 March 2028	Existing customers cannot add users or buy new DC apps after this date
Data Center: end of life	28 March 2029	Subscriptions expire; Data Center products and apps become read-only

Still on Server? Server instances no longer receive security patches. Treat an internet-facing Server instance as a priority risk and restrict access until it is migrated.

2What you need before step two

Need	Details	Where to get it
Jira System Administrator and Confluence System Administrator	To install and run the migration assistants and change permissions on the source.	Your Jira and Confluence Server or Data Center instances
Organisation admin for the cloud site	To receive migrations, manage users and groups, send invitations and set up SSO.	Atlassian Administration, https://admin.atlassian.com
A production cloud site and a test site	Test migrations go to a separate site so production stays clean.	Create from the assistant (Atlassian offers a free Cloud migration trial) or at https://www.atlassian.com
A supported source version	Atlassian says you need a supported Data Center version of Jira to use the assistant.	Jira and Confluence system information pages
App vendor contacts	For every app you mark Needed in cloud.	Atlassian Marketplace listing for each app
A recent backup of each instance	Database and home directory, taken with your normal backup process before production migration.	Your backup tooling

3Assess the instance4 steps

1
Inventory projects and spaces
Where: Jira: Administration > Projects. Confluence: Spaces > Space directory. Record results in your Application inventory and dependency map
List Jira projects and Confluence spaces, their owners and whether they are active. Archive or exclude what nobody needs.
You should see: Every project and space has an owner and a Move, Archive or Exclude decision.
2
Check versions
Where: Jira: Administration > System > System info. Confluence: Administration > General configuration > System information
Read the product version. Atlassian says you need to be on a supported Data Center version of Jira to use the assistant. Upgrade first if you are on an old release.
You should see: Both instances are on versions the assistants support.
3
Record integrations
Where: Jira: Administration > Applications > Application links, and Administration > System (webhooks, incoming mail). Confluence: General configuration > Application links
List application links, webhooks, mail handlers, SSO and directory integrations. Application links and global settings are not migrated and must be set up again.
You should see: A list of every integration with an owner who will recreate it in Cloud.
4
Create the cloud site
Where: https://www.atlassian.com sign-up, or the assistant's Choose destination cloud site screen
Create or choose the destination cloud site and a separate test site or sandbox for trial runs. Check Atlassian's current plans and pricing for user tiers.
You should see: You can sign in to both the production and test cloud sites as an org admin.

4Install or update the migration assistants3 steps

1
Jira Cloud Migration Assistant
Where: Jira Server or Data Center: Administration > Manage apps
Pre-installed in Jira 8.14 and later and Jira Service Management 4.14 and later. To update, select Manage apps, search for Jira Cloud Migration Assistant and select Update. On older supported versions, select Find new apps, search for it and select Install. Atlassian recommends updating to the latest version. Open it from Administration > System > Migrate to cloud.
You should see: The assistant opens from System > Migrate to cloud.
2
Confluence Cloud Migration Assistant
Where: Confluence Server or Data Center: Administration > Manage apps
Pre-installed in Confluence 6.15 and later. Select Manage apps, search for Confluence Cloud Migration Assistant and select Update (or Find new apps and Install if missing). Atlassian says versions older than 3.3.7 are no longer supported. Open it from Administration > Migration Assistant.
You should see: The Migration Assistant page opens.
3
Connect to the cloud site
Where: The migration assistant home page > Create new migration > Connect to your cloud site
In each assistant, create a migration, name it, choose testing or production as the stage, and select the destination site under Choose destination cloud site. Atlassian says the stage only helps you tell plans apart on the dashboard.
You should see: The assistant moves on to Migration options with your site selected.

5Assess and plan Marketplace apps4 steps

Apps usually decide the timeline. In each assistant select Assess your apps and set a decision for every app.

Decision	Use when
Needed in cloud	The app and its data must move
Not needed in cloud	Cloud has native features that replace it, it is already on a cloud site, or few people use it
Choose alternative	No cloud version exists or requirements changed; pick a replacement later in the flow

1
Set a decision for every app
Where: The migration assistant > Assess your apps
Set each app to Needed in cloud, Not needed in cloud or Choose alternative. Only apps marked Needed in cloud, with a vendor migration path, are included when you choose All on the Apps card later.
You should see: No app is left without a decision.
2
Read the migration path column
Where: The migration assistant > Assess your apps table
Paths include Automated (built into the assistant), Install-only (data moves with core data), View path (partner's own process), Upgrade app, Contact vendor, and No (no cloud app yet).
You should see: Every Needed in cloud app has a known migration path recorded in your inventory.
3
Contact vendors
Where: Each app's Atlassian Marketplace listing (vendor support contact)
For every app marked Needed in cloud, share your schedule, security needs and support needs with the Marketplace Partner. The assistant does not perform a security assessment of apps.
You should see: Each vendor has confirmed their migration path and support for your dates.
4
Plan app data timing
Where: Your Migration wave plan
Atlassian documents preloading app data and migrating app data separately. Use these for large or complex apps such as ScriptRunner, Zephyr or Xray, which have their own guidance.
You should see: The wave plan shows when each large app's data moves.

No need to uninstall first. Atlassian says Marketplace apps do not need to be disabled or uninstalled from Server before migrating.

6Plan user and group migration4 steps

1
Pre-migrate users and groups
Where: The migration assistant > Create new migration > Migration options > Choose what to migrate > Users and groups card
Atlassian recommends migrating users and groups first, especially above 2,000 users. Later migrations then only move the differences. Create a plan with only the Users and groups card selected and run it.
You should see: Users and groups appear in the cloud site with no projects or spaces yet.
2
Understand email matching
Where: Jira and Confluence user management on the source, and Atlassian Administration (https://admin.atlassian.com) users list
Cloud identifies users by unique email address. If an address already exists in the cloud site, the migrated data links to that account. Fix blank, duplicate or shared email addresses on the source first.
You should see: Every active source user has a unique, real email address.
3
Check group names
Where: Source user management (Groups), compared with the groups in Atlassian Administration
Groups link to existing cloud groups by name, which Atlassian warns could result in permission escalation. Rename server groups that clash with cloud admin or product groups before migrating.
You should see: No source group shares a name with a cloud admin or product access group.
4
Decide on invitations and SSO
Where: Atlassian Administration (https://admin.atlassian.com)
The assistant does not send invitations. Send them from the admin area after migrating, or let users log in. Passwords do not migrate, so without SSO people must set a new password: plan SSO or password resets. If you use LDAP or Crowd, plan your cloud identity provider and Atlassian Guard before cutover.
You should see: A written decision on invitations, SSO and password resets, with the identity provider ready before cutover.

7Run a test migration4 steps

1
Choose scope
Where: The migration assistant > Create new migration (stage: testing) > Migration options > Choose what to migrate
Use the cards to select projects or spaces, users and groups, dashboards, boards and filters, and apps, confirming each with Add to migration. Jira Service Management customers have their own option.
You should see: The plan summary lists the projects or spaces, users and apps you chose.
2
Run pre-migration checks
Where: The migration assistant, the check for errors step of the plan
Fix every error the assistant reports, and record warnings and their remediation in your Pilot test plan.
You should see: The checks show no errors.
3
Migrate to a test site
Where: The migration assistant review page, then its migration dashboard
Run the migration into a test site and time it. Use the timing to size your production window.
You should see: The dashboard shows the plan complete, with a start and finish time you can record.
4
Test with real users
Where: The test cloud site, following your Pilot test plan
Ask project and space owners to check workflows, permissions, macros, links, attachments, dashboards and app features. Known gaps include personal drafts, user-created macros, custom emojis and some space shortcuts in Confluence.
You should see: Owners sign off the test or log defects with a fix before production.

8Run the production migration5 steps

1
Communicate the freeze
Where: Jira: Administration > System > Announcement banner, plus email and your intranet
Tell users when the server instance becomes read-only and when Cloud opens. Put the dates in the Jira announcement banner and in your Cutover runsheet.
You should see: Users see the banner and have the dates in writing.
2
Make the source read-only
Where: Jira: Administration > Issues > Permission schemes. Confluence: each space > Space tools > Permissions
Restrict write access on the server instance during the final migration so no changes are lost. Remove create and edit permissions for user groups, leaving browse access.
You should see: A test user can view but cannot create or edit issues or pages.
3
Migrate in waves
Where: The migration assistant > Create new migration (stage: production)
Run production migrations in the order you tested: users and groups, then projects and spaces, then app data.
You should see: Each production plan shows complete on the assistant dashboard.
4
Reconfigure global settings
Where: Each cloud product's settings, and Atlassian Administration (https://admin.atlassian.com)
Recreate global permissions, settings, application links and integrations in Cloud, and invite users.
You should see: Integrations from your Step 2 list work in Cloud and invited users can sign in.
5
Redirect users
Where: Your intranet, bookmarks guidance and integration configs
Update bookmarks, intranet links and integrations to the cloud URLs.
You should see: Links from the intranet open the cloud site.

9Hypercare and decommission3 steps

1
Monitor migrations
Where: The migration assistant dashboard > each plan's migration details
Use the assistant's migration details pages to review logs and any items that failed.
You should see: Every failed item has been fixed or accepted.
2
Keep the source read-only
Where: The source instance, then your Decommission checklist
Keep the server instance read-only for a period agreed with the business, then back it up and decommission it.
You should see: A final backup is verified before the server is shut down.
3
Review licences
Where: Atlassian Administration (https://admin.atlassian.com), user and product access lists
Users disabled on Server migrate as active but without app access and are not billed as active Jira users. Review app access so you only pay for people who need it.
You should see: Only people who need each product have access to it.

Worth knowing

Expert notes

The detail behind the plan: options compared, and what experienced engineers check first. Tap any item.

Compare all the ways to do this4 options

Migration assistants in a single production run

Medium effort

Best for: Smaller Jira and Confluence instances where a test migration fits inside one agreed outage window

Atlassian calls the Jira Cloud Migration Assistant the easiest and most reliable way to move to Jira Cloud
Moves projects, spaces, users, groups and supported app data, and does not overwrite or delete existing cloud data
Pre-installed in Jira 8.14 and later and Confluence 6.15 and later

Global settings and permissions, passwords (people use SSO or set a new one) and application links still need manual work
Each Marketplace app needs its own decision and migration path

Migration assistants in phased waves

High effort

Best for: Larger instances, especially above 2,000 users, or teams that cannot all move on the same weekend

Users and groups go first, so later waves only move the differences
Each wave is smaller, so outages and rollback are easier to manage

Teams work across two systems until the last wave, so cross-project links and integrations need planning
More test runs, communications and hypercare effort overall

Stay on Data Center for now and migrate later

Low effort

Best for: Organisations already on Data Center with apps or compliance needs that block Cloud today

Buys time to resolve app blockers or wait for vendor cloud versions
No change for users until you are ready

Data Center reaches end of life on 28 March 2029, when products and apps become read-only
New subscription sales to new customers ended on 30 March 2026, so it is not an option for Server customers starting now
You still migrate later, with more data to move

Jira Cloud CSV import

Medium effort

Best for: A handful of Jira projects where only the issues matter and the migration assistant is not an option

No migration assistant needed on the source
Useful for a small, selective issue import

Atlassian says it is not a recommended method because of its limitations
Imports issues only, not users, groups, Confluence or app data

Our advice

Use the migration assistants. Choose a single run if your test migration shows the whole instance moves within an acceptable outage, and waves if it does not or if you have more than about 2,000 users. Staying on Data Center only delays the move to 2029 at the latest, and CSV import is a last resort for issues alone.

Migrate users and groups on their own firstSaves time

Atlassian recommends pre-migrating users and groups, especially above 2,000 users. It shortens the production window because later runs only move differences.

What to do

Run a users-and-groups-only plan days before the production weekend, and check group membership in the cloud site afterwards.

Atlassian Support: Determine your user migration strategy

Rename groups that clash with cloud admin groupsReduces risk

Groups link to existing cloud groups by name. Atlassian warns this could result in permission escalation, for example a server group called site-admins.

What to do

Compare source group names with cloud groups before any migration and rename clashes on the source.

Atlassian Support: How Jira users and groups are migrated

Apps decide the timeline, so start thereSaves time

Apps without an automated path need the vendor's own process, and some have no cloud version. These are the usual cause of slipped dates.

What to do

Run the app assessment in week one, mark Not needed in cloud generously where Cloud has native features, and get written dates from vendors for the rest.

Atlassian Support: Assess Marketplace apps with the Jira Cloud Migration Assistant

Time the test migration to size the outageUser impact

Migration time depends on issue counts, attachments and apps, and a guess is usually wrong.

What to do

Run a full test migration into a test site, record how long each plan takes, and plan the production window from those numbers with a buffer.

Archive and exclude before you migrateSaves time

Old projects, archived issues and large attachments all add to migration time. Projects can be migrated with or without archived issues.

What to do

Exclude dead projects and spaces, and decide per project whether to include archived issues on the Projects card.

Atlassian Support: Migrate Jira data using the migration assistant

Plan sign-in before users arriveUser impact

Passwords do not migrate, so without SSO people must set a new password, and the assistant does not send invitations. Users locked out on day one is the most visible failure.

What to do

Set up SSO with your identity provider (Atlassian Guard) or plan a password reset email, and decide when invitations go out.

Tools that can get around this

With SSO and SCIM provisioning from your identity provider, people sign in to Cloud with their existing work account, so no Atlassian password or invitation is needed. Entra ID matches Cloud accounts by email address, and only users from verified domains receive updates.

Microsoft Entra ID (Atlassian Cloud provisioning)Provisions users, groups and group memberships into Atlassian Cloud and keeps attributes in step; needs Atlassian Guard (formerly Atlassian Access) and a verified domain.

Third-party tools, not endorsed by the platform vendor. Confirm in the tool's documentation and run a pilot first.

Atlassian Support: Determine your user migration strategy

Things the assistants do not moveReduces risk

Global settings and permissions, application links, and some Confluence items (personal drafts, user-created macros, custom emojis) do not migrate.

What to do

List each one in your runsheet with an owner who recreates it in Cloud, and test them in the trial run.

Atlassian Support: What migrates with the Confluence Cloud Migration Assistant

Control who gets product access to control costCost lever

Cloud billing is per user. Users disabled on Server migrate as active without app access, but anyone you grant access to counts.

What to do

Before cutover, clean up inactive users on the source and grant product access in Atlassian Administration only to people who need it. Check Atlassian's current pricing for your tier.

Tools that can get around this

The assistants copy users once and do not remove leavers afterwards. Identity provider provisioning creates only the users you assign and removes them in Cloud when they no longer need access, so billable users do not creep up after go-live.

Microsoft Entra ID (Atlassian Cloud provisioning)Removes users in Atlassian Cloud when they no longer require access, and syncs group memberships from Entra groups. Group renames in Entra are not reflected in Cloud.

Third-party tools, not endorsed by the platform vendor. Confirm in the tool's documentation and run a pilot first.

Atlassian Support: How Jira users and groups are migrated

Keep a read-only source for rollback and referenceReduces risk

If something is missing after cutover, a read-only source lets you check and re-migrate. Data Center becomes read-only at end of life on 28 March 2029 anyway.

What to do

Keep the source read-only for an agreed period after go-live, then back it up and decommission it.

Atlassian: Data Center end of life

Finish safely

Check it worked, or roll back

Full validation checklist9 checks

Run these before you declare the migration complete. Record the results in the data validation report.

Check	How to check	What good looks like
Every production plan completed with failures accounted for	Open each production plan on the migration assistant dashboard and review its migration details page and logs.	Every plan shows complete, and each failed item is fixed or accepted in your Data validation report.
Projects, spaces and issue or page counts match the source	Compare the project and space list from your inventory (Jira: Administration > Projects, Confluence: Spaces > Space directory) with the cloud site. For large projects, run the same JQL search (for example `project = FIN`) on server and cloud and compare the result counts.	Every project and space marked Move exists in Cloud, and issue counts for the sampled projects match the server.
Users and groups linked correctly with no unexpected admin rights	In Atlassian Administration (https://admin.atlassian.com) review the users list and the members of admin and product access groups, and compare them with the source groups.	Every active source user has one cloud account with a unique email address, and admin groups contain only the people you expect.
Users can sign in	Have a pilot group from each department sign in through SSO, or use the password reset or invitation route you chose.	Every pilot user reaches their projects and spaces without an access request.
Permissions behave as on the server	Sign in as a test user in each main group and try to view, create and edit in a restricted project and a restricted space.	Each test user can do exactly what they could do on the server, and nothing more.
Boards, filters, dashboards, macros and attachments work	Ask project and space owners to repeat the checks from your Pilot test plan on the production site: workflows, boards, filters, dashboards, macros, links and attachments.	Owners sign off, and any gap from the known list (personal drafts, user-created macros, custom emojis) is accepted or rebuilt.
Marketplace apps and their data arrived	For each app marked Needed in cloud, open it in Cloud and check a sample of its data with the app owner, following the vendor migration path you recorded.	Each app works in Cloud with its data, or the vendor has confirmed a date for the remaining data.
Integrations, application links and mail point at Cloud	Test each integration from your Step 2 list: application links, webhooks, mail handlers and directory sync. Open intranet links and bookmarks.	Every integration on the list posts to or reads from the cloud site, and intranet links open Cloud.
The server instance no longer takes writes	Sign in to the server instance as a normal test user and try to create an issue and edit a page.	The test user can browse but cannot create or edit, and the announcement banner points to the cloud site.

Rollback planIf it goes wrong

Roll back if

Pre-migration checks or the production plan fail on a project or space you cannot exclude, and the fix will not fit in the window
Users cannot sign in to the cloud site at go-live because SSO or invitations are not working
Users gain admin or product rights they should not have after the users and groups migration
A business-critical app or its data is missing in Cloud and the vendor cannot fix it before the freeze ends
Core integrations (mail handlers, application links, CI or service desk channels) cannot be rebuilt in Cloud in time

Point of no return

The migration assistants copy one way, from server to cloud. They leave the server data in place, so until users start working in Cloud you can reopen the server by restoring write permissions. Once people create issues, comments and pages in Cloud, that work exists only there and has to be copied back by hand. The true point of no return is decommissioning the server instance after the final backup: Server support ended on 15 February 2024, so plan on never rebuilding it. Keep it read-only, and keep the final backup, until the business signs off.

1
Stop users working in Cloud
Where: Your email and intranet, plus the cloud site and Atlassian Administration (https://admin.atlassian.com)
Tell users to stop working in Cloud and record the time. If users already have access, remove product access for user groups in Atlassian Administration, leaving admins in place so you can still investigate.
You should see: No new issues or pages are created in the cloud site after the recorded time.
2
Restore write access on the server
Where: Jira: Administration > Issues > Permission schemes. Confluence: each space > Space tools > Permissions
Put back the create and edit permissions you removed for user groups during the freeze, using the before-and-after record in your Cutover runsheet.
You should see: A test user can create and edit issues and pages on the server instance again.
3
Point users and integrations back at the server
Where: Jira: Administration > System > Announcement banner, your intranet, and each integration you changed
Update the banner and intranet links to say the server is live again, and revert mail handlers, webhooks and application links you moved to Cloud.
You should see: Users open the server from the intranet and integrations post to it again.
4
Copy back any work created in Cloud
Where: The cloud site, with each project or space owner
Search for issues and pages created or changed in Cloud after go-live (for example JQL created >= -2d) and have owners re-enter or export them to the server. There is no tool that moves them back.
You should see: Every item created in Cloud is either on the server or recorded as not needed.
5
Fix and re-plan before trying again
Where: The migration assistant dashboard and your Issue and decision log
Record why you rolled back, fix the cause on the source or in Cloud, and run another test migration into the test site before you set a new production date.
You should see: A logged root cause, a passed test migration and a new date agreed with the business.

Agree the triggers and who decides before the go / no-go meeting. Use the rollback plan template.

Common problems and fixes6 errors

Users gained admin rights after migration

Cause: A server group had the same name as a cloud group with higher permissions; groups link by name.

Fix: Rename clashing groups before migrating and review cloud group membership after each run.

App data missing in Cloud

Cause: The app was not marked Needed in cloud, or it has no automated migration path.

Fix: Check the app assessment table and follow the vendor's migration path.

Users cannot log in to Confluence Cloud

Cause: Passwords are not migrated unless you use SSO.

Fix: Send password reset or invitation emails, or configure SSO before go-live.

Boards or filters missing in Jira Cloud

Cause: Single-project boards or private filters on projects that were not migrated are excluded.

Fix: Include the related projects or recreate the boards and filters.

Jira migration assistant not available

Cause: Jira is older than 8.14 or the app is out of date.

Fix: Install or update the assistant from Administration > Manage apps.

Integrations broken after cutover

Cause: Application links and global settings are not migrated.

Fix: Recreate application links, webhooks and integrations in Cloud.

Search the full error library →

FAQ

Frequently asked questions

When did Atlassian Server support end?

On 15 February 2024. Server products no longer receive updates or security patches.

When does Atlassian Data Center reach end of life?

Atlassian says Data Center subscriptions expire on 28 March 2029, when products and apps become read-only. Expansions and new Data Center app sales end on 30 March 2028.

Is the Jira Cloud Migration Assistant free?

It is a Marketplace app from Atlassian for Jira Server and Data Center and is pre-installed in recent versions. Check Atlassian's cloud pricing for the destination site.

Do Marketplace apps migrate automatically?

Only apps marked Needed in cloud with a vendor migration path. Check the migration path column in the app assessment.

Will the migration overwrite existing cloud data?

Atlassian says data won't be overwritten or deleted. Existing users are matched by email address.

Do users get invited automatically?

No. Atlassian says the assistant does not send invitations; you send them after migrating.

Sources

Official sources

11 official pages this guide is based on

Vendors change limits and features, so confirm details on the source before you rely on them. Last checked 4 Nov 2026.

How to migrate Jira and Confluence Server or Data Center to Atlassian Cloud

Your migration plan

Get ready

Assess your apps

Plan users and sign-in

Run a test migration

Migrate production

Check and decommission

Detailed steps

Inventory projects and spaces

Check versions

Record integrations

Create the cloud site

Jira Cloud Migration Assistant

Confluence Cloud Migration Assistant

Connect to the cloud site

Set a decision for every app

Read the migration path column

Contact vendors

Plan app data timing

Pre-migrate users and groups

Understand email matching

Check group names

Decide on invitations and SSO

Choose scope

Run pre-migration checks

Migrate to a test site

Test with real users

Communicate the freeze

Make the source read-only

Migrate in waves

Reconfigure global settings

Redirect users

Monitor migrations

Keep the source read-only

Review licences

Expert notes

Migration assistants in a single production run

Migration assistants in phased waves

Stay on Data Center for now and migrate later

Jira Cloud CSV import

Check it worked, or roll back

Roll back if

Point of no return

Stop users working in Cloud

Restore write access on the server

Point users and integrations back at the server

Copy back any work created in Cloud

Fix and re-plan before trying again

Frequently asked questions

Official sources