This is the second blog in a four-part series addressing the 2024 end-of-support for Atlassian server-based Jira and Confluence. Time is running out. Do you have a migration plan yet? Have you started and failed? Do you need a partner? This series will explore these questions and more as you assess your current plans for migration, your timeline, and the best practices to ensure your migration to Atlassian cloud or data center succeeds.
It may seem like a very strange question in a blog post about cloud migration. Of course you know where you want to be, right? In the cloud. You want to move some server-based software, like your Jira and Confluence instances, to the cloud-based versions.
But that doesn’t really answer the question because the cloud-based instance you use may be significantly different from the server-based version. Which means that part of setting out on the road to the cloud is answering that question, “do you know where you want to be?”
To move your server-based software to the cloud, you’ll need to first understand (and document) the state of your current instance: cataloging everything from configuration settings to integrations. But that documentation should also include explanations of how teams are currently using the software. These can be diagrams or other representations of the processes through which employees work with the application.
With that current state assessment in hand, it’s time to look at the ideal state of the application. How would you want the software to work? What integrations would make the software more valuable, improve productivity or increase efficiency? Although this “future state” will focus more on use cases and workflows, it can also include configurations. For example, maybe one of the future states is single-sign on. This isn’t necessarily a feature of the software but rather a way in which it is configured within your IT security framework.
You now have a comparison to make between the current state and the ideal future state which illustrates the disparity between what’s being used and what might be possible. Although documenting what’s currently installed and what you would like to see possible can take some time, especially when gathering all of the input regarding that future state, the result is what you need for the next step in your migration journey.
The gap between current state and future state is the basis of the plan that will drive your migration forward. Of course, your gap may include dozens of changes and it’s not feasible to tackle them all simultaneously. To develop that plan, you’ll need to evaluate each element along a number of factors:
An easy way to do this is to score each element on a numerical scale. For example, a score of 10 for priority is the highest while a score of 1 in time means it won’t take very long. Consider the table below which examines an element, SSO, in the future state of a cloud application:
Out of a possible 40, the SSO feature scored a 36 which would support adding the change to the initial migration. Remember that you need to reflect the individual scores with the objective: to help decide to make the change in the initial migration or not. So although normally a one (1) would be the highest priority, here it’s 10. For Cost and Time, a one would more often mean lower but in this case, it means higher. Of course, you can tailor the scoring to whatever serves your needs but the goal is to assist you in making a decision about what elements from your future-state to include in the initial migration.
This is the point in the movie where the action stops and the main character gets a moment of self reflection. Maybe it’s like Matthew Broderick breaking the fourth wall in Ferris Bueller’s Day Off. But it’s your moment now and it’s all about what you can do besides just moving a piece of software from your network to the cloud. It’s about thinking of how you use that software. What departments could use it? How would they use it? To what systems could it connect? And how would processes be improved if it connected to them?
In other words, you have the opportunity at this moment to think about transformation instead of a lift and shift migration. When you go through the planning process, imagining that ideal future state of the application, you need to take the next step and think about the ideal future state of your business using the application. This is the opportunity with every migration and shouldn’t be overlooked: improving your business through the benefits of a mission-critical application in the cloud. It’s not just about translating how you use the software but about rethinking how the software supports the way you do business.
If you are already working with a partner to perform the assessment we covered in the first blog, then it makes sense to have that partner help you inventory your current state, define your future state, build the gap analysis, and score the outcomes.
If you assessed your cloud readiness yourself, you should still seriously consider engaging with an experienced partner. Why? That expertise can identify opportunities to improve how your systems work, anticipate not-so-common problems and roadblocks, and ensure a successful migration.
ServiceRocket has been helping customers harness the benefits of their Atlassian software and platform for 20 years. Using our proven ServiceRocket Methodology, we work with customers to ensure that their future state is well-defined and the plan reflects what can be accomplished on time and on budget. And we get the migration to cloud right the first time. Now that’s peace of mind.
Visit our Migration Hub to learn how to move beyond a simple lift and shift migration to a true cloud transformation.
Planning a move to Atlassian cloud? Our newest e-book can help you avoid the most common pitfalls using ten best practices.
