Veraxent
Contact

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.

Start with an assessmentBack to Atlassian Practice

The Methodology

Recognized as an Atlassian Cloud Migration Specialized PartnerAtlassian Cloud Migration Specialized Partner, AMER
  1. 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
  2. 02

    Plan

    • Decide full site migration vs. Jira Cloud Migration Assistant, per instance
    • 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
  3. 03

    Clean Up

    • Decide what gets deleted outright, retained for audit, or streamlined
    • Consolidate workflows; convert inactive projects to a read-only scheme
    • Mark more data read-only to enable async migration without a scheduled outage
  4. 04

    Prepare

    • Run a test migration
    • Handle user mapping, particularly for org merges
    • Migrate app data via JCMA, tooling, vendor or custom scripts
    • Rebuild high-risk entities: ScriptRunner post-functions, listeners, dynamic forms
    • Run proof-of-concepts on the highest-risk items
  5. 05

    Test

    • End users and stakeholders run UAT
    • Issues triaged, prioritized, and fixed jointly
    • Production migration authorized only after sign-off
  6. 06

    Migrate

    • Production migration inside a defined maintenance window sized to avoid data drift
    • Migrate app data and integrations using the approach validated in Prepare
    • Repeat UAT and make an explicit go/no-go call
    • 48 hours of hypercare support post-migration

The app inventory is usually the biggest unknown

A single app, ScriptRunner is the canonical example, can contain hundreds of entities. Some are trivially re-implementable. Some, like post-functions, listeners, and scripted fields, take a week or more to rebuild and test. Assess exists to find that out before it becomes a Prepare surprise.

App inventory risk, below the surfaceA single app can contain hundreds of entities. Some are visible in the marketplace panel and trivially re-implementable. Most sit below the surface: post-functions, listeners, and scripted fields that take days to a week or more to rebuild and test.Visible in the marketplace panelJira app AConfluence appScriptRunnerConnector appWhat that one app actually containsTrivially re-implementableSimple custom fields, basic notification schemes, static shared filtersDays of rebuild and validationMulti-condition workflow transitions, calculated fields, board configurationsA week or more to rebuild and testScriptRunner post-functions and listeners, dynamic forms, scripted fields:the entities that determine whether the timeline holds

Start with an assessment

No commitment past a look at your instance, your apps, and where the real risk sits.

Get in touch