IntegratiON interviews E02: Discussing Jira integrations with Alex Ortiz

You’re a YouTuber yourself, can you tell me more about the type of content you are publishing – what people can learn watching your channel?

I wanted to start a YouTube channel for several years, and one day I thought “hey! I’m really good at Jira, it’s what I do, why not talk about Jira?”. My channel is all about Jira, it started from the administrator’s point of view, and how to manage it. Then it evolved to show the user’s point of view.
Now, I’m answering users’ questions, and community questions, I’m doing add-on reviews, tips and tricks, and more.

You’re helping people with Cybersecurity. What are the main differences between SaaS, and On Premise deployment of the apps regarding security?

I started my career with a defense company, they are obligated to have full control over their data. The same goes for the FinTech companies, Pharma, and more. For those companies, where data control and data security are crucial, there is no other way than On Premise. Of course, it comes with a cost. Now you need an IT infrastructure, and support teams. You need to have disaster recovery plans, SLAs, and so on. Most companies will favor on-premise because they have control, but there is the cost element. SaaS companies are doing a really good job trying to market themselves as “hey, we will try to keep your data safe”. I’m leaning towards trusting big, well-known companies with their SaaS – because there is nothing guaranteeing me that my on-premise data are secure. The threat is always there. If some actor will want to get your data, they will move mountains to do it. From the threat perspective, the probabilities are very small. And big companies are doing what they can because their reputation is on the line. When it comes to your IT department, you need to make sure they will do their part, and that they will keep your data secure. What do they have to lose? Let’s remember, that in the end of the day, the most vulnerable thing, is the human element.
With smaller, not well-known companies, you can’t be that sure. They usually don’t have big budgets for certificates, licenses, and hardware to keep your data secure as big companies have.
Sometimes is better to have the on-prem version, secured as you wish. Does it make sense to use native tools for integration/migration?

Native tools are often a bit limited. Importing data from Jira, or to Jira you can use CSVs, but they will do just one simple scenario. If you need even a bit more, or some customization, you won’t be able to use it. For us, at getint.io, we have a lot of customers trying native tools first, and they were very unhappy, hopefully, our platform was able to help them.

Why do you like Jira so much, what makes it unique? Can you compare it to Azure DevOps?

My journey started with TFS (Team Foundation Server), the precoursor of Azure DevOps. I started using this in 2013, so quite some time ago. I was using it for 3 years before I started using Jira. So why do I love Jira so much? First, it’s the customization. Back then it made sense to use TFS since it was like the all-in-one Microsoft shop. You used Microsoft tech stack (f.e. Visual Studio for development, C++), so TFS was integrated into Visual Studio – you didn’t have to leave your developer tool to go and track your status. Now, not a lot of people are developing using the Microsoft tech stack. They are agnostic to a tech stack. That’s where I see Jira come in and shine. Jira entered as an amazing project tracking software, that doesn’t care about the technology used. What’s also great is that you’re not limited to just developing software. Azure DevOps is geared toward Software Development. F.e. for one company, I introduced Jira as a purchase order tracking system – it goes way beyond what the Founding Fathers thought it might be used for.
Additionally, I see that the companies are trying to minimize the noise made by the variety of tools. And it makes sense to have one Jira, that can be used also for non-technical teams, and have one source of truth that can easily scale.
But the plus for Azure DevOps is the price there is better.

Why do you think people integrate Jira with another tool like Azure DevOps, ServiceNow, or Asana?

1. I prefer tools that are designed to work together (through the marketplace) over tools that have hooks but only because tools that don’t have native integration tend to not have the best support.  Additionally, native tools have lots of limitations, not all fields are supported, plenty of things are lost, and not possible to be migrated. There are two types of people – the ones with all the time in the world, and no money – who can use the native tools. And there are those with all the money in the world, and no time – those who will use the best tools. When making this decision, you always have to calculate the ROI (return on investment) – taking into account time spent on manually copying and pasting issues and the risk of losing some data along the way. Usually, paying the license fee is a smaller cost, it’s easier to just pay and focus on the north star, which is actually generating revenue. Communication is key when you have friction here, which has a mandatory consequence – much bigger than some monthly fee of a license. The risk of making a decision based on not accurate data could be very painful, it can cost millions of dollars. When it comes to migration, people often don’t realize how complicated it can be. Additionally, there is also a self-development option – which is often a distraction, and plenty of customers are choosing to go with the existing solution anyway.

Does it make sense to use native tools for integration/migration?

There is no quick answer, but it’s usually about 3 months. Of course, if you have a simple scenario, it can be much quicker than this. Remember about testing, taking all requirements from the business stakeholders, and finally implementing it.

How to prepare yourself, business representatives, and other stakeholders for integration/migration?

Make a plan, identify risks, practice a migration, review results and then just do it. Please remember, that migration or integration requires much more than just technical knowledge. There is so much more coordination that has to happen outside of the tech team. The complexity is not in the technical part, it has to be in what’s happening what’s before, and after. You need to make plenty of decisions. When it comes to migration, you need to decide f.e. what happens with the old tool and the old accounts. Also, make sure you know the risks. F.e. losing some parts of data like attachments, or comments (like in the native Jira – Jira migration tool)?

How much time it should take to migrate from one tool to another?

Depends on the historical context.  I prefer the band aid approach, so no more than a few hours. I mean, migration itself few hours (depending on the volume, 20-30 sec one task). The whole process with good scope description, tests, execution – 3 months.

What can go wrong when setting up the integration?

Anticipate it can go wrong, always. The worst thing is simply to lose data.
Setup a sandbox, make a copy of your production environment, and just practice. At the end of the day, data integrity is key. You want to make sure, you practice in a controlled environment, and you document everything – not just remember things. You won’t remember things a week from now. Print out those to ensure they will last, and no one will incidentally delete them.

Alex about Getint

What I like in Getint.io is the plug-and-play approach. It takes a lot of complexity out, it makes things intuitive. Takes the guesswork out and offers a lot of integrations.

Alex Ortiz bio:

Alex is a Jira administrator working with companies all over the world to help them with their Jira problems. When he’s not fixing someone’s Jira, you can find him on YouTube where he’s putting Jira videos to help everyone get better at Jira. Alex has been a Jira administrator for the last 6 years and has been in IT for 12 years.

‍