Project • In progress

Atlassian Cloud Migration

As part of the Atlassian Cloud migration, SLAC IT will establish two separate Confluence cloud instances (environments): Open Science Confluence for external research collaboration and SLAC Secure Confluence for internal use. 

This migration improves security, supports DOE compliance requirements, and enables a more scalable and sustainable service model. It also ensures continued vendor support, as Atlassian has announced the end of life of its Data Center products.

Atlassian Data Center support is ending, and we are already on extended support.

Project
Complete

Key Points

• SLAC is moving Jira and Confluence to Atlassian Cloud

• The use of the current on-premises Data Center product will be shut down completely on Sunday, 11/15 at noon PST

• Most users will only need to update their bookmarks when notified

 

graphic - solid bar

Why We're Migrating

SLAC's current Atlassian environment operates on on-premises infrastructure that supports both Open Science Confluence collaboration and internal mission support activities. As collaboration needs, security expectations, and vendor platforms evolve, this model is no longer the most effective long-term approach.

What's changing?

SLAC will operate two Confluence Cloud instances:

  • Open Science Confluence instance: for research collaborations without any cybersecurity-sensitive content
  • SLAC Secure Support Confluence instance: for internal mission support functions and work requiring enhanced cybersecurity controls

Assignment of Confluence spaces to an instance is based on cybersecurity and collaboration requirements and is not user-selectable. Space owners will be contacted to review requirements and confirm the correct placement.

All Jira projects will move to Atlassian Cloud and will be hosted in a secure Cloud instance aligned with SLAC cybersecurity and access control requirements.

Jira will continue to support operational and project management workflows, with access governed through SLAC single sign-on (SSO) and group-based authorization.

 

  • The legacy Crowd authentication system will be retired.
  • Users will continue to log in using SLAC single sign-on (SSO).
  • Space owners (in Confluence) and project owners (in Jira)  will manage membership for their spaces and projects through SLAC-managed group services (Grouper) instead of submitting requests to SLAC Atlassian administrators.
  • Most users will not need to take action related to access changes beyond using the new Cloud URLs once they are provided.
  • Non-employees will need to register their federated accounts with the SLAC Guest Gateway (SGG). 

  • Jira and Confluence will have new Cloud-based URLs.

  • The Cloud user interface differs somewhat from the current on-premises experience.

  • Core functionality will remain familiar, though some navigation and features may appear in different locations.

  • Some plugin functionality may change or require alternatives.

  • All plugins, macros, customizations, and integrations are being reviewed for Cloud compatibility.

  • Some functionality may require changes, alternatives, or retirement where Cloud equivalents differ.

  • Space owners and integration owners will be contacted directly if review or action is required.

What stays the same?

While the platform is moving to Atlassian Cloud, many aspects of how users work with Jira and Confluence will remain familiar.

  • All in-scope Jira projects and Confluence spaces will be migrated to Atlassian Cloud.
  • Existing content, pages, and attachments will remain available after migration.
  • SLAC single sign-on (SSO) will continue to be used for access.
  • Core Jira and Confluence functionality will remain available in Cloud.
  • Collaboration with internal teams and external partners will continue.

Some workflows, plugins, or integrations may require adjustments as part of the migration. Where changes are needed, affected owners will be contacted and supported through the process.

What we need from users

Different groups will be involved at different points in the migration. Actions will be requested only where needed and communicated in advance.

  • Confirm space ownership. All spaces need an identified owner before migration.
  • Review your space for outdated content, permissions, and plugin dependencies.
  • Work with the project team if clarification is needed on instance placement.
  • Participate in validation activities when invited.
  • Communicate upcoming changes to your teams and collaborators.

  • Identify critical workflows and collaboration-specific requirements.
  • Help communicate migration plans and timelines to your global collaborators.
  • Participate in validation of test migrations for your collaboration's spaces and projects where requested.
  • Plan collaboration activities around communicated migration windows to minimize impact on research activities.

  • Review custom code, scripts, integrations, and customizations for Cloud compatibility.
  • Plan updates or remediation where Cloud APIs or functionality differ.
  • Participate in testing and validation of updated integrations as needed.

  • Support for LCLS and AD: The platform helps manage large text-based data sets, assisting teams in LCLS and AD with data categorization and summarization.
  • Expanding knowledge connections: Future expansions will include more SLAC knowledge collections and connections to external DOE knowledge sources.

  • Watch for updates via SLAC Today, targeted emails, and #slac-it-official so you know when changes are coming and what actions are needed.
  • Complete any requested surveys to help inform the planning and readiness.
  • If invited, participate in testing to help validate common workflows.

In most cases, no action will be required beyond using the new URLs and becoming familiar with minor user interface changes.

How we will support you

  • Clear, advance communication before any user-impacting changes.
  • Targeted outreach to affected owners and stakeholders.
  • Updated Knowledge Base articles and support documentation.
  • Service Desk support for login, access, and general questions.

Role

Name

Executive Sponsor

Jon Russell

Project Sponsor

Kevin Purcell

Business Owner

Kevin Purcell

Technical Lead

Gaven Ray

Team MemberMai Tran

Project Manager

Pierre Joseph

Atlassian Cloud Migration Timeline
  • Complete
    Project Initiation and Discovery 

    Initial project setup, scope definition, and early stakeholder engagement

  • Complete
    Planning and Assessment 

    Assessment of Jira and Confluence environments, review of plugins and integrations, and preparation for migration planning

  • Complete
    Migration Planning and Readiness

    Finalization of migration approach, access model readiness, and preparation for migration execution.

  • November 13-15, 2026
    Migration Execution

    Migration of Jira and Confluence to Atlassian Cloud, followed by validation and transition to operations.

  • November 16 and beyond
    Post-Migration Support and Optimization

    Stabilization, user support, and follow-up improvements after migration completion.

  • FY27 Q1
    Target Completion

Frequently Asked Questions

Migration Process & Timeline

Yes, all projects and spaces will be migrated to Atlassian Cloud. However, each space/project must have an identified owner.

The timeline evolved through our preliminary work with the migration partner. They analyzed our sites and assessed their readiness for migration. Also note that stretching schedules increases cost, sometimes considerably, when engaging external vendors. We are planning to complete the production migration by November 17, 2026.

We will not be upgrading past minor version updates.

Access & Downtime

There will be planned downtime windows during the cutover. We will communicate these well in advance and work to minimize disruption.

The Atlassian Data Center products will be read-only during the migration downtime. No edits will be allowed during this time.

You'll continue using SLAC single sign-on (SSO). The first time you log in, use an incognito window and your SLAC email address. When you reach the SSO Screen, use the SLAC Button. This will ensure your account is activated properly in Atlassian Cloud.

Yes. To provide continuity between the Open Science Confluence and SLAC Secure Confluence instances, we have developed a method to keep existing URLs redirecting to Atlassian  Cloud. 

There will be no changes to the number of licenses. We will have sufficient licenses for both SLAC Secure Confluence and Open Science.

  • Host sponsors will invite external users to obtain a registered account via the SGG process. 
  • For a user to gain access to Atlassian applications, a host sponsor will need to initiate a ServiceNow ticket to add the user to the appropriate Confluence or Jira groups.
  • Immediately after the production migration, SLAC IT Atlassian admins will update group membership in the Grouper access management application. As we become more familiar with this process, space owners (in Confluence) and project owners (in Jira) will manage membership for their spaces and projects through Grouper, rather than requesting changes from SLAC IT Atlassian administrators.

Technical Changes

We're assessing all plugins for Cloud compatibility. Some may have Cloud equivalents, while others may require alternatives or retirement. Integration owners will be contacted directly if action is required.

Most plugins will migrate without issues. A few will need to be replaced. We will provide a full update once we start working with the vendor. API requests will need to be updated. We will determine the required changes during the User Acceptance Testing phase. Until then, if your team uses API calls to either Jira or Confluence, you should read about the changes at https://developer.atlassian.com/

Instance Assignment & Management

Confluence spaces will be assigned based on cybersecurity guidelines and collaboration requirements. Space owners will be notified of their assigned instance. In cases where the appropriate instance is not immediately clear, space owners will be contacted to review requirements and confirm placement. 

Space owners (in Confluence) and project owners (in Jira) will manage membership for their spaces and projects through Grouper, rather than requesting changes from SLAC's Atlassian administrators.

 

Yes, Confluence spaces may be moved between instances. This process can be initiated with a ServiceNow ticket.

Communication & Support

As the project progresses, we will notify affected users and owners through targeted communication. Outreach methods may include direct email to affected owners, coordination through program leads for scientific collaborations, and Lab-wide updates via SLAC Today and #slac-it-official. Not all users will be contacted individually. Direct outreach will be limited to those involved in specific migration activities.

Contact the Service Desk for general support, or reach out to the project team at apps-platforms@slac.stanford.edu. Your IT Business Partner can also help with directorate-specific questions. 

There will be a testing period for users. We can also reach out to our vendor for further assistance. Group Admins can update groups using Grouper. IT will no longer need to manually add users to groups. ServiceNow will still be the place to open tickets for Confluence and Jira changes.