As an Atlassian Expert consultant, I’ve led numerous Jira Data Center to Cloud migrations, each with its unique challenges and learning opportunities. In this post, I want to share a recent migration experience that perfectly illustrates why having a well-defined strategy is crucial, and how that strategy might need to evolve throughout the project to address unexpected challenges.

The Initial Assessment: Expect the Unexpected

What appeared to be a relatively straightforward migration compared to other projects I’ve led turned into an interesting case study in risk management. During the initial assessment phase, we encountered an issue where the ScriptRunner plugin page appeared to not load at all. Based on our analysis of the rest of the instance, which showed minimal complexity, we made an assumption about ScriptRunner’s usage being similarly straightforward. This appeared to be a technical issue with the page itself rather than an indication of extensive ScriptRunner usage.

This assumption was deliberately documented in our Statement of Work (SOW), which proved to be a crucial decision. We specifically stated that our estimation considered ScriptRunner as being minimally utilized. This documentation became our safety net when we later discovered the actual situation: the page was loading slowly due to an unexpectedly large number of scripts.

Key Lesson: Always document your assumptions and limitations in your project scope. When dealing with unknowns that could potentially impact the project, make sure to explicitly state these in your contractual documents.

The Reality Check: 400+ Scripts to Migrate

During the project execution phase, not during the initial assessment, we discovered that the ScriptRunner page was actually loading – it just took several minutes to complete due to the sheer volume of configurations it was trying to display. This was a significant revelation that changed our understanding of the project scope: we discovered over 400 scripts that needed migration. This revelation led to a change request for the project. However, it’s important to note that this situation was well-handled from the start: during the assessment phase, we had explicitly documented in our SOW that we were assuming minimal ScriptRunner complexity since we couldn’t access the page. We made it clear that resolving technical issues like extremely slow-loading pages was outside the assessment scope – after all, the assessment phase is meant for evaluation, not troubleshooting infrastructure problems. This documentation proved invaluable as the client understood and accepted that this was a known risk they had taken on. When the true scope of ScriptRunner usage became clear, the client readily acknowledged the need for additional work through a change request. Interestingly, about 90% of these scripts were performing simple operations like field validation or field clearing – functionality that could be replaced with out-of-the-box (OOB) features in Jira Cloud.

We began the process of documenting and replacing these scripts in our sandbox environment, mapping old functions to new ones. However, it quickly became apparent that manually reproducing these changes in production would be extremely risky due to the volume of changes required.

Finding Solutions: From Manual to Automated

The challenge of transferring workflows from sandbox to production led us down several paths. Given the large number of scripts (400+), we needed to be strategic about our approach:

  1. AI-Assisted Script Translation
    • We leveraged ChatGPT extensively to help translate complex scripts from Data Center to Cloud versions
    • This proved especially valuable for more intricate scripts that required significant rewrites for Cloud compatibility
    • The AI tool helped accelerate the translation process while ensuring accuracy in the script logic
  2. Automation Attempts
    • Initially, I attempted to develop a Python script to automate the transfer of workflows
    • The goal was specific: automatically move all workflows with their modifications from sandbox to production environment
    • This would ensure that all the script replacements and modifications we had tested and validated in sandbox could be replicated exactly in production
    • However, this automation attempt proved more complex than anticipated due to the intricate nature of the API and ScriptRunner’s encoded storage format
  3. Solution Discovery and Evaluation
    • Eventually, we discovered Salto, a tool designed for cloud-to-cloud and Data Center-to-Data Center configuration migration
    • We thoroughly evaluated the tool in our internal environments, performing multiple tests to validate its capabilities
    • After confirming its effectiveness, we presented the tool to the client, explaining its benefits and potential risks
    • The client reviewed and approved the use of Salto as part of our migration strategy

Timeline Extension and New Risks

Several months passed between our sandbox migration and the decision to proceed with production migration. This delay was intentional and driven by the client’s strategic needs:

  • Unified Authentication Experience: The client wanted to ensure a seamless transition for their users. Rather than migrating with Atlassian’s default SSO and then switching to PingID days later, they required a single, unified authentication experience from day one. This meant implementing and configuring PingID before proceeding with the migration.
  • Change Management Process Implementation: The client had developed a new workflow for handling organizational changes, and they wanted to train and familiarize their users with this new process while still in the Data Center environment. This strategic decision allowed users to adapt to the new change management workflow before introducing the additional changes that would come with the cloud migration.
  • Training and Adaptation Period: By implementing and training users on the new change management process before the cloud migration, the client ensured that their teams would be comfortable with their new workflows before having to deal with the cloud platform changes. This phased approach to change helped reduce the overall impact on user productivity and satisfaction.

While these delays were necessary to ensure a smooth user transition, they introduced new risks to our migration plan. The extended timeline meant that:

  • Our sandbox migration was now several months old
  • The production environment had continued to evolve
  • The effectiveness of our previous migration tests might no longer reflect current conditions

With these new considerations in mind, we presented two risk mitigation strategies:

Option 1: Proceed with Production Migration

This option carried three known risks:

  • Potential JCMA errors due to the time gap since our last migration
  • Possible Zephyr migration issues, which had caused significant problems previously
  • Uncertainty about Salto’s performance with large-scale workflow modifications

Option 2: Additional Risk Mitigation

This more cautious approach would involve a complete test run in a separate environment before attempting the production migration. Here’s what it would entail:

  1. New Test Environment Setup
    • Creating a new Jira instance completely separate from the client’s organization
    • This separation was important to ensure a clean testing environment
    • The approval process for this new instance would require additional time due to security and compliance requirements
  2. Trial Migration Process
    • Performing a complete test migration of both Jira and Zephyr to this new environment
    • This would help verify that the JCMA tool was still working correctly with current data
    • It would also validate that our Zephyr migration fixes were still effective
    • The goal was to catch any potential issues before touching the production environment
  3. Workflow Migration Testing
    • Using Salto to migrate all modified workflows from the sandbox environment to this new test instance
    • This would serve as a full-scale test of Salto’s capabilities with our specific use case
    • We could verify that all 400+ scripts and their replacements were correctly transferred
    • Any issues could be identified and resolved without impacting the production timeline
  4. Resource Implications
    • This approach would require a new change request to cover additional project hours
    • The client would need to allocate more budget for the extended testing phase
    • The project timeline would need to be extended to accommodate these additional steps
    • However, this would significantly reduce the risk of production issues

The Decision: Calculated Risk-Taking

After careful consideration of both time and risk factors, the client chose to proceed with Option 1, accepting the identified risks. This decision was made with a clear understanding that rollback to Data Center was always possible if needed.

Key Takeaways

  1. Client Expectation Management is Crucial Setting clear expectations with the client about potential risks and mitigation strategies creates a more collaborative and understanding project environment.
  2. Risk Assessment is an Ongoing Process Project risks aren’t static – they evolve and new ones emerge throughout the project lifecycle. Regular reassessment and transparent communication with the client about new risks and mitigation options is essential.
  3. Automation is Your Friend Always look for ways to automate manual work, whether through custom scripts or existing solutions. In our case, Salto significantly reduced what could have been days of post-migration work.
  4. Tool Highlight: Salto’s Potential Salto treats Jira configurations as code, similar to Git, and can migrate various Jira elements including workflows, projects, custom fields, filters, and dashboards. Even with just the trial version, it proved to be an invaluable tool for our migration process.

Looking Forward

This migration reinforced that successful Jira Data Center to Cloud migrations require more than just technical expertise – they need careful risk management, clear communication, and a willingness to adapt strategies as new challenges emerge. By maintaining transparency with clients and continuously seeking ways to improve our migration processes, we can ensure better outcomes for future migrations.