Atlassian Practice ยท Cloud Migration
A six-stage methodology, not a vendor migration wizard
Every migration runs this sequence. The schedule stays explicitly tentative until Prepare, because app inventory and org structure surface things no kickoff call can predict.
"We've worked with Veraxent across our Data Center to Cloud migration and multiple rounds of post-acquisition consolidation over the last three years, bringing Synq3, Amelia, and Interactions onto a single Atlassian platform. Each engagement came with its own complications: compressed timelines, evolving scope, systems we didn't fully understand ourselves yet. They were consistently responsive, delivered on time, and stayed within budget even when scope grew mid-project."
Data Center end-of-life timeline
Announced
Atlassian announces Data Center end of life.
Status: passed.New sales close
New customers can no longer buy Data Center subscriptions or Marketplace apps.
Status: passed.Last new purchases
Last day for existing customers to buy new Data Center subscriptions, Marketplace apps and expansions.
Status: upcoming.End of life
Data Center subscriptions expire and products become read-only.
Status: upcoming.
Filled marker: the date has passed. Hollow marker: still ahead.
- Existing customers can keep renewing their Data Center subscriptions until end of life on March 28, 2029.
- Jira Align is excluded from Data Center end of life.
- Existing Bitbucket Data Center customers get a hybrid license that extends access to both Bitbucket Data Center and Bitbucket Cloud past March 2029.
Source: Atlassian, "Data Center End of Life," atlassian.com/licensing/data-center-end-of-life. Verified as of September 2026.
The Methodology
- 01
Assess
- Map stakeholders: technical, PMO, and business liaisons per business unit
- Establish migration priority and sequencing; identify deadlines and blackout periods
- Inventory users, SSO, and admin governance
- Inventory data and apps, usually the single biggest unknown
- Map integrations: app links, email, API, connectors
- Assess app migration paths: automated, vendor-supported, manual rebuild, replace, or retire
- 02
Plan
- Decide migration scope and sequencing: all-at-once vs. selective or phased migration, including anything that requires a vendor-supported or manual path
- Determine what gets cleaned up, reimplemented, or replaced
- Assign action ownership and phase work by business unit and priority
- Build a schedule that stays explicitly tentative
- Identify data that can be pre-migrated to reduce cutover time
- 03
Clean Up
- Delete, retain, or streamline obsolete data
- Consolidate workflows and convert inactive projects to read-only
- Archive retained data that does not need to move into active Cloud
- Retire obsolete integrations, automation, fields, and configuration
- Resolve duplicate or conflicting configuration before migration
- 04
Prepare
- Run a test migration
- Handle user mapping, particularly for org merges
- Validate and execute the migration path for each app: automated, vendor-supported, tooling-assisted, or manual
- Rebuild high-risk entities: ScriptRunner post-functions, listeners, dynamic forms
- Run proof-of-concepts on the highest-risk items
- Run and clear pre-migration checks ahead of cutover
- 05
Test
- Validate migrated data and critical object counts against the source environment
- Validate identity, permissions, integrations, automation, and app behavior
- End users and stakeholders run representative business-critical UAT
- Triage and remediate issues
- Authorize production migration only after agreed exit criteria are met
- 06
Migrate
- Execute production migration using the sequencing and cutover model validated in Prepare
- Migrate app data and integrations using the approach validated in Prepare
- Run production validation, smoke testing, and targeted business validation, then make an explicit go/no-go call
- Provide defined post-migration hypercare, issue triage, and stabilization
Migration complexity is not merely a size metric
User count, issue volume, and app count matter, but none predicts migration effort on its own. Integrations, automation, custom configuration, identity, and the number of entities hidden inside individual apps often matter more.
Illustrative ordinal categories — Low, Moderate, High, Very High — not a scoring model.
Scale
Users
- Environment A
- Very High
- Environment B
- Moderate
Issues & data volume
- Environment A
- Very High
- Environment B
- Moderate
Complexity
Integrations
- Environment A
- Moderate
- Environment B
- High
App & plugin entities
- Environment A
- Low
- Environment B
- Very High
Automation rules
- Environment A
- Moderate
- Environment B
- Very High
Custom fields & configuration
- Environment A
- Moderate
- Environment B
- High
Identity & user mapping
- Environment A
- Low
- Environment B
- High
Reading the comparison: Environment A is larger by users and data volume. Environment B is more complex across configuration, integrations, automation, app entities, and identity.
A smaller environment can be the harder migration. Assess exists to find the dimensions that actually drive effort before the schedule is treated as real.
When the documented path ends
The hardest part of a large migration is rarely the standard objects. It is the data types, configuration, app entities, and blocking errors that do not have a clean documented path. That is where the team’s engineering background matters: understanding the platforms beyond the admin layer, tracing problems into APIs and underlying data structures, and building scripts or other repeatable tooling where necessary. We treat those cases as engineering problems to solve, not automatic scope exclusions.
That capability also extends beyond Atlassian-to-Atlassian migrations. We work with source platforms and apps that do not translate one-to-one into Jira or Confluence, defining what can be preserved, transformed, rebuilt, or intentionally left behind before cutover.
Start with an assessment
No commitment past a look at your instance, your apps, and where the real risk sits.