Key Challenges & Context: High-Volume Data Center Environment with Deep App Dependencies
Our client is a global provider of gaming and entertainment technology solutions, serving operators and partners across multiple countries. Their engineering and product teams rely on Jira Software for development workflows and Confluence for technical documentation and cross-team collaboration.
The environment had reached a scale where Data Center maintenance was consuming more effort than it delivered value:
- 300 Jira Software projects with 80 custom workflows built on JSU/JMWE automation
- 300 Confluence spaces with large page hierarchies and legacy macros
- 400 Jira users and 1,400 Confluence users across global teams
- Thousands of workflows, pages, and issue types accumulated over years of organic growth
- Key apps deeply embedded in daily operations: Xray (test management), JSU/JMWE (workflow automation), Time to SLA, EazyBI (reporting), Snow, Backbone (cross-project linking), Checklists, and DynamicForms
The migration target added a layer of complexity: Jira needed to move to a new Atlassian Cloud instance, while Confluence needed to merge into an already existing Cloud environment. Two different targets, two different sets of constraints.
Why this was not a standard migration
- 80 custom workflows with JSU/JMWE dependencies: These weren’t simple status transitions. They were complex automation chains with conditions, validators, and post-functions that governed how work moved through the organization. In Cloud, JSU and JMWE operate under a different execution model. Every rule and transition needed manual audit and rebuild.
- ~20 Backbone connections and ~20 security levels: Backbone (cross-project issue linking and synchronization) had to be re-implemented under Cloud constraints, where the app’s architecture differs significantly. Security levels, used to restrict issue visibility within projects, needed careful remapping to Cloud’s permission model.
- Hundreds of custom fields and complex permission schemes: Years of configuration accumulation had produced a heterogeneous environment where each project had slightly different field configurations, screen schemes, and permission structures. Migrating without standardization would have replicated chaos in a new environment.
- High-volume data integrity: With thousands of issues per project in some cases, ensuring that every issue, attachment, comment, and link migrated correctly was a non-trivial validation challenge.
- Zero downtime requirement: Global teams operating across time zones meant there was no convenient maintenance window. Service continuity had to be maintained throughout.
The Approach: Four-Phase Migration Strategy with Weekend Cutovers
We designed a 4-phase migration strategy specifically to control risk and maintain service continuity. Each phase isolated a different category of complexity, so problems in one phase could not cascade into the next.
Phase 1: Baseline Jira migration (projects without apps)
The first wave migrated Jira projects that had no app dependencies. This established the baseline Cloud setup: project structures, issue types, workflows (standard ones), custom fields, and permissions were validated in Cloud before introducing any app complexity.
This phase served as the proving ground for our migration process. We validated data integrity, confirmed permission behavior, and refined our runbooks before tackling the harder phases.
Phase 2: High-volume Jira projects
The second wave targeted projects with large issue datasets and complex structures. These were the projects where data volume alone created risk: tens of thousands of issues with deep comment threads, extensive attachment libraries, and complex issue link networks.
Attachments were migrated 2 days before each batch cutover. This was a deliberate architectural decision. Attachments represent the heaviest data payload in any Jira migration. By pre-migrating them 48 hours before the project cutover, we reduced the load during the actual migration window and shortened cutover time significantly.
Phase 3: App-dependent Jira projects (weekend execution)
This was the most complex phase. The 80 custom workflows built on JSU/JMWE automation required manual rebuild of key rules and transitions in Cloud. There was no automated migration path for these configurations.
We executed this phase over a weekend, with a dedicated team:
- Pre-built Cloud-compatible versions of all critical JSU/JMWE rules in a sandbox environment
- Migrated the project data (issues, fields, links)
- Applied the rebuilt automation rules and validated behavior against expected outcomes
- Ran UAT with project owners on Monday morning before releasing to all users
The same approach applied to the other app re-implementations: Xray test management configurations, EazyBI report rebuilds, Backbone connection re-establishment, and DynamicForms/Checklists reconfiguration.
Phase 4: Confluence one-shot migration
With Jira fully migrated and stable, we executed a one-shot migration of all 300 Confluence spaces into the existing Cloud instance. Unlike the phased Jira approach, Confluence could be migrated in a single operation because:
- The target instance already existed (no setup required)
- Space-level isolation meant less interdependency risk between spaces
- Legacy macros could be identified and addressed post-migration without blocking users
Post-migration, we addressed legacy macro compatibility issues, validated page hierarchies, and confirmed that cross-product links between Jira issues and Confluence pages resolved correctly in Cloud.
Post-migration stabilization
Every phase was followed by several days of dedicated post-migration support to stabilize users and configurations. This included:
- Resolving user-reported issues in real time
- Fine-tuning automation rules based on actual Cloud behavior
- Adjusting permission configurations where DC-to-Cloud differences surfaced
- Validating that integrations (EazyBI dashboards, Xray test plans, Backbone syncs) functioned correctly under production load
The result: zero migration errors across all four phases.
Benefits: Standardized, Scalable, and Maintainable Cloud Environment
Five months after project kickoff, the client operates a fully consolidated Atlassian Cloud environment serving 1,400+ users.
Standardized and scalable platform
- Fragmented Jira DC and Confluence setups replaced by a unified Cloud environment with consistent configurations
- Hundreds of custom fields rationalized and aligned across projects
- Permission schemes consolidated into a manageable, auditable structure
- New projects can be created from standardized templates instead of ad-hoc configurations
Reduced operational overhead
- Legacy workflow dependencies (JSU/JMWE Groovy-based rules) replaced by Cloud automation where possible, reducing maintenance complexity
- No more Data Center infrastructure management, patching, or upgrade coordination
- Simplified app landscape with Cloud-native configurations that are easier to maintain and update
Improved cross-team visibility
- Unified permissions model gives teams appropriate visibility across projects without the fragmentation of 300 independently configured Jira projects
- Centralized Confluence content (now in a single Cloud instance) makes organizational knowledge discoverable instead of siloed in disconnected spaces
- Backbone connections rebuilt in Cloud provide cross-project traceability that was previously fragile on DC
Higher platform reliability
- Key integrations (Xray, EazyBI, Backbone, DynamicForms) rebuilt under Cloud-compatible architecture, eliminating legacy technical debt
- Cloud’s automatic updates ensure the platform stays current without coordinated upgrade cycles
- Zero migration errors means no data integrity issues lurking in the environment post-migration
Faster delivery
- Simplified workflows and Cloud-native app configurations reduce the time to make changes
- Teams can self-serve on reporting (EazyBI Cloud), test management (Xray Cloud), and automation without platform team intervention
- Lower maintenance effort frees the platform team to focus on improvements rather than upkeep
Key Takeaway
Migrating 300 Jira projects with 80 custom workflows and deep app dependencies is not a lift-and-shift exercise. It’s a controlled rebuild. The apps that make Data Center environments powerful (JSU, JMWE, Backbone, Xray) are also the ones that make migration complex, because their Cloud versions operate differently.
The four-phase approach, isolating complexity by category and validating each phase independently, is what made zero-error delivery possible at this scale. Organizations facing similar migration complexity should expect that the app re-implementation phase alone will represent 40-50% of total project effort.
If you’re evaluating what your own migration would look like, a structured assessment is the right first step.
