[Update May 2025: The dates for the EAP stand delayed. Please stay tuned for further updates]

      [Update Sep 2024: We have added this to our roadmap are looking to have an EAP in June 2025]

      Problem Definition

      Customers are not able to push data/per project from sandbox to production. This is important as users would like to prepare their projects and push them to production.

      Suggested Solution

      Customers want the ability to push data/per project from sandbox to production.

      Why this is important

      Easily push projects to the production site.

      Workaround

      1. Take a CSV export from the sandbox and import the data into the production site.
      2. Or, use the Cloud - Cloud Migration feature.

      We don’t recommend copying data from sandboxes to your production instances using the Copy product data feature. When you copy data from a production instance to a sandbox, we copy configurations such as custom fields. When you copy data back from the sandbox to the production instance using the Copy product data feature, we create duplicate configurations. 

            [CLOUD-11150] Ability to push data from sandbox to production

            Also it would be helpful if i can select what needs to be copied like: 
            Issue types, Forms, Workflows etc. and not all. 

            Also there should be a support for exporting and importing via a serializable object which only people with project admins can do. Project admins should be able to control the project in their completeness and not rely on Site-Admins.  

            Ayush Chaturvedi added a comment - Also it would be helpful if i can select what needs to be copied like:  Issue types, Forms, Workflows etc. and not all.  Also there should be a support for exporting and importing via a serializable object which only people with project admins can do. Project admins should be able to control the project in their completeness and not rely on Site-Admins.  

            Please release the release of this function as soon as possible, we need it!

            nancy xu/xuqiannan added a comment - Please release the release of this function as soon as possible, we need it!

            It's also worth pointing out that every time I've tried the CSV import OR the cloud migration tool, any fields the new project is using in the sandbox get re-created as duplicate fields with new ID's. 

            As an example, we have 3 copies of "Due Date". Different projects actually use all 3 different "Due Date" fields. With different IDs. And it's really hard to disambiguate which field is which. Since they are all named the same.

            William Wilson added a comment - It's also worth pointing out that every time I've tried the CSV import OR the cloud migration tool, any fields the new project is using in the sandbox get re-created as duplicate fields with new ID's.  As an example, we have 3 copies of "Due Date". Different projects actually use all 3 different "Due Date" fields. With different IDs. And it's really hard to disambiguate which field is which. Since they are all named the same.

            I appreciated that there is an update on this topic but disappointed on the pushing the date for availability even further into the future.

            But what I would like to be clarified:

            Does it eventually include pushing CONFIGURATION from the sandbox into production - which IMHO is more important than data. If itis NOT included should we create another feature request for that? Albeit it would for sure not happen before 2030? </sarcasm>

            Jochen Betz added a comment - I appreciated that there is an update on this topic but disappointed on the pushing the date for availability even further into the future. But what I would like to be clarified: Does it eventually include pushing CONFIGURATION from the sandbox into production - which IMHO is more important than data. If itis NOT included should we create another feature request for that? Albeit it would for sure not happen before 2030? </sarcasm>

            15b3b63090ad - Very true. Especially in the case of duplicate entries and cleanup. 

             

            That said, I'll take small wins. FOR NOW. If I have the option to move a single Jira [Service Management] Project to another instance / site, I'm far happier cleaning up "Copy of" items, than having to duplicate my other efforts by hand. Situationally dependant of course. So, my thought is that it might be a good stop-gap for some of us. Again.... situationally, depending on the complexity of the changes. We have some that are just easier done by hand, and others that are very complex, and make me value the ability to get it done, with some manual deduplication.

            Let's be honest... it's just nice to see them executing on some of our requests, and seeing some progress! And I'd like them to remain encouraged. After all, it's a growing trend for companies to simply ignore their customers entirely.

            William Wilson added a comment - 15b3b63090ad - Very true. Especially in the case of duplicate entries and cleanup.    That said, I'll take small wins. FOR NOW . If I have the option to move a single Jira [Service Management] Project to another instance / site, I'm far happier cleaning up "Copy of" items, than having to duplicate my other efforts by hand. Situationally dependant of course. So, my thought is that it might be a good stop-gap for some of us. Again.... situationally, depending on the complexity of the changes. We have some that are just easier done by hand, and others that are very complex, and make me value the ability to get it done, with some manual deduplication. Let's be honest... it's just nice to see them executing on some of our requests, and seeing some progress! And I'd like them to remain encouraged. After all, it's a growing trend for companies to simply ignore their customers entirely.

            Hey fdfebb1bd187,

            I think you're confusing two things here. This functionality has been around for a longer time, but has now been moved elsewhere and expanded to include Jira Service Management. But this is a migration from one instance to another instance. In such a case, for example, all custom fields are migrated as double if they exist in the target instance, same with any existing configuration with the same name

            In the case of push from a sandbox to production, this is not acceptable. 

            What you mentioned, specifically with JSM, was published this month in this feature request: JRACLOUD-72570 Ability to move a single Jira Service Management Project to another instance / site - Create and track feature requests for Atlassian products.

             

            We are still waiting for this specific feature release as we want the configuration of the sandbox to be migrated, without needing to clean up so many "(migrated)" configurations, but just update the production by the changes

            Lukas Ortner added a comment - Hey fdfebb1bd187 , I think you're confusing two things here. This functionality has been around for a longer time, but has now been moved elsewhere and expanded to include Jira Service Management. But this is a migration from one instance to another instance. In such a case, for example, all custom fields are migrated as double if they exist in the target instance, same with any existing configuration with the same name In the case of push from a sandbox to production, this is not acceptable.  What you mentioned, specifically with JSM, was published this month in this feature request: JRACLOUD-72570 Ability to move a single Jira Service Management Project to another instance / site - Create and track feature requests for Atlassian products.   We are still waiting for this specific feature release as we want the configuration of the sandbox to be migrated, without needing to clean up so many "(migrated)" configurations, but just update the production by the changes

            db7b347c6ab8 - Not sure if you've gotten the updates delivered to you yet. But, we have a feature release!

            Atlassian Admin -> Data Management -> Copy Production Data
             
            "Adding or reorganizing teams? Copy Jira projects or Confluence spaces, users, groups, and configurations from one instance of your product to another.
            Learn more about what we copy"
             
            Likely due to some conversations I'd had with teams at Atlassian, we were able to trial this for the last couple months, and it just got pushed to our prod instance yesterday so you may not have seen it yet. It's very under-promoted. 
             
            I hope this is as helpful for you as it is for us! Let us know how it's working for you! (and/or if you have it as a feature yet!)

            William Wilson added a comment - db7b347c6ab8 - Not sure if you've gotten the updates delivered to you yet. But, we have a feature release! Atlassian Admin -> Data Management -> Copy Production Data   "Adding or reorganizing teams? Copy Jira projects or Confluence spaces, users, groups, and configurations from one instance of your product to another. Learn more about what we copy "   Likely due to some conversations I'd had with teams at Atlassian, we were able to trial this for the last couple months, and it just got pushed to our prod instance yesterday so you may not have seen it yet. It's very under-promoted.    I hope this is as helpful for you as it is for us! Let us know how it's working for you! (and/or if you have it as a feature yet!)

            AJ McBride added a comment -

            Couldn't agree more with fdfebb1bd187 !!!

            Our org is investigating how to manage so many Admins (an issue we are currently trying to reel in) but while solution some of our issues, a sandbox quickly became a solution everyone could get behind to solve some of our most persistent issues.

            Having said that, picking and choosing, and having a list of what will change when those adjustments are pushed to production with projects that could potentially be affect would be huge benefit. Date is not our concern but configurations, specifically automation, since so many similar situations can be solved with workflows and automations together or either, or.

            Thank you for your quick attention to solving this, as to many commenter's points, this can solve more workflows than just pushing data to production

            AJ McBride added a comment - Couldn't agree more with fdfebb1bd187 !!! – Our org is investigating how to manage so many Admins (an issue we are currently trying to reel in) but while solution some of our issues, a sandbox quickly became a solution everyone could get behind to solve some of our most persistent issues. Having said that, picking and choosing, and having a list of what will change when those adjustments are pushed to production with projects that could potentially be affect would be huge benefit. Date is not our concern but configurations, specifically automation, since so many similar situations can be solved with workflows and automations together or either, or. – Thank you for your quick attention to solving this, as to many commenter's points, this can solve more workflows than just pushing data to production

            I'll add the same concern as others have. 

            It's not just the data we want to be able to move. It's also the config. For example: We'd like to be able to make workflow changes in the sandbox and push them to prod. Or to add fields in the sandbox, and then push to prod. 

            Most of us don't generate data in the sandbox. Most of us are looking at the sandbox as a safe development environment, which we can then use to make changes and push those changes into prod. 

            (as a side objective: This would also potentially solve the problem with workflows, where you can't perform certain modifications on an active workflow, so you have to clone it, rename it and then make the clone the active workflow, and migrate all the issues in that project to the new workflow. Potentially, of course.)

            Thank you for looking at this, and for letting us know that this is in your development queue! This is exactly the kind of communication we love!

            William Wilson added a comment - I'll add the same concern as others have.  It's not just the data we want to be able to move. It's also the config. For example: We'd like to be able to make workflow changes in the sandbox and push them to prod. Or to add fields in the sandbox, and then push to prod.  Most of us don't generate data in the sandbox. Most of us are looking at the sandbox as a safe development environment, which we can then use to make changes and push those changes into prod.  (as a side objective: This would also potentially solve the problem with workflows, where you can't perform certain modifications on an active workflow, so you have to clone it, rename it and then make the clone the active workflow, and migrate all the issues in that project to the new workflow. Potentially, of course.) Thank you for looking at this, and for letting us know that this is in your development queue! This is exactly the kind of communication we love!

            Belto added a comment -

            Belto added a comment - https://getsupport.atlassian.com/browse/PCS-260965

              6dd2ec62243b Adithya Ramesh
              rdey@atlassian.com Ratnarup (Inactive)
              Votes:
              755 Vote for this issue
              Watchers:
              482 Start watching this issue

                Created:
                Updated: