Migrating to Jira cloud

[Johnny Gotham]

Hi,
My company is finally migrating from our data center to Jira Cloud. Our manager wants all teams' Jira Projects to live in one project when in Jira Cloud. He wants teams under projects to be able to run their sprints. Is this possible? 

I appreciate any help you can provide.

[Trudy Claspill · Accepted solution]

Hello @Johnny Gotham 

Welcome to the Atlassian community.

I'm not sure that I understand your question.

Jira Projects in Data Center equate to Jira Project in a Jira Cloud instance. Are you saying your manager wants all the issues in various Jira DC Projects to be merged into a single Jira Project when you migrate to Jira Cloud?

As for sprint management, if the users can run the sprints in their boards in Jira DC Projects, then they would be able to run the sprints under the same boards in the same projects when they are migrated to Jira Cloud, as long as you grant the users access to the Jira Cloud instance.

Side note: If your company is feeling trepidatious or overwhelmed about the migration process and impacts, you might want to engage an Atlassian Solution Partner with a Cloud Migration specialization to help you. You can find partners that support your region in the Atlassian Partner Directory. I work for Praecipio, which is an Atlassian Platinum Solution Partner with a Cloud Specialization. If we support your geographic region, we would be happy to discuss the services we can offer you to support your migration effort.

[Johnny Gotham]

Hi Trudy, thank you for your answer. 
Yes to "Are you saying your manager wants all the issues in various Jira DC Projects to be merged into a single Jira Project when you migrate to Jira Cloud?"

It sounded a bit off to me, too, when I was told. I've been working in Jira for over a decade, and I'm reasonably sure that you can't have teams under projects that can also run their sprints independently of the project. 

Thank you for the offer to engage with Praecipio. If you could help guide me on what a good hierarchy should be when transitioning from Jira DC to Jira Cloud, I can take that to some folks and suggest we work with you.

[Trudy Claspill]

Hello @Johnny Gotham 

First, addressing your question in response to @Melanie Dixon about "company managed" vs. "team managed".

In Jira Cloud there are two types of project customization architectures. Projects that are set up as "company managed" use the same sort of customization architecture you that exists in Jira Server/Data Center, meaning that the projects use Schemes and Global settings to determine their configuration; Workflows and Workflow Schemes, Issue Types and Issue Type Schemes, etc.

The "team managed" customization architecture is only available in Cloud. It is an architecture that allows customizations at the project level that can be managed by the Project Administrator. They can customize the available Statuses, Workflows, Issue Types, create Custom fields, and so on. These things are project specific and will not appear in the global configuration options for Workflows, Issue Types, and Custom Fields.

When you migrate from DC to Cloud all the projects that migrate will retain their customization architecture, which means they will be "company managed" projects where it still takes a Jira Admin to make changes to schemes.

Now as to the merging of multiple projects into one project, the Jira Cloud Migration Assistant application provided by Atlassian to help with the migration cannot merge the projects. The merge has to happen before the migration or after the migration, and that merge would not be a simple process. The issues in the various projects would have to be Moved to a single project. That could involve a lot of work to map workflows and issue types and so on, if they don't all already share a single set of configuration Schemes.

On the topic of teams managing their own sprints - sprints are associated to a Board. A Board is built on a Saved Filter that might reference a single project, multiple projects or any subset or super-set of issues from 1..n projects. 

If all the issues are merged into a single Jira Project, each team can have a filter that selects the issues in that project that are owned by their team. (That presumes that a method for identifying the owning team for each issue has been decided upon.) Each team can create a Board based on their filter. Each team can create sprints in their board. However...

Jira does not restrict a user from adding an issue to a sprint that was created in another board. So, if the team is not already well versed in managing the addition of issues to sprints, they could run into some problems. Technically that could happen even if they have their issues in separate projects.

And the ability to manage sprints and move issues in and out of sprints is based on Project Permissions for all the Projects that are within the scope of the board filter. So, while they can have separate boards and create their own sprints, they would all have to have the same permissions in the underlying project to manage those sprints.

But I would recommend backing up a step and really digging in to what problem the manager is trying to solve with their suggestion that all issues from various projects should be merged into a single project. That suggestion of a "merge" is a solution. It doesn't tell us about the problem. And without knowing the problem, we can't determine if the suggested solution is a good idea. I like to use the Five Whys to try to get to the real root problem to make sure the best solution is determined.

On your final question about "what a good hierarchy should be when transitioning from Jira DC to Jira Cloud", what are you seeking when you say "hierarchy"? Are you talking about the set up of Jira? While Jira Cloud has a lot of commonality with Jira DC, there is also a lot of new and different functionality. What would benefit your company the most depends on your company's needs, goals, and challenge areas.

Assessing that, discussing what it takes to migrate to cloud, developing a plan for the migration, and executing the migration are all areas where Praecipio can assist you. We can serve in capacities from purely advisory to architecting the solutions to executing the solutions. That is something your company would discuss with the Praecipio team during your early conversations.

I hope that helps.

[Trudy Claspill]

p.s. Feel free to mention my name if your company does contact Praecipio. I am not usually part of the "first contact" team, but I am a Sr. Architect that works in the architecting and delivery of solutions.

[Melanie Dixon · Accepted solution]

The answer depends on the type of project that was set up.  Will this be a Company Managed or Team Managed?  My guess is that it would be company managed and it that case the answer is 'yes.  Each team can have their own Board and their own sprint schedule.

[Johnny Gotham]

Hi Melanie, thank you for your answer. I'm reasonably sure that the project will be team-managed rather than company-managed. I'm basing this on descriptors; I have no idea what the difference is. I assume 'company-managed' means something along the lines of a single project for the entire company. Each department and team has its own projects, which are managed using Scrum and/or Kanban boards. I'm nearly getting access to the sandbox cloud instance where I can test my theory. Essentially, I don't believe what the manager wants is possible. This involves having all the manager's teams under one project, so they can easily see what all the teams are doing and produce metrics at a department level instead of a team level.