Introduction
Hi everybody, my name is Michael Roberts with SPK and Associates. I’m here with Edwin Chung, and Edwin’s going to talk to us today about a Bitbucket Server to Cloud migration. Ed, if you could give us a few words about the general size and background of this migration so viewers can understand the scope of this type of engagement.
Bitbucket Cloud Migration
Yeah, let me start with the fact that we were successful. It got done, the customer is happy, and their users are happy. It was a large migration featuring about a thousand users, 500 repos, and 200 gigabytes of data, which we moved from Bitbucket Server up into Atlassian Bitbucket Cloud.
Challenges with Migrating to Bitbucket Cloud
You had mentioned when we talked before about this that there were some challenges that were discovered after the fact, and some challenges that were known going into it. So, if you could talk to everybody about some of those challenges—what are the ones that you found out as you got into it and what are the ones that you knew going into it?
Yeah, we can talk about those. Some expected challenges—let me start with those. We expected, hey, the first thing that I want everyone to know, and Atlassian knows this too, is that the Bitbucket migration tool provided by Atlassian does not move everything. They say on their website that it doesn’t move user permissions on each repo and that they expect you to do that manually, which, if you have 500 repos and therefore 5,000 branches, is not reasonable to do manually. Atlassian is working on adding more features. Some of our results from this particular migration they’ve taken, and I know that they just updated the code to do user permissions recently when I was asking them about this during the Atlassian Teams Conference last month. So, it’s still improving. There are usual things; please plan time for those accordingly.
Expectations of Bitbucket Migration
Some unexpected things happened, right? When you go into the cloud, sometimes you have a lot of changes. I think one of the biggest semi-unexpected things that we had to overcome was the repo size limit. In Bitbucket Server, you can allow the bad practice of having very large repositories, but in Atlassian Cloud, there is a limit of 4 gigabytes for one repository, which is plenty if your users are practicing good habits and not storing binary files inside of Git directly—they’re using Git LFS or another solution. But that conversion, right, maybe I’ll call that data cleanup.
There’s a very common thing in migration: before you do the migration, you’ve got to fix these problems in your source system in order to get over there. Atlassian is very good about accommodating. By the way, they have a secret—a toggle to allow bigger repos if you promise that you’re going to fix it and make it a smaller repo afterwards. But still, you’ve got to fix the root cause problem, which not only takes time during the migration but also time to teach the users how to use a technology or feature or function that they weren’t using before. Our friend Carlos Almeida would insert the phrase “dark features” here. That toggle, I know that Atlassian likes to have some of those get-out-of-jail-free cards, those dark features, so that partners can help resolve problems with customers. So yeah, I’m glad that exists in the interim.
Timeline Expectations
Big picture here, Ed, in terms of the migration, can you give the viewers an idea of what that looked like in terms of timeline from start to finish and maybe a rough amount of time that had been spent on that type of migration?
We finished this migration in about six weeks, and that was uncomfortable, right? I don’t recommend doing that. I recommend giving double that amount of time because that amount of time is the correct amount for what we’re doing here. For us, we do a proof of concept, then we do a dev environment, then we do a QA environment. For this customer and many of our customers, we do validation testing, formal validation testing on the QA environment, and then go live. Squeezing all of those technical things into six weeks can work, and it depends on the size of how many things, but I think the thing that really you need to account for is the user experience. We’ve got all these users and they’re changing, and some people think, “Oh, I’m just using Git, and whether Git is pointing here or there, it’s the same,” and that’s not an accurate statement. Bitbucket adds a lot of features such as pull request approvers and Active Directory integration. It has a lot of features that aren’t part of Git, and they change between Bitbucket Server and Bitbucket Cloud.
Bitbucket Server vs. Bitbucket Cloud
Random trivia: Bitbucket Server and Bitbucket Cloud are not the same; they don’t have the same ancestors. Bitbucket Server was originally called Atlassian Stash and it became Bitbucket Server, but Bitbucket Cloud was never Atlassian Stash. It is a fresh product. It performs much better; it is much better and more efficient, but there are changes between those two different systems that you have to teach your users to accept. As we all know, change and change management are extremely difficult, especially when you’re talking about large groups of people. By the way, this is a Fortune 100 client that we’re talking about here—a large organization with lots of moving pieces, which is why Ed had to tiptoe through this migration in six weeks.
Recommendations for Bitbucket Cloud Users
So, Ed, last question. Is there anything else that we haven’t covered today that you would like to share with the viewers about lessons learned and things that people should do, especially if they’re integrating or working with an Atlassian partner like SPK to do this type of migration?
That’s a great question. I recommend the following two things: first, I recommend doing a proof of concept. Run the Atlassian migration tool, get it into the cloud, get a trial license, and then go look at it. What you’re looking for are differences between your server or data center version and the cloud version. But really what I recommend is you should do an inventory of your server or data center version. Go into the server and data center, use the APIs, and pull a list of every user, every project, every repo, every branch, every permission. Get it down on paper, and that will help immensely when you’re checking the cloud version to see the differences. Because if you ask a user, “What are the differences?” that’s too broad. But if you say, “This site has 1,500 users and this site has 103 users,” now it’s very clear something got missed because you don’t want to miss anything, especially when you’ve got historical software development Git commit histories in there.
Conclusion
Great. Well, thanks, Ed. I appreciate your time here. This is good to get this stuff out because it is really helpful to our viewers. For those of you watching, if you want to see more of this content, be sure to connect with SPK on YouTube. Subscribe to the channel, make sure you turn notifications on, and we’ll see you next time. Thanks, Ed.
