Key Challenges & Context: Clustered Data Center, 3000 Users, and Deep Customization Debt
Our client is one of France’s largest online retailers, operating a high-traffic e-commerce platform that serves millions of customers. Their technology organization relies on Atlassian tools as the backbone of engineering workflows, service management, and cross-team collaboration.
The environment was substantial:
- Jira Software and Jira Service Management on clustered Data Center, supporting 3000 active users across engineering, product, operations, and support teams
- Confluence Data Center serving as the central knowledge base for technical documentation, runbooks, and project coordination
- 100,000+ assets managed in Jira Service Management (formerly Insight/Assets)
- 200 ScriptRunner scripts embedded in workflows, automations, post-functions, and scheduled jobs
- Dozens of Marketplace apps integrated into daily operations
The client had already identified the need to move to Cloud. Atlassian’s end of support for Data Center in March 2029 set the strategic direction, but the real driver was operational: they wanted to eliminate the infrastructure overhead of managing clustered instances, reduce upgrade cycles, and unlock Cloud-native capabilities (Atlassian Intelligence, native automation, advanced roadmaps) that their teams were requesting.
The challenge was not whether to migrate, but how to migrate an environment of this complexity without disrupting a 3000-person engineering organization that ships code daily.
What made this migration complex
- ScriptRunner at scale: 200 Groovy scripts is not a configuration detail. It’s a parallel codebase. These scripts handled everything from custom field calculations and automated transitions to scheduled data synchronization and complex validators. In Cloud, ScriptRunner operates under a fundamentally different execution model: no direct server access, Atlassian Cloud APIs only, strict rate limiting. Every script needed to be audited, classified, and either rewritten for Cloud, replaced by native automation, or decommissioned.
- 100,000 assets in JS: The CMDB was deeply integrated into service management workflows. Assets were linked to incidents, changes, and service requests. Object schemas, import sources, and automation rules all needed to migrate intact, and Assets in Cloud behaves differently from Insight in Data Center in several areas (import scheduling, AQL syntax nuances, integration patterns).
- Clustered architecture: Running Jira and Confluence in clustered mode meant the environment was designed for high availability and horizontal scaling. Migrating from a clustered topology to Cloud required careful planning around data consistency, session management during cutover, and validation that nothing was lost between nodes during the migration window.
- Marketplace app ecosystem: With dozens of apps installed, each one represented a migration decision. Some had automated Cloud migration paths. Others required manual reconfiguration. A few had no Cloud equivalent at all, requiring functional alternatives or custom development.
This level of migration complexity is exactly why we recommend a structured assessment before committing to a timeline.
The Approach: Assessment, Remediation, and Phased Cutover
We structured the project in four phases over 6 months, with a dedicated team working alongside the client’s platform engineers.
Phase 1: Assessment and Architecture (Months 1-2)
The first phase produced the migration blueprint. We conducted a full audit of the environment covering:
- Complete inventory of ScriptRunner scripts with criticality classification (must-migrate, nice-to-have, decommission)
- Marketplace app compatibility analysis with migration path for each (automated, manual, replace, remove)
- Assets schema review and Cloud compatibility validation
- Permission scheme audit and consolidation recommendations
- Integration mapping (CI/CD pipelines, monitoring tools, internal platforms connected via API)
- Identity management assessment, leading to SSO implementation with Microsoft Entra ID as part of the Cloud readiness workstream
This phase delivered a detailed migration plan with effort estimates, risk register, and sequencing logic. The client’s leadership used this to secure budget and align stakeholders across the organization.
Phase 2: Pre-Migration Remediation (Months 2-3)
Before touching the migration tools, we addressed the technical debt that would have complicated or blocked the migration:
ScriptRunner remediation. We classified all 200 scripts into four categories:
- Scripts replaceable by native Jira Automation rules (approximately 40%)
- Scripts that needed rewriting for ScriptRunner Cloud’s execution model (approximately 30%)
- Scripts that required Forge app development as replacement (approximately 10%)
- Scripts that were obsolete or redundant and could be decommissioned (approximately 20%)
For the scripts requiring rewrite, we developed and tested Cloud-compatible versions in a sandbox environment before migration.
App rationalization. We worked with the client to decommission unused apps, consolidate overlapping functionality, and validate migration paths for critical apps. For apps without Cloud equivalents, we implemented alternatives and ran them in parallel on Data Center to validate before cutover.
Data cleanup. Inactive projects, orphaned workflows, duplicate permission schemes, and unused custom fields were cleaned to reduce migration scope and simplify the target environment.
Phase 3: Migration Execution (Months 3-5)
We executed the migration using Atlassian’s Cloud Migration Assistants (JCMA for Jira/JSM, CCMA for Confluence) in controlled batches:
Jira Software migrated first, in waves organized by project portfolio. Each wave followed the same protocol:
- Pre-migration validation (data integrity checks on source)
- Test migration in sandbox (full content, permissions, workflows)
- UAT with project owners
- Production migration during a planned maintenance window
- Post-migration validation (issue counts, attachments, links, permissions)
Jira Service Management followed, with particular attention to:
- Assets/CMDB migration and schema validation
- SLA configuration testing (calendar behavior differs between DC and Cloud)
- Portal configurations and customer-facing forms
- Queue behavior and automation rule compatibility
Confluence migrated last, leveraging our experience from previous large-scale Confluence migrations. Spaces were batched by department, with UAT cycles confirming content integrity, macro rendering, and permission inheritance.
Phase 4: Stabilization and Handover (Months 5-6)
The final phase focused on:
- Hypercare support for all 3000 users during the first weeks post-migration
- Performance monitoring to identify and resolve any Cloud-specific behavior differences
- Documentation of the new environment’s architecture, governance model, and operational procedures
- Knowledge transfer to the client’s platform team for autonomous Cloud administration
- Decommissioning of the Data Center infrastructure once all validation gates were passed
Benefits: Reduced Operational Overhead, Modern Capabilities, and Scalable Governance
Six months after project kickoff, the client’s entire Atlassian environment runs on Cloud Enterprise.
Infrastructure burden eliminated
- No more cluster management, node patching, or database maintenance
- No more coordinated upgrade windows requiring downtime
- Atlassian handles availability, performance, and security patching continuously
- The platform team reallocated approximately 30% of their time from infrastructure maintenance to value-adding platform engineering work
Modern capabilities unlocked
- Atlassian Intelligence available across Jira and Confluence, giving teams AI-powered search, summarization, and content generation
- Advanced Roadmaps (Plans) in Cloud, enabling cross-team planning at portfolio level
- Native automation replacing the majority of ScriptRunner scripts with a no-code interface that business teams can maintain themselves
- Cloud-native integrations with the client’s CI/CD pipeline, monitoring stack, and communication tools via Forge and Connect apps
Governance and security improved
- Atlassian Guard Premium providing organization-wide security policies, data classification, and audit logging
- Data residency configured for EU, ensuring data at rest stays within European boundaries (relevant for GDPR compliance)
- Centralized identity management via Microsoft Entra ID with SCIM provisioning, eliminating manual user administration
- Simplified permission model after consolidation from 80+ schemes to 12 standardized schemes
Cost predictability
- Licensing moved from perpetual + maintenance to a predictable annual subscription
- Infrastructure costs (servers, storage, networking, monitoring) eliminated entirely
- Total cost of ownership reduced when factoring in the platform team hours previously spent on maintenance
Key Takeaway
Migrating 3000 users from clustered Atlassian Data Center to Cloud Enterprise in 6 months is achievable, but only when the project is treated as a transformation rather than a lift-and-shift. The 200 ScriptRunner scripts alone represented weeks of analysis and rewriting. The 100,000 assets required schema-level validation. The app ecosystem needed rationalization, not just migration.
The organizations that succeed at this scale are the ones that invest in a proper assessment phase before committing to a go-live date. The assessment is what turns “we need to migrate” into “here’s exactly how, in what order, and by when.”
