This article was written by Kamil Beer, an Atlassian Engineer at iDalko.
As Atlassian offers a variety of options for different business scales and supports various scenarios and add-ons, maintaining the Atlassian Stack can become a kind of challenge along the way. As an admin, you probably asked yourself questions like how to deploy Jira, what rules to set up, and how to guarantee security. The biggest question here, though, is how to maintain your Atlassian Stack.
Luckily, the paths have been trodden by many experts, including those at iDalko. So in this blog post, we’ll walk you through the right steps to maintaining your Atlassian Stack with the least fuss possible, all based on our experience.
Here’s what is going to be covered in this blog post:
Deployment Models for Your Atlassian Stack
Before we get to the Atlassian Stack governance and cleanup, let’s start by going over the options you have to avoid possible risks when choosing the deployment model for your Atlassian Stack.
So first things first, where should the application run?
On Cloud, Data Center, or Server?
In this part, we’ll go through the deployment choices. It’s useful to both novice and veteran administrators especially if you’re thinking about migrating your Jira.
Cloud
Simply put: Cloud means Atlassian hosts the application.
With Cloud, you don’t need to provide the application infrastructure or perform any complicated server administration tasks. But there are other things to consider.
There are four types of Cloud deployments:
- Cloud Free
Allowing you to use Jira Software, Core, Service Desk, Confluence, Trello, Bitbucket, and Opsgenie for free. It’s a good introduction, but the limitations don’t make it very production-viable (e. g. Jira lacks permissions, Bitbucket is limited to 5 users). - Cloud Standard
The most common Cloud solution. - Cloud Premium
A more powerful Cloud Standard. It has a 99.9% uptime SLA, unlimited file storage, and 24/7 support. New features include IP Allowlisting and Project Archiving. For small teams, users cost twice as much (e. g. a user in JSW costs $7 for Cloud Standard and $14 for Cloud Premium). But the more users you have, the lower will be the price increase. - Cloud Enterprise
Going even further, with unlimited users, a 99.95% uptime SLA, the ability to choose Data Residency and “guaranteed integration with many essential enterprise SaaS tools”. It’s certain to be a dream come true for many teams, but also at a cost that won’t make it accessible to most of them. Try it out here.
Now that we covered the Cloud types, let’s see what Cloud Standard has to offer.
Data Center
Simply put: Data Center means you host the application, utilizing the power of several servers.
Data Center deployment was first made available for Jira 6.4 in 2014 and then for version 7.0 in 2015, when Jira was split into Jira Core, Jira Software, and Jira Service Desk.
But what exactly does the Data Center deployment bring?
First, it runs the application on several servers, so it provides better performance and can sustain a heavier load than a Server instance.
Second, it provides a backup solution. For instance, Server A might be down, but your application will still run from servers B and C. Neat and useful when you need high uptime, for instance, for documentation or a support service desk.
Server
Simply put: Server means you host the application.
Important note: Atlassian announced the end of Server era as of February 2, 2021, so that is the end of new server license sales and you can no longer purchase or request a quote for a new server product. There will also be an update on new prices for server renewals and upgrades and the customers have the option to renew their maintenance until February 2, 2024
So, what do you need when deploying locally? Certainly, your own/ a hosting provider’s server to run the application (Linux, Windows Server, AWS, or Azure are all options), a database, a file system, and an administrator that can put it all together. In the beginning, the help of some other IT technicians might also be necessary.
Server is for sure a more user-friendly option in comparison to Cloud as you can perform various tweaks and custom integrations. But in case your instance is crashing down, Atlassian can’t help remotely like they can on Cloud, as it is done via the helpdesk only.
Another hurdle might concern licensing, with big differences between user counts (if you have 501 users, you need to buy the 2000 user license) – including apps.
Read all about the latest price updates here.
Deployment Limitations
Now that you know the main properties of the three deployments, there is another point to consider: some applications can be deployed only in Cloud, some only on the Server version, and only a few can be deployed in Data Center. Thankfully, there is a large overlap – see below.
Summary
Cloud, Data Center, and Server are the deployment options an Atlassian administrator should know about. But maybe you already chose your hosting, but it doesn’t work as well as initially planned. Or you might be on Server and are planning to migrate to DC or Cloud in the coming years. If you haven’t yet decided to migrate or not, you can read about what you need to do before, during, and after your migration in this complete migration guide.
Whatever your case is, maintaining your Atlassian Stack is something you need to do along the way. In the next parts, we’ll cover everything from governing your Atlassian Stack to doing a neat and regular cleanup.
Atlassian Stack Governance
Regardless of your Atlassian Stack deployment model, you need to set quality administration standards right from the start and avoid a lot of head-scratching later before your users start working. That includes documenting everything, maintaining a great admin team, and saving users the hassle.
What exactly makes good Atlassian Stack governance? Let’s first define what it isn’t: everyone is an admin, users are lost and untrained, nothing is documented, settings are all over the place, nobody sets any standards. There’s more but you probably already have the picture of such a work environment.
So here’s how you can avoid these troubles.
Documentation
Documenting is the first step. Sure, it takes time but saves it (along with money and headaches) later. Have you heard about the Bus Factor?
The Bus Factor is a term used when only one employee holds all the knowledge about a certain system or an application. One day, a bus hits him and the company is then done. All the important information was in his head. Documentation counters the Bus Factor. Even if your key admin is perhaps sick, his deputy can follow up on his work.
Still not convinced? Consider this: Your key sysadmin steps down. Maybe you didn’t part on good terms, so when he meets his successor, the said sysadmin starts the meeting with “Fine, ask.” Yikes.
So, what are some good things to document?
Jira Project Documentation
If users have been working in Jira for some time, they have likely created many projects. To keep admins informed, it’s good to track which projects do what. Otherwise, Jira might easily get cluttered by thousands of old issues, which worsens the user experience.
You can start documenting projects even if you haven’t done so before. However, make sure you have a clear project creation/ change process in place first for the documentation to be effective. You can record these details:
Users should tell you these when requesting a new project so that the assignee can easily add it to the documentation.
Project Settings Documentation
Sometimes, projects use large workflows, scripts, complex permissions, or integrations. And at some point, it’s best to write everything down, else new admins and users would get confused and lost in the project all the time.
Create a new page per project, right under the project’s overview. Here, write down the project settings – issue types, screens, permissions, notifications, etc. Write scripts in the “Expand” macro, so they don’t take too much space. Document important links, roles, groups, boards, and integrations, too.
Complex workflows require the most attention. Many users work with them and new hires need to know how their projects work. The same goes for admins that see the project for the first time. Create an extra page for each workflow and write it down.
This is an example of how a sample project documentation might look.
App Documentation
You can install a lot of apps on Jira and Confluence. But the more apps you have, and the more they are left unchecked, the performance, costs, and user-friendliness of the application worsens. We’ll write about evaluating app usage and removing the unused ones in the next part. Right now, documenting the current state is a good first step to decide better later.
Again, a simple table in Confluence will do.
If you are considering an application upgrade, adding a compatibility field is also useful, e. g. – “Compatible with Jira 8.6.1”
Moving on
You documented the projects and the apps. Good! You can also write down how custom integrations work, or record groups, so you know which are used for what and which can be safely removed. Maybe you could also add a whole “Scriptrunner” section covering all scripts used in the application.
Having the documentation in place helps not only with keeping users informed but also as a foundation for future application cleanups. We will cover how to do them in one of the next parts.
Documentation is the most effective when you revise it at least twice a year, but it’s best when it’s updated after every change, so it isn’t dated. Tell your admins when a new object (a group, an app, a project…) is created that they should document it to save time later. And how to choose the right admin team? Read on.
Staff
A lot of admins usually maintain the toolset. It makes sense: Innovators that need its help start the application „under the table“ first. It succeeds, slowly gets adopted by others, then perhaps by the whole company.
New administrators are elected. Anyone can get admin rights to quickly set up what he requires. Suddenly, you have a large application with tens of admins. Nobody uses best practices and you can easily break everything. What to do?
Administrators
Reducing the number of admins to two or three is how you take back control over the application. While it seems easy, it’s probable there will be pushback from users losing their admin rights. They might be afraid their requests won’t get implemented (maybe from a bad experience), or that the company doesn’t trust them anymore.
First, clearly explain the necessity of this step: that it will bring benefits from security, governance, and performance standpoints. Namely:
- It lowers the chance of a malfunction. (e. g. they won’t be able to start a full reindex and lock the instance.)
- It reduces the probability of an admin account getting compromised. (e. g. via a stolen password)
- The application stability and reliability are guaranteed by a dedicated admin team. (e. g. all changes will go through a helpdesk)
You might get the old „I won’t break it / I know what I’m doing / I configured it with Mike and Scott!“ Sure, but can you vouch for all the others? No. So the same rules need to apply to everyone.
Second, tell everyone clearly how to create a ticket. Users get frustrated fast if they don’t know where to ask for help or when they should provide data they don’t even know where to get. Or when nobody responds in weeks…
You can explain the request creation in a global email. Ask managers to tell their teams. Write a guide on how to enter a ticket and put it in announcement banners.
Scriptrunner can create a „Request support“ button in the navigation bar with a Script Fragment. It can link to either a new issue screen or a Jira Service Management portal and everyone will see it.
Third, exceed the users‘ expectations. Of course, this doesn’t mean you should do everything that’s asked. But you can provide a good response time and enough attention to the tickets.
Meetings and vacations often get in the way of a quick response. That’s why you have multiple admins: one always prioritizes tickets. And attention means that you will find time to talk to the requestor if he wants something unclear or complex, like a project import or a migration.
Quick responses and attention will soon make users’ bad past experiences go away and make the Atlassian team and tools appreciated and important.
Advisors
A smaller admin team means better control and stability, but dedicated Atlassian administrators often lack the knowledge, approach, and skillset of different vocations. And so, the point of view of a regular user, a scrum master, a business person, and others are invaluable in setting up the application correctly.
Let’s say you want to standardize workflow status names, but your users have already learned the existing ones and this would confuse them. Or you’re creating a roadmap of the next direction of your Atlassian tools, but the company has a pressing need for a feature that you can help with. Or, you’re considering Cloud migration, but users will have to relearn the whole UI (and not once)!
It helps to have a contact (or an advisor) in each of the big user groups. It’s not about them watching and chiming in on your tickets, however, but about having a buddy to discuss large-scale changes and projects with.
So, who are these people? Here are a few examples:
User Accessibility
Good governance for your Atlassian Stack also means that using the application is simple and if users have trouble, they can get help quickly. It’s about knowing where to go, having clear guides, and training users to work with the tool so they don’t feel overwhelmed.
User Requests Project
Let’s manage user requests better. First: stop using email. Yes, not only it’s clumsy, as you’ll get flooded by messages, they might branch, and it’s hard to find what you need, but emails are also bad for auditing. Because they often get accidentally deleted. What if you lose the whole mailbox, maybe because its owner left the company? All information regarding the requests will disappear.
A better solution is a ticketing system. And not necessarily the massive enterprise one used by the rest of the company, but a lightweight Jira project for Atlassian-related requests.
Set it up so anyone can create a ticket. If your Jira is visible only on the company intranet, you may even allow anonymous issue creation. Remember, however, that if the requestor doesn’t provide his name, you won’t know who created the ticket (e. g. when granting permissions).
The choice of issue types depends on the data you want to report on and the fields that users have to fill. While a simple “Task” type is often sufficient, “New User”, “New Project”, and “General Request” can provide more data and help users create the right ticket. In “New project”, you can require all the fields mentioned in the “Jira project documentation” part. For “New user”, the reporter can enter the applications said user should have access to – Jira, Confluence, Bitbucket, …
Users should already know the details they need to fill in the tickets and enter only a few fields. Sometimes “Summary” and “Description” are all they need. Remove “Assignee”, though – the ticket will be assigned by the Atlassian team.
Also, keep the workflow simple: “Open”, “In Progress”, “Waiting for requestor”, “Resolved”, and “Cancelled” is enough.
Issue Security Level is useful when dealing with sensitive data. If the default level allows only the Reporter, Administrators, and Service Desk Team to see the issue, requestors won’t see each other’s tickets. You can also add a custom user field “Participants” where you can add others that should see the request.
If you have Jira Service Management (formerly Jira Service Desk), then great! Create an internal customer portal and organize tickets by request type without a further configuration of the permission or issue type schemes. The ticket form will also be less intimidating than a regular “create issue” dialog.
User Guides
Users will ask similar questions. How to request an account? How to reset a password? How to create an agile board or simply raise a ticket?
Save time and create step-by-step guides answering frequently asked questions and requests. Users should be able to access these pages even without having to log in. The guides on how to create an account and how to request a ticket are universal. If a user that isn’t yet familiar with entering tickets sends you an email with a request, you can send him this guide to help him.
There might be other requests/ questions specific to your company. Watch what is requested the most often and create guides for those cases.
Training
One wouldn’t give an unqualified admin control over the application, but letting untrained users work in it is, sadly, common. Trainings are neglected because there’s apparently a lack of time and money. But isn’t it obvious how much money and time it will cost if people get lost or make mistakes because nobody taught them the tool?
If you agree, what types of seminars should you hold then? Start with a basic and an advanced course for Jira and the same ones for Confluence. One for the absolute beginners and the other for power users (that set up JSW boards, Confluence spaces, or JSM service desks).
Bitbucket and Bamboo are different in this regard – developers often don’t want these trainings, as they have used similar tools before.
It’s also a good idea to first ask the users what they would like to learn. With more replies, you’ll get an idea of how to tailor these trainings to be of the most use. You might also find out that they want very specific courses with marginal features and apps, like those for timesheeting, reporting, or resource management.
Length-wise, if users tell you to make the seminars “as short as possible”, remember there’s a reason why a college degree takes several years. Still, 8 hours might be discouraging or exhausting and a two-hour course might barely scratch the surface. A half-day session makes the most sense: attendants get enough time for questions and you get enough space to sufficiently address the topic.
How often should you hold the trainings? If there’s a high demand, or if you’re just starting with them (and the number of untrained people is high), two courses (basic and advanced) for each tool each month is enough. After the majority of users attend these seminars, you can hold them quarterly instead.
Let users play around with the tool during the training. Use a demo space, project, or even a whole instance. After you cover a particular feature, give them an exercise to try it out, whether it is creating an issue or a page from a template, add a macro and so on.
The examples don’t need to be complex; the important thing is that the users try the actual process they will then repeat (with some small variations) in their daily job.
Summary
Good governance is key to the application growth and a standard for its future usage. The sooner you establish it, the easier the work in the application becomes. You can expand on the concepts yourself: create a guide describing what you will and won’t implement to set the right expectations. Hold trainings specific to your use cases.
But what about the past? If you already have a messy application and would like to clean it up, no worries: that’s what the next part will be about.
Atlassian Stack Cleanup
Maybe you haven’t had the luck to arrive at a brand-new deployment where you could establish good governance right from the start. Or, you have to take care of an instance with hundreds of custom fields and statuses, along with ancient projects, spaces, apps, and users that nobody had reviewed for a long time.
Don’t worry, we will help you tidy up everything in this part.
You took the steps mentioned in the governance part. Projects and spaces are documented, the admin team has shrunk, and most requests go through a helpdesk. The future is bright, but what about the mess that’s been left? Let’s fix it.
So, what exactly is this cleanup? It’s a process that you perform once or twice a year, where you remove unused objects, users, and features to improve application performance. It can be done on all Atlassian tools – and it should if they have been implemented for a long time. On Data Center, a hardware/system health check should also be a part of the cleanup to ensure application stability.
In this part, you will learn how to properly remove what’s no longer needed.
User cleanup
Deactivating users helps with:
- Reducing costs: On monthly Cloud subscriptions, you pay for all active users even if they no longer use the application. On DC, they “just” take license space.
- Less confusion: Disabled users have “(Inactive)” in their names and cannot be picked as assignees or into fields.
- Improving security: Each deactivated user reduces the chance of unauthorized access to your data.
It’s easier if the applications are connected to a central user directory like AD or GSuite because users that leave the company are automatically deactivated by the register’s administrator. If you’re working with an internal directory, Crowd Data Center, or Atlassian Access instead, you need to disable the users yourself.
But sometimes, even if you’re connected to a central directory, some users are granted access but will never log in, while still using licenses. So how do you work around that?
First, check the last login date to determine if the account is being used at all. It’s clear that users that haven’t visited for a year aren’t exactly the tool’s habitués. Set the bar for disabling users to six or even three months to enforce stricter access rules. Don’t worry, you can reactivate a disabled account at any time. Find the last login date in the User Management section – it’s displayed on every user’s account:
Next, filter all active users, look at their login dates, and deactivate them. Or use a specialized app, like User Management by Toros for Cloud or the User Management series, available on Data Center.
These apps enable you to filter users by various criteria, like group memberships or last logins. Not only you can search for all users that haven’t logged in for some time, but also those that have never logged in, yet signed up a long time ago.
This group of deactivation candidates is particularly hard to find, because without knowing how old their account is, you may mistakenly disable new users that are yet to log in.
These apps also allow you to deactivate users in bulk in a similar fashion to a bulk issue change. And luckily, the apps’ trial period doesn’t limit any of their features.
Be careful, though: you don’t want to disable a user that’s never logged into Bitbucket, but actively works in Jira. The safest option is to check every user’s “Last seen on” information before you disable him.
App Cleanup
What will you gain in this step?
- Reduced costs (again!): If only a few users work with an app you’re paying for, is it necessary to keep it? What about two very similar ones?
- Simpler UI: Many apps add fields or buttons that might confuse the users. Make your teams’ job easier.
- Better performance: Remove unused resource-intensive apps to speed up the instance.
- You’ll get less app conflict.
You documented your apps in the previous part, now let’s check their usage. Each add-on is different, so there isn’t one single way to determine if you should remove it or not. Let’s divide them into several categories first.
- Workflow apps: This is a specific Jira app category expanding the list of workflow conditions, validators, and post functions. These add-ons are also often the victim of app redundancy, as they frequently get installed together despite identical functioning.
First, choose the only workflow app you’ll use in the future. Then, search where the other apps are used and replace them with adequate features from the primary app.
Instead of checking all workflows and transitions, use the free Power Admin app to list the usage of any of these add-ons. Choose „Configuration Manager“, App, and then the app to review.
In this picture, we see that JMWE is used in 5 projects. Click on it to see the specific occurrences.
There are 5 occurrences of JMWE features in „Copy of EK: Process Management Workflow“. Let’s inspect the transition and replace all functions from the retiring app with similar elements from the primary one. Repeat until there are no occurrences of the old app.
The app has so far been compatible only with Data Center, but given its popularity and the recent interest of Botron, the add-on’s developer, in having Configuration Manager (from the same family of apps) on Cloud, it’s safe to say that one day, Power Admin will get there, too.
Some workflow add-ons have other features, so check if they’re used before disabling the apps.
Examples: Jira Misc Workflow Extensions, JSU, Create on Transition, Jira Workflow Toolbox, etc.
- Standalone features: These apps add big functionalities that create new objects in the application, e. g. BigPicture and its „Programs“ or Insight and its „Object Schemas“. It’s easy to review their usage, as an administrator can see each of these new objects.
So first, determine how actual they are. If not (e. g. In a „Plan“ in Advanced Roadmaps, no issues have been scheduled for the last half-year), see who owns the object and ask him if you can delete it. It’s also useful to document these items for future reference.
There are exceptions, of course. for instance, the “Team Calendars” app. While it creates objects (Calendars), you can’t display a list of those that are in use. We will describe how to remove them next.
Example: Advanced Roadmaps, BigPicture, Structure
- Specific extension:. These are probably the hardest to remove. Their usage isn’t listed anywhere accessible and Power Admin doesn’t help either. The best option to find out if they’re used is to search the database (when on Data Center). When on Cloud, we recommend contacting the vendor of the app about the right way to determine the usage.
Example: Rich Filters for Jira Dashboards, Artezio Burndown Chart for Jira
- Admin tools: And these are the easiest – the admins know if they’re using these apps. Plus, you don’t need to worry that you’ll disable somebody else’s add-on.
Example: Optimizer for Jira, Power Admin, Admin Toolbox for Jira
- Macro apps: You can create all kinds of custom content with Confluence macros, some of which are added by apps. Read which are used in General Configuration -> Macro Usage (this section is available on Cloud or in Confluence DC version 5.10 and higher).
Example: Table Filters and Charts, draw.io Diagrams for Confluence
If you have apps installed that don’t fall under these categories (and thus it’s hard to measure their usage), ask the users who are most likely to be working with them.
Jira Cleanup
Project Archiving
New projects come and go, they are finished and abandoned but nobody tells the admins. Many unused issues stay in Jira, slow it down, take up disk space, and clutter search results. Let’s learn how to archive them.
You’ll find archival candidates by reviewing the projects’ last updated date. The app “Profields” will create a list of these dates, but you can easily find it even without the add-on. Create a filter with all issues from a particular project and add the field “Updated”. Sort the filter results by this date. The JQL query is “project = nameofproject ORDER BY updated DESC”.
If the “Updated” field on the issues on top shows a date that occurred more than a year ago, it’s probable you can archive the project. Contact its lead and confirm that you may. If his account is disabled, ask other users that worked on these issues about who to contact, if anyone.
And how to archive? For example, you can make the project invisible (with an admin-only permission scheme). However, the projects will still appear for you as admins and the issues will remain in searches. The attached schemes will also appear as used.
Another option is to use Jira’s native “Archive projects” feature. It’s handier as it hides archived projects from searches. However, it’s available only in Jira Cloud Premium.
Another option is Configuration Manager. This app allows you to export projects, their issues, and schemes and reimport them somewhere else. This way, you can move what you’re not working with anymore to a Jira instance you use for archiving. Don’t forget the attachments!
The third option is creating a backup. When you verify its integrity, ideally by restoring it on another instance, delete all archived projects from your production and store the backup somewhere safe. The downside of this approach is that you can’t add newly archived projects on a single instance (like you would with Configuration manager) and you need dedicated backup storage.
Clean up Unused Objects
Over time, Jira creates many objects that clutter the application, making it hard to administer and standardize. These are issue types and their schemes, statuses, workflows and their schemes, screens and their schemes, field configurations and their schemes, permissions, notifications, resolutions, priorities, links, custom fields, and issue security schemes. Custom fields are the most impactful, as they considerably slow down issue viewing, editing, and creating.
The goal here is to delete all unused objects and replace the less used ones with more popular ones. An app that helps tremendously with this is Optimizer for Jira, available on both Cloud and DC.
It helps you sum up the objects’ usage, but you can easily review them yourself. Here are a few pointers on how to do so.
Jira Templates
This next section is more about prevention so you save time later, and it’s going to be about Jira project templates. But why does NOT using them cause problems?
When you create a project, it comes with a new issue type scheme, workflows, a workflow scheme, screens, screen schemes, and an issue type screen scheme. Especially Service Desk projects come with many of these.
The thing is if you’ll change the new project’s settings anyway or replace its schemes with those you already have, the newly created objects will remain in the system.
Avoid this with the “Create with shared configuration” function. First, have a template project – it can be empty but needs to have the necessary configuration schemes. Then, if you want to create a project that works just like the template, use the shared configuration setting. The new project will use the same schemes and create zero unused objects.
This is the way to go if you’d like to standardize projects in a certain way (e. g. Every help desk needs to work the same). Be careful with this approach, however – if you change anything in the template (add a new issue type, for example), you’ll also change it in shared projects sharing the schemes.
Correct Resolutions
Fix wrongly set Resolution fields next. The problem is that if there are either issues with a green status (“Done” category) and without Resolution, or in the “To Do” or “In Progress” categories, but with a Resolution, it can cause various issues.
Unresolved issues (with a Resolution) don’t appear on the “assigned to me” gadget and similar filters that hide resolved issues. Or the opposite – resolved issues show up in filters with “unresolved issues”, giving the impression that there is still work to do on them.
Most likely, their workflows are missing either a post function to clear the Resolution field when the issues are reopened or a screen/post function that sets Resolution when issues are resolved/closed. To find these workflows, search for the affected issues first. Create two filters:
statusCategory != Done AND resolution is not EMPTY
For issues in the To Do or In Progress status categories with a Resolution
statusCategory = Done AND resolution is EMPTY
For issues in the Done status category, but without a Resolution
These two filters will show you the relevant issues. Create a new dashboard with these filters, because new issues with the same problem might again appear after some time.
At this point, you’ll have all the information you need to start fixing the workflows – let’s do that!
When you’re done, correct the issues next. With Scriptrunner for Jira, you can resolve this problem by using the “Bulk Fix Resolutions” built-in script. You specify a filter and a Resolution (even “None”), and the app will set that Resolution on every issue in the filter. Very useful and time-saving!
You can also fix the Resolutions manually. In each of the affected issues’ workflows, add a global transition to the same status that changes (or clears) the Resolution field via a post function. Restrict the visibility of this transition only to the admins.
Then, perform a bulk edit and transition the affected issues. After they’re fixed, remove the transition.
Summary
Keeping your instance in shape is a continuous process that becomes easier with regular cleanups. What’s important is to start. If you can’t clean up everything we suggested at once, divide the cleanup into smaller parts during the year. The process of archiving Confluence spaces and Bitbucket projects is similar.
When on Data Center, there are more steps to maintain your instance: browsing server logs for possible issues, regular upgrades, and system health checks (setting the right memory and Java Heap, disk space, optimizing the database and network connections, etc.). Prophylaxes and cleanups go a long way in ensuring the application will remain working in top shape.
Conclusion
Maintaining your Atlassian Stack can become a challenge at some point along the way. But by following the best practices and tips from the experts and good preparation, you can get the most out of your Atlassian Stack and make life much easier for the users.
In this thorough article, we covered the deployment models, so you have a better picture of the possibilities you have, and then we talked about good governance which includes efficient documentation, the staff, meaning who should do what, and user accessibility.
In the final part, we went over one of the most important topics regarding your Atlassian Stack, cleanup. If you manage to keep your instance clean and up-to-date by doing regular cleanups, you can definitely avoid a lot of unnecessary and of course time-consuming work and keep every piece of data easily accessible to the relevant users.
So if you have taken all the steps and have come to the end of this guide, then congratulations! You can now say that you have a happy, healthy, and well-maintained Atlassian Stack.
Recommended Reads:
- GDPR: The Complete Guide to Compliance Regulations in Jira
- Migrating Atlassian Apps from Server to Cloud – Part I: Migrate Scriptrunner
- Migrating Atlassian Apps from Server to Cloud – Part II: Gliffy and Draw.io
- Migrating Atlassian Apps from Server to Cloud – Part III: Structure for Jira
- Migrating Atlassian Apps from Server to Cloud – Part IV: Automated Migration Paths