5 min read

Atlassian Cloud Migration Webinar Q&A

By Praecipio Consulting on Jul 22, 2022 1:15:00 PM

No cloud migration is created equally, and because there are several factors to consider when planning your migration, it can all feel overwhelming. As an Atlassian Specialized Partner in Cloud, our goal is to help guide you through the messiness of migrations and develop a path that fits your specific business needs and leads you to a successful Atlassian Cloud Migration.

Our team of migration experts recently hosted a Q&A-style webinar about the most common issues they see with cloud migrations and provided their insights about moving to Atlassian Cloud. Below is a list of all the questions that were asked and the answers that our team gave.

 

Q: What is the easiest way to determine if all the add-ons are still in use in the system prior to the cloud migration/test?

A: Have Praecipio Consulting run a database query.

 

Q: How do I migrate from Server to Cloud? What are the options?
A: Outside of a custom solution, there are 3 potential methods of migrating server data to cloud.

  1. Leverage the Jira and Confluence cloud migration tools developed by Atlassian.
  2. Run a full site export/import.
  3. Use an add-on like Configuration Manager for Jira from Appfire.

Of these options, Atlassian only supports 1 and 2, and 2 will be deprecated as a supported method in the near future. None of these methods are perfect, there are pros and cons to consider for each, and potentially have additional objects and elements that would have to be solutioned for.

 

Q: Do you see any challenges with having a hybrid environment with, for example, a Cloud Confluence linked to an on-prem Jira?

A: The main challenge to a hybrid approach is going to be related to security. In order for the applications to communicate rules and allowances will need to be put in place between the cloud site and the internal network. If the current scenario is that both Jira and Confluence are on-prem, and Confluence is migrated to Cloud, there are some additional challenges to consider with existing issue links between the two that would have to be overcome depending on the migration method.

 

Q: How to deal with SSO for our partners whom also have different IdP at their end on Jira Cloud configured with Atlassian Access SSO.

A: When talking about Atlassian Access, the main consideration you have to take into account is that in the server setting, all user accounts belong to the individual application, but in cloud, all accounts are Atlassian accounts and exist independently from the cloud sites. This allows a user to have permissions on multiple sites but potentially be governed by a different organization. If you have partners that you wish to grant access into your cloud site, and they have their own SSO policy in place, you can freely grant them access without any impact to your current user base.  As an example, for our customers we frequently leverage our @praecipio.com accounts, which we have managed by our own IdP.

 

Q: 1. Do you have any automated way to clean up an on-prem instance of Jira before migrating to cloud, things like filters and boards that belong to legacy projects that no longer exist?

2. Can the ability to have team-managed projects be disabled to ensure teams do not create a mess and stick to enterprise standards?

A: 1. We have developed several scripts and queries over time that can be used to help identify orphaned boards and filters, but this process is seldom completely automated and often requires additional input and context.

2. Yes, in cloud there is a global permission associated with who can create team-managed projects.

 

Q: When it comes to merging of Jira Server projects into an existing Cloud instance (where the projects are replacing previous existing projects), is there a preference of whether going on-prem to cloud or go to a cloud instance and then go cloud to cloud?  Or is that hop unnecessary? Do you have a preference as to whether to use Appfire's cloud migration tool or Atlassian's native migration tool?

A: Going from server to cloud and then cloud to cloud is more than likely going to be an unnecessary hop, but this depends largely on the migration method and the context surrounding the environments involved. We tend to leverage Atlassian's cloud migration tools when possible to gain the benefit of having support from Atlassian, but there are scenarios where Appfire's Configuration Manager for Jira needs to be leveraged, especially if there's a more complex instance merge happening.

 

Q: When migrating Jira from on-prem to cloud, is there a way to migrate a project without its data (i.e. keep issue types, dashboards, etc BUT not the issue tickets)?

A: This functionality does not exist natively within the migration toolset developed by Atlassian, but it is certainly a scenario that could be accomplished. There are several factors that would have to be considered such as preference of data archival.

 

Q: Do I need to have Atlassian Access to use the claim domain?

A: Yes, Atlassian Access is required to claim domains and set up authentication policies, including the use of SSO.

 

Whether you're looking for a speedy, low-cost migration or have complex enterprise requirements, we have a path for you. While the journey to Atlassian Cloud comes with its fair share of challenges, our experts are equipped with a deep understanding of migration intricacies and have helped hundreds of enterprise organizations successfully move to cloud. With our team as your guide, start planning your migration with confidence. Watch the full webinar on-demand!

Topics: webinars cloud configuration atlassian-cloud cloud migration
3 min read

Jira Workflow Tip: Global Transitions

By Morgan Folsom on Apr 5, 2021 11:47:00 AM

Blogpost-display-image_Jira Workflow Tip- Global TransitionsBuilding Jira workflows can be overwhelming. As Atlassian Platinum Solution Partners for over a decade, we at Praecipio Consulting have spent a lot of time building workflows (seriously, A LOT). 

One piece of workflow functionality that we often see either ignored or abused are global transitions. A global transition in Jira is a transition to a workflow status that is able to be triggered regardless of where the issue is in the workflow. These can be very powerful, and we use them in some capacity in almost all of our workflows. However, there are a few things that we put into place to make these transitions easier to use. 

When do I use a global transition?

While these are not appropriate in all situations, we recommend using them in situations where users should be able to move to the status from anywhere else in the workflow. The most common use cases are "On Hold" or "Withdrawn" transitions, where users should be able to place the issue there regardless of where it is in the life cycle. It is understandable that users shy away from global transitions, as without specific configuration they have the potential to be confusing to end users and open up the workflow in ways we may not want. Keep in mind that global transitions should not be overused - using direct transitions allows for processes to be enforced, while global transitions are great options when you need to remove an issue from its normal flow.

With that in mind, we recommend the following configuration on all global transitions:

How to configure a global transition

Transition Properties

Opsbar-sequence is a transition property that allows you to determine the order of all transitions in your workflow. To use it, you assign numbers to each transition, and Jira will numerically order them on the issue view. 

Global transitions generally belong at the end of the list, so we usually give them a high number (100 or  500) so no matter how robust your workflow gets, they're always at the end of the list of available transitions. 

Conditions

Workflow conditions prevent transitions from showing when certain criteria are not met. As a best practice, we always add a condition so the transition is not available from the status it's going to – e.g. if we have a "Withdraw" global transition that goes to Closed, the condition should be "Status != Closed". If this condition isn't present you'll see the global transition available when you're in the status it's going to. 

Post Functions

One of the biggest issues that we see with global transitions is around resolution. Jira resolutions are an extremely valuable tool, and if you don't configure your global transitions correctly, they can affect your data integrity. So, 

If the global transition is moving into a "Done" status (e.g. Closed or Withdrawn), add

  1. A post function that automatically sets the Resolution, OR
  2. A transition screen with resolution that prompts users to enter a resolution before the transition

If the global transition is NOT moving into a "Done" status, add

  1. A post function that clears resolution

With the above configuration, your workflows will be more user friendly while also ensuring that your Jira data stays clean. 

Still need more help with your workflows? Praecipio Consulting is an Atlassian Training Partner with a robust catalog of training, including Workflow help!

Topics: jira tips training workflows configuration atlassian-solution-partner
3 min read

Three Things No One Tells You About Custom Fields in Jira

By Mary Roper on Mar 4, 2021 12:19:10 PM

Blogpost-display-image_Three Things No One Tells You About Custom FieldsCustom fields can be an over-looked configuration point in Jira, and it's easy to see why: they're easy to create, modify, and make available for your users. Although Jira ships with several system fields, it's inevitable that teams using Jira will reach a point where they require additional fields to input specific information into their issues. But in order to maintain Jira's performance as well as instance hygiene, it's important that Administrators take great care when it comes to custom field creation. That's why today we're sharing with you a few custom field insights we've gleaned over the years. Read on to learn three things no one tells you about custom fields. 

1. Technically, there is no limit to the number of custom fields you can have. BUT...

Custom fields do impact system performance in Jira. Below are some recent results breaking down each configuration item's impact on Jira. Here, we can see that custom fields have an impact on the speed of running a large instance. Your teams may feel this impact in the load time of issue screens. As an admin, one indication can be having a long page of custom fields to scroll through. Additionally, this is often accompanied by longer than usual load time for the custom field Administration page. 

Response Times for Jira Data Sets

To combat this, Jira Administrators should partner with the requestor and other impacted users to determine some guidelines for creating custom fields. For instance, requiring the requestor to submit an example of how they plan to report on the custom field or having the Administrator ensure the custom field can be used in the majority of projects (>=80%). Execution is crucial here: once the guidelines are aligned with management and stakeholders, it's crucial they are followed to prevent your custom field list from unnecessarily growing.

2. There are native alternatives to custom fields.

There are a few usual suspects to look for when reviewing custom fields. Duplicate custom fields ("Additional Comments" as a supplement to the "Comments" system field), variations of custom fields ("Vendor" vs "Vendors"), and department specific custom fields ("Company ABC" vs "Vendor") are a few custom fields that can needlessly drive up your custom field count. To prevent this from happening, Admins can offer their business partners alternative suggestions to creating a custom field by looking at the following:

  1. Utilize an existing custom field that may be more general, but is fit for the purpose to get the most out of what is already in place.
  2. Rather than implementing a custom field, Labels or Components can be used to help organize issues and categorize them for future reporting.
  3. Apply a custom field context to help maximize the potential for picker, select, checkbox, and radio button custom field types. Adding field context enables Administrators to pair different custom field select options or their default values to specific projects or issue types within the same project.

3. You can proactively manage custom fields.

Rather than waiting for custom fields to pile on and create a lag on the instance speed time, proactively scheduling time to scrub your instance for stale custom fields will help Administrators keep on top of their custom field list. This can be a visual check to understand what fields aren't associated to a screen- those are good candidates for removal- or if there are similarly named fields- those can be good candidates for consolidation. More information from Atlassian on how to identify and clean up these fields can be found here.

Ultimately, a well-maintained Jira instance includes a good understanding of custom fields and their overall impact on the system. As your instance grows overtime, the guidelines around custom field development will become all the more important. Bringing these tips to life will help your instance run at top speeds for your users. 

Need help making the best out of your Jira instance? Our experts know Jira inside-out: contact us and we'll get in touch!

Topics: jira blog best-practices optimization standardize configuration bespoke health-check
4 min read

How to Handle Delete Permissions in Jira

By Courtney Pool on Feb 16, 2021 11:47:00 AM

Blogpost-display-image_Why you should restrict who can delete issues in Jira

Permissions are one of the most important things to “get right” in Jira. Sure, having the right fields, screens, and workflows are all vital pieces of the puzzle as well, but they can easily be tweaked along the way. While permissions can also be updated as needed, a user who can’t see or edit the issues they need may have their work completely blocked in the meantime.

And then there is the group of permissions so important, so crucial, so absolutely imperative to get right that they earned a blog dedicated solely to them: the delete permissions.

“Well, of course,” you may be thinking, “everybody knows that.” But even if it may seem like common sense to you, it can easily slip through the cracks — it’s happened to others before, and let me tell you, it doesn’t always end well.

You see, delete permissions are so incredibly critical for one reason:

There is no recycling bin in out-of-the-box Jira.

This means that if something is deleted, whether through intent, accident, or malice, it’s gone. Poof. And while the loss of one item may be easy to recover from, the loss of tens, hundreds, or even thousands? Even I can feel the sweat dripping down your spine now.

So, to summarize: Delete permissions? Very important.

TYPES OF DELETE PERMISSIONS

To begin, it’s important to understand the delete permissions structure. Within Jira, there are four groups of delete permissions: 

  • Delete Worklogs
  • Delete Comments
  • Delete Attachments
  • Delete Issues


And then within those permissions, there are two types:

  • Delete Own
  • Delete All

DELETE OWN PERMISSIONS

The Delete Own permissions, as the name implies, will allow a user to delete content tied to their specific user account. These permission types exist for most of the above-mentioned groups, with the exception of Issues.

Delete Own Worklogs applies to any time that's been tracked to an issue, whether through Jira's native feature or through an app like Tempo Timesheets. As such, it is an innocuous permission and can be assigned to any users with access to a project, unless you have strict requirements otherwise. It will likely primarily be used for clean-up, and the ripples it can cause are limited.

Delete Own Comments is also often used for clean-up, and again, its area of effect is a bit smaller. However, just because a comment is deleted doesn’t mean that people haven’t already seen it, or even acted upon it. It may be better to instead point users in the direction of comment editing, or have them enter new comments entirely, even if it’s just to say, “Disregard the last.”

Delete Own Attachments is another permission that can be used for tidying. This feature might be useful were someone to, say, accidentally upload an adorable picture of their dog rather than a spreadsheet for the project. It’s fairly low impact as well and can likely be given out to any users within your project, especially if you’re following the Backup Rule of 3 or similar internally.

DELETE ALL PERMISSIONS

Each of the Delete Own permissions has a Delete All counterpart. Delete Issues exists here as well, though the naming convention differs from the other four. Delete All permissions give a user access to delete items associated with any user account. As such, we generally recommend these permissions are limited to only certain groups, such as Project or System Admins.

Delete All WorklogsDelete All Comments, and Delete All Attachments can each only be performed in a single issue at a time. This barrier helps to protect against mass deletion, but in the interest of data integrity, you’ll still want to restrict who is allowed to perform these actions.

And as for Delete Issues? This will also give a user the ability to delete from within a single issue, but unlike the three mentioned above, this permission gives a user access to Bulk Change as well, which allows actions to be taken across multiple issues at once. As such, ask yourself if you even need to grant this permission at all. Sure, there could feasibly be a time when you need to mass delete issues, but it’s likely to occur so rarely that, should those stars align, the permission can be assigned when needed to system admins and then removed as soon as the job is done. This extra step will save you from being the organization that just lost a years’ worth of tickets. 

Remember: when something is deleted in Jira, it’s gone forever. This permanence can be a nightmare for many, especially those in organizations with heavy audit requirements. Rather than leaving yourself open to a very unpleasant surprise, do your team a favor and review your permissions now.

Stop worrying about Jira and make full use of its powerful features!  Explore more ways we can help your team succeed with our Consulting Services, or contact us with a question or request and one of our experts will be in touch shortly.

Topics: jira atlassian blog best-practices tips configuration

Praecipio Consulting is an Atlassian Platinum Partner

This means that we have the most experience working with Atlassian tools and have insight into new products, features, and beta testing. Through our profound knowledge of Atlassian environments and their intricacies, we can guide your organization as you navigate these important changes.

Atlassian-Platinum-Solution-Partner

In need of professional assistance?

WE'VE GOT YOUR BACK

Contact Us