Video Transcript
Presenters:
Chris Bland | CEO & Co-founder | BDQ
Dom Bush | CTO & Co-founder | BDQ
Chris Bland: My name is Chris Bland. I'm a certified Atlassian consultant. I'm one of the Co-founders of BDQ which is an Atlassian Solution Partner in the UK.
Dom Bush: And I'm Dom Bush. I'm also one of the co-founders of BDQ and also a certified Atlassian specialist.
CB: So what we wanted to talk about today was the migration process. This is a question we get a bunch of questions from customers, a lot of which are similar. So we thought we'd just talk about some of the sort of high level problems that you sometimes see and some of the approaches we used to get around them. So firstly, one of the obvious questions here is why can't we just move it to the cloud? That should be easy. Isn't Atlassian Cloud just like Jira in the cloud? Think we both know the answer to that is no.
DB: Yeah, absolutely. They are very different products, the different way that the apps that people use to extend the product structure in Confluence work differently both in Server and Cloud, and also the way that they architected the products in Cloud in order to meet the scale requirements means that the two products have diverged between the two.
CB: Yeah, they're completely different implementations basically. Now one is on the cloud. It's been architected to work on cloud scale. Back in the day it was basically Jira servers hosted somewhere basically on AWS, that now is no longer the case. Maybe different implementation, addons are architected differently. But what is the same I suppose is the data is compatible between the two things. So you can move the data from all together. So that's basically you could say why, why fundamentally it's not always that straightforward just to migrate from Atlassian, Server to Jira in the Cloud because you're not just migrating a server instance. Upgrades really from one application to the other. All that happens to be there is data compatibility between the two. So I think next question is what is our overall process? I think it's fair to say we had I think we can summarize it, basically, thus. Discovery - we make some choices about whether we are going to do a direct migration or a clone. Then we will trial the migration, develop the run book, get UAT candidate, and then schedule the final migration and go live once the UAT candidate has been validated by the client. Needless to say, it's not necessarily as straightforward as that when we get into the detail.
DB: Absolutely.
CB: First of all, when it's a lift and shift or rather, I beg your pardon, first of all when it’s a discovery, sometimes we have to find out whether this is going to be a lift and shift or a reimplementation.
DB: Absolutely. Some some customers might want to just literally get the data from the server instances and get it up into cloud as an equivalent. Others might take it as an opportunity to re-architect somewhat their solution. That may be data that they don't need in the cloud, which is now not required going forward. So that might be an ideal opportunity to tidy things up.
CB: Yes, I think it's fair to say is that if you got a vanilla system on Server and it's straightforward, then maybe a lift and shift is perfectly sensible and the right thing to do. If you’re a client and maybe you’ve got an older system and that it's evolved over time, there's might be perhaps lots of customer fields, there's lots of apps or plugins that may be in there redundant, actually going to be, given the differences between the two platforms. It will be very difficult, in fact to move from one to the other and actually try and achieve a perfect copy so it can actually be cheaper just to re-implement based on your business outcomes - taking a sort of Cloud first approach and then move the data across essentially into that new system. Obviously we can do both, but I think that's probably the main options that are open to people. In terms of the next one of the next thing to be asked about sometimes is should we use a clone or can we just do a direct migration straight from our server up to the cloud? Do you think some of the benefits of using a clone, would you say?
DB: One of the primary advantages is that it allows us really to decouple the development of the migration process from your everyday systems so there's no chance of any impact on your business as usual. We can take a copy or a clone of the source and and work from that clone, work from that copy to develop the migration from book. So it does have a number of advantages there that we don't sort of trample, if you see what I mean.
CB: Yeah, it's just I suppose actually we use a clone, so we typically clone on AWS, don’t we? We put it where we have a dedicated AWS server wherever the client want it’s to go, whatever region and want to go, usually for data protection reasons. And then we set up syncing so that where possible, so that we don't have to do an enormous update every time, we can keep things up to date, reduce the pressure on the client network. But yeah, there's let me, just basically let well, some of the things that we've been told really gives them a lot less risk, it’s read only access for us to that production system. It allows them to continue with business as usual in the production system with basically no impact. And all our data prep activities do not impact them in any way. So we can just do it all on the clone basically and re-clone, can’t we, if we need to.
DB: Absolutely. Definitely.
CB: We can do it, because I know sometimes you have to do multiple test migrations to get to this point.
DB: Absolutely. We have to do a number of iterations in order that we can reduce risk for the actual production migration.
CB: And that leads us to the next point, doesn't it? We have to trial the migration to develop the runbook. So trialing the migration, what does that still usually look like?
DB: But essentially we work through the process of understanding what's in the source system do various different tests against it. And run a number of different migration attempts and take learnings from each of those and apply them to the next one. So we get to a point where we have a process that will work for the production migration.
CB: Yeah, and so we’ll know how long it's going to take as well, don't we.
DB: Absolutely. It's one of the critical outputs of that whole process is really understanding what the window needs to be for the actual production migration. Yeah.
CB: And then as a result of doing these test migrations, one of the main outputs, the other output is a UAT candidate on the cloud, isn't it, which basically that we can demonstrate to the client exactly what they are going to get at the end of the day.
DB: Yeah. I mean it's critical really, that the the UAT candidates are reviewed by the customers users to understand how well it's going to match their expectations when we actually do the live production and we can feed those, any issues identified during that process, back into the runbook to make sure that we resolve those for the next iteration and the next one and then the eventual production migration.
CB: It's all about trying to get the highest quality UAT candidate while minimizing the amount of time clients to spend on it, basically. But that is something we can help with, UAT. And then once we've done that, once that's been signed off, then basically scheduling the final migration go-live isn’t it? And by that time we've got the runbook. So we know exactly what the process is going to be and how long it may take and what's going to be produced at the end of the day in terms of UAT.
DB: Absolutely, yeah. Which leads to a good result and also put in place plans for if, on the day during the production migration, problems occur, that we can back that out in a way that doesn't impact any of the systems that the customer relies on. So we can then go again, in the event that there is a problem.
CB: In terms of apps. Interestingly, because there's various wrinkles throughout this process and apps are one of those. Some of them basically have equivalents on the cloud. Some don’t, as we've said, the architecture is completely different. Basically, you know, it's either embedded if you're using Forge or it's having to run on your own platform as a service and integrated in. It’s not the same as server where you basically got an integrated bit of Java. Some of them have migration paths and some don’t.
DB: Yes, absolutely. So some of them to integrate into the Atlassian migration tooling, in which case that's good and it will move over the configuration into cloud for you. Some apps it may be that you have to reconfigure them manually and it might be that some apps don't have a cloud equivalent, in which case what we would do is provide a process for how we could look at re-implementing some of the functionality with our different apps or potentially using automation in the clouds to replicate some of that.
DB: So there's a number of different ways that we can get equivalent functionality for the customer, based on what they use currently in server, in cloud.
CB: That leads into an interesting point actually regarding automations. So, automation apps work differently, don’t they, in Server versus Cloud. There are some things like ScriptRunner, Jira utils and so forth, you know, very well established, very powerful. You might look in to post functions of workflows and that sort of thing. However, those will not necessarily migrate over because those automation apps do not necessarily have the same capability on the cloud. It may be impossible to do that because of the difference in architecture. That being said, cloud is actually a more extensive automation capabilities natively, out of the box on all the time. So I think you've actually found that sometimes it's best just to look at the business requirements of what's there now in server and then just identify how to redo those in the cloud using its native features.
DB: Yeah, absolutely. It's just much more of a cloud native approach. “Let's look at what the requirements are and implement them” is usually the best way in cloud.
CB: And I think in one or one or two cases where you can't easily do it with an automation we've just done a simple Forge App for the client, basically a simple private forge app, that is - which just matches their business requirements. Then apps can basically do anything.
DB: Yeah, I mean, it's a very powerful approach for how you can write apps for for the cloud platform.
CB: So basically I think we're also going to say actually how we deal with scale typically, again, our usual approach with that is the clone and sync approach isn’t? Now, the syncing in that - there’s two things. The clone allows us to basically not interfere with, obviously what is a large business critical application,a nd syncing basically reduces the pressure on the Clouds network. If there is a large amount of data that's got to be uploaded. We can just keep dripping over into the clone, can’t we - rather than having to Big Bang refreshes, which makes it easier when you are trying to do an upload to do the migration test. It takes advantage of the AWS upload speeds doesn't it? From, from the clone server.
DB: To the Atlassian infrastructure? Yeah, absolutely.
CB: Yeah, definitely.
DB: Yeah we have found that. Yeah.
CB: So actually can make the final upload a lot quicker during the go-live process. Ah yes, other things we get asked - JCMA, CCMA and XML, what are these things? Other than different ways of getting the data.
DB: So the original approach for migrating to cloud was to use the XML and XML import. So the XML - export from server is really sort of a backup mechanism which allows you to take the contents of the repository and write it out into a structured format. So you may want to recover later, you know, recover from a backup. So Atlassian leveraged that for the initial approach and that mechanism still exists, but they have limited it recently to instances of over a thousand users. So and the reason for that is because they brought out all the bits of functionality, other approaches called the JIRA Cloud Migration Assistant and the Confluence Cloud Migration Assistant. So these are apps that get installed in the source servers, source applications and they run a migration from that into your new instance. So they are very good pieces of tooling. They, they do work quite well for, for the aspects of the instance that they support and it does provide a reasonable amount of documentation at the back of the process in the form of logs which allow you to see what has happened of any issues that have cropped up. However, it doesn’t - both products don't do absolutely everything, so one of the one of the things that we have to sort of help our customers with is understanding what the impact of those things are.
CB: Yeah, I mean, the XML import export was not without its problems.
DB: No, it was to a certain extent very much a black box. It would run for a while and sometimes the restores would not work successfully Atlassian support was very good. And they did provide a great deal of support around that. However, it was obviously an issue when they wanted to scale that up to get more customers onto cloud. So I think that's why they introduced this JCMA and CCMA to link to help with that process.
CB: Yeah. And it doesn't make like does make life easier. I mean if it's still I mean, you can still get XML if you get over a thousand users. Now the JCMA though, which is a bit of an issue, it doesn't migrate boards and dashboards by default and it may be an issue if you've got a lot of them basically on older instance where we've seen a hundreds or thousands of dashboards and filters.
DB: Absolutely. There are some what they call dark features for functionality that does do some of this, obviously I think it's like a prerelease version of functionality that will eventually come into the main products and we have used those quite successfully on a number of projects. But there are again, there are potentially issues that we have to look at as part of the migration process to make sure that you get what you want in the actual target cloud instance.
CB: Yeah, exactly. And on that note, it should be said that Atlassian are really good at their support during this process, actually in helping out the other end. So if you do this stuff yourselves, Atlassian will help you don’t worry about that, in terms of filters, boards and dashboards and how to see what's migrated, how to see what hasn't migrated, because that is obviously a key issue. We're going to cover that a little bit more in another, another video where we are going to get into a little bit more detail about some of the problems that we can see. So I think that's some of the main questions we've covered. Just to sort of wrap up, the overall process tends to be discovery, make a choice of what you want to do it clone or direct. For most people as a clone and then it's a trial migration, developing the runbook, developing the UAT candidate as part of that process, going through UAT and then scheduling final migration and go-live. As you've heard, there's got to be more to it than that in all the steps, but that's fundamentally the way to go. Anyway, we'll catch you soon on some other videos.
Many thanks for your time.
DB: Thank you.
Field Service Management
Easy Email Attachments
BDQ Migration Analyst
Attachment Manager
Real Signature
Real Signature
