Introduction
Hello and welcome back to another SPK and Associates vlog. My name is Michael Roberts. I’m the Vice President of Sales and Marketing here at SPK and Associates. In today’s vlog, we’re going to talk about how Atlassian continues its shift of strategy towards a cloud-first future.
Now, because of that, many organizations are starting to feel that urgency around the upcoming data center sunset. But moving from data center to cloud isn’t just a technical migration. It’s actually a really strategic opportunity to modernize how your teams are collaborating, scale, delivering value, and utilizing some new capabilities on the Atlassian cloud platform.
So in today’s vlog, I’m joined by Carlos Almeida, our VP of Software Engineering here at SPK. Carlos, please feel free to introduce yourself.
Well, thanks, Michael. Yes, I’m VP of Engineering, been at SPK since 2010, working tons of different migrations over the years with Atlassian, working all kinds of other things in the ALM space.
Before that, I spent years doing chip design, working at Cadence Design Systems. So a lot of the hardware chip manufacturing world and the fab world is where I come from. Look forward to talking to you today.
Overview of Discussion
And so Carlos has a really deep history and expertise with these Atlassian migrations and overall big enterprise change. So we’ll walk through in this vlog about how I think the foundation is really properly assessing that current Jira and Confluence and what other tools you’re using, understanding that environment, the role of apps and marketplace tools, and then how to avoid some of those common migration risks like downtime and data loss.
Then we’ll also ask some questions around what a realistic migration roadmap should look like for these large organizations that are using data center and are concerned about that sunset.
Assessing Your Current Environment
So Carlos, I want to start with the beginning. How should teams assess their current Jira and Confluence migration, and how do you look at usage before that migration?
Good question. So first of all, SPK—we’re here to help you with this process because it’s not trivial. In fact, I’ll say that a lot of times we are engaged after organizations have tried to start it on their own, and either through resources or some other issues, they get hung up. So we’re brought in to try to help the process.
So at SPK, the first thing we do is we actually start off with a discovery call with you, and we’re interviewing you to understand the “why” behind the migration. Is it driven by the data center end of life? Are you consolidating environments? Are you moving from cloud to cloud? Are you trying to reduce costs or improve governance?
Then, having done this a lot of times, we’ve developed our own survey that we’ll send out to you that will help guide you with some questions. And there we’re starting to get into details like what version of Confluence or Jira are you on, how many projects, JSM or Jira, number of Confluence spaces and pages, number of users, what apps you’re using, what integrations you’re using, and also we get a little bit into your authentication model. Do you want to go single sign-on? Thinking of things like Atlassian Guard.
App Assessment
And then on the app side is where we start really, because we want to save you some money and time. So we’re going to ask you to look at all the apps that you have, fill out that assessment to us. And in doing so, you’re going to have an opportunity to try to figure out your usage.
Some of the apps will be first-class citizens and provide you metrics of what’s going on, and you can really see what’s going on with the apps. Other ones, you’re just going to have to find the folks who are using it. You get your key stakeholders and ask them, because I think that’s one of the biggest opportunities and things you can think about in how to save money and time—is looking at the apps and getting a handle on that before we start a migration.
Role of Apps in Migration
Yeah, so you talked a lot about the apps there. So what role do they play in terms of compatibility—those marketplace apps? How do they play in a successful migration?
So yeah, thanks. I look at the apps—I don’t really like calling them apps. They’re products, because an app could be a whole test platform. You feel like it’s a little plug-in—nope. Often they are a significant product.
So what we do, we really want to take the load off of you guys and give you as much information before we start, so you have some good data on how you’d like to proceed.
So once we get the survey data back, we go to work and we do what I like to say is a preliminary assessment. We look at the app’s availability. We see if the apps are available in the cloud. If not, is there an equivalent or something better native?
And we also try to filter things out because there’s a lot of stuff that sits in data center-specific world—things that talk to the database that don’t make sense anymore. So we try to remove those immediately to clean that up.
App Migration Complexity
And then we also look into what the vendors say. SPK does the extra step—we actually research every migration strategy for every app that is in your queue. And we’ll do this before we actually sign a contract because we want to get to a really good proposal for you to be able to do this as cheaply and as quickly as possible.
Each app is different. You’re going to find some of the apps are more automated, some of them are less automated, depending on whether they work well with JCMA or CCMA.
So what we do is we get in there. You’ll find an app is qualified as cloud-fortified is a good thing, which means they’ve actually done some work in trying to make JCMA or CCMA do some of the heavy lifting.
But then you’ve got everything else. We’ll dig into things like ScriptRunner. ScriptRunner is a very popular thing and can get very complex. So we start digging into what is your usage for ScriptRunner, how prevalent is it, how many variants of it, and we start coming together to figure out what we really need to do the work.
Because things like ScriptRunner often mean we’re rewriting the scripts or rethinking what we want to do.
Reducing App Dependency
And then also, one of the things I push for is we want to wean you guys off of the apps as much as possible, because you’re going to get a lot of good stuff out of the box with the cloud, especially in the automation space.
So we’re going to go back and say, well, this ScriptRunner thing—all it does is check a field in a workflow and it advances only if a certain condition is met. We want to make sure that you can do that out of the box. You don’t need that particular ScriptRunner. So let’s make something native for you.
So all this is to build something that’s as lean and mean as possible and save you money.
Version Dependencies
And then one last piece—by the time we get through all of that and we’re meeting with you guys again and saying, “All right, this is what it looks like,” I like to say the tail wags the dog here a little bit.
The apps will sometimes dictate what minimum version you could be on for Jira or Confluence. So at that point, we’ll say, “Hey, you’re on an older version—you probably should consider doing an upgrade to get you ready so when we hit the ground running, Jira is ready to roll and we don’t have to burn more time on that.”
Avoiding Migration Risks
So that’s pretty extensive. We really want to give you all the tools so you really know what you’re doing before we even start work.
I’m also going to set you up here, Carlos. I’m going to ask you a question that is a little tricky here. We are Atlassian partners, and we get a lot of these scenarios, as you mentioned, where people try to do it themselves, or they’ve tried multiple times, or maybe even tried with some outside help, but they haven’t been able to get migrated.
So how do experienced migration partners help organizations avoid downtime, data loss, and all the risk—kind of what you were talking about—all the risk avoidance? How do we do that?
Well, that’s, I think, very important because I think our value add is really our experience. We’ve done a lot of these, so we know where the bones are, if you will.
So first thing we want to do is we design a framework for a low-risk migration. What does that mean? We do everything in a sandbox, so nothing in production is touched.
We will go and do multiple sprints into the sandbox. And I like to say we are practicing for a Broadway opening. So each sprint, we are going through bringing the stuff over—Jira, Confluence, and the apps—and then we are going through doing the migrations per the apps, and then sending it back to you guys in a UAT.
We’re going to find issues in sprint one, sprint two, sprint three. We’re going to go through and mitigate every issue that we find such that when we are clean and we’ve built a back-to-forward runbook, we can go from beginning to end with a high degree of confidence that we’ve hit every possible scenario.
Right, so that’s risk avoidance.
User Acceptance Testing and Validation
The other thing we’d like to do is, in our assessment piece, you’re going to find that the apps will have different feature levels. They may say, “Yeah, this app is on the cloud. It’s not your own data center. You’re going to compare it to the cloud. Oh yeah, it’s there.”
But then you have to go look at, “Oh, it behaves differently.”
So we want to have you guys look, and usually they’ll provide a nice grid about how behavior is slightly different here—it works this way or that way.
The way we mitigate that is for you guys to get in there and play with it, because your experience and how you want the thing to behave is paramount in understanding if this is going to work for you.
So that again is in the UAT side.
Performance and Migration Execution Strategy
Other things we do—so we have the sandbox stuff going on.
Before we set up, we do some work on the infrastructure. Doing a pull from your data center can feel like someone’s doing a backup, right?
So what we like to do is make sure that we’ve beefed up your memory. We’ve taken care of anything we can to kind of lighten that load.
And then also, when we’re working, we don’t do anything during business hours. We’ll coordinate with you. We’ll typically do our sprints in the evenings.
We tend to do Jira one night, Confluence another night, and we’ll divide that. It’s usually into two different sandbox areas.
So we’re trying to lighten the load, no perception of anything going on to your users, and everything stays in the sandbox.
Final Migration Confidence
And then ultimately, like I said, by the time we get to no issues and mitigations, and we have metrics knowing how long it takes, the migration itself becomes a non-event because we’ve rehearsed it, we’ve done it, there’s nothing new.
I don’t think we’ve ever had to roll back in years—maybe once because there was something Atlassian did that had to change on us, some internal setting that we needed to flip.
But we’re really good on that, and we have a great track record. So that’s how we mitigate downtime or data loss for you guys.
Partner Value
Yeah, and I think that’s a part of the value of working with partners, right? We’ve done it before and we do it all the time.
It doesn’t mean that companies can’t learn to do it by themselves, but at the same time, you probably don’t want to learn how to do this more than once because you’re only going to do it once.
So let somebody that’s done this before and that’s had great outcomes lead that.
Migration Roadmap
So this leads me to my last question, Carlos. I think this is probably the most important.
What does a realistic migration roadmap typically look like for these large organizations that we’re seeing moving from data center to cloud?
Average is about one to two months, maybe a little longer depending on how many apps you have and the scope and breadth of that.
But what we break down is we start off—and this is actually from the point we get access, because I’ll raise that initially when we get onboarded.
The moment we can start getting in there and start looking is when our clock is going.
So we want to try to minimize the onboarding process to keep it as tight as possible, align with your schedule of course.
Sprint-Based Migration Approach
What we’ll do is we’ll break up our sprints.
We’ll have done the preliminary assessments, and we’ll start sprint one.
Sprint one is bringing over Jira and Confluence core stuff. We leave the apps off at this point.
We’re also handling the user provisioning, if we’re doing Atlassian Guard, all that kind of stuff. We do a bunch of security things as well.
Security and Permissions Review
One thing—we do a lot of regulated companies with high security—so we do some due diligence up front.
For instance, if you have Confluence right now in your data center, and we’re putting it out on the cloud, we’re going to review every space and permission for every page to make sure that they’re set properly.
We don’t want to inadvertently open it up more than you want to, because they are different. You have to set the permissions explicitly how you want them.
Similarly, we’re going to be looking at how your users are structured. We do a lot of cleanup because when we use Atlassian Guard, all the people across many instances come to light.
So there’s a lot of cleanup there.
App Migration Sprints
Usually sprint one, sprint two, and beyond—sprint two onward is all about the apps.
Just cleaning things up. If we’re changing ScriptRunner, we’re going to iterate, iterate, iterate with UATs in there.
The sprints usually, between us doing it and then handing it to the customer, are often a one- to two-week process to give customers a chance to go in, test it in UAT, give us feedback, and we’re going to keep track of any issue.
We’re going to have a full list of mitigations.
Collaboration with Atlassian
Also, when we start this process, we are partners with Atlassian, so we’ll have created a migration ticket.
There will be a migration manager with Atlassian working with us as well as you guys.
This is great because anything that comes along, including needing to extend your trials if something needs to go longer, we can make that happen.
Working with Atlassian, we also have a closer connection to their engineering department for any tweaks or internal adjustments needed for JCMA or CCMA.
Final Execution
So that’s essentially what it looks like—two to three months.
Once everything’s done and you guys have come back to us saying thumbs up, UAT looks good, customers know what to expect, communication has happened—then we do it.
So that’s when we launch the Broadway show and do the migration.
Closing
Awesome. Carlos, thank you so much for sharing these insights. You obviously have done this many times and looked at all the risks and where issues can arise.
So thanks for sharing that with the audience today. Appreciate it.
Absolutely, Michael. Thank you very much.
Call to Action
If your organization is starting to think about that Atlassian data center sunset, now is really the time to start planning.
As Carlos mentioned, the earlier we can assess your environment and help you define that strategy, the smoother and more successful that migration will be.
And if you’re looking for guidance and migration support in that journey, our team at SPK and Associates can absolutely help.
From our initial free assessment, like Carlos walked through, all the way through the execution and optimization of your Atlassian cloud environment post-migration, we can absolutely take care of that for you.
So be sure to reach out if you’re looking for that.
Our socials and contact form are linked in the description.
Also, we encourage you to like and subscribe to the SPK and Associates YouTube channel if you like this content.
Thanks for joining, and we’ll see you next time.
