This is the third 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.
As you learned in the first two blogs in this series, migrating requires you to ensure you are ready to move to the cloud and that you have a plan for it which covers the current state of your application and what the ideal future state would be.
But this is where the rubber meets the road.
Faced with executive pressure to make the migration happen (especially when it’s a required migration with a deadline, like Atlassian), IT management may take the path of least resistance: the lift-and-shift.
Let’s face it, moving software from server-based versions to the cloud can cause a lot of anxiety, especially when the software is mission critical, like Jira and Confluence. Which is why many businesses simply opt to port their data to the cloud version and call it a day. No muss, no fuss. Any functionality which doesn’t port is left behind. IT focuses on one thing: making sure the core features of the software work and employees can continue to use it for the obvious use cases.
Many companies want to migrate to the cloud because the benefits are well documented. First, there are the cost savings. Next, there is better resiliency, scalability, and reliability. Finally, although you may not know it, an application in the cloud can actually be more secure than the same application running on your network. But a migration done poorly, such as just lifting-and-shifting the data, can potentially have more negative impacts than one not done at all. You can disrupt processes within the company (such as how customer support tickets are routed through different systems). You can lose key functionality provided through integrations with third-party software (sometimes custom built). And you can impede the day-to-day jobs of employees by preventing them from accomplishing what they need to do.
That’s why the first two blogs in this series focused on the groundwork which needs to be accomplished for a successful migration: assessment and planning. And although those activities can seem daunting and time-consuming, they are critical to a successful migration. Still, even if you have the greatest plan in the world and everything in your company is ready to make use of the cloud, a migration may still fail if it falters during execution. But following three basic key steps can assure you remain on plan and on task.
This may seem like the obvious first step, but it’s important to call it out because it’s where the initial surprises will appear which can threaten the success of your migration. When your employees or partners begin the initial configuration of the cloud instance of the software according to your plan, they may find settings or functionality which don’t conform to the intentions of the plan. These surprises may require adjustments to the plan, the involvement of key stakeholders to review new recommendations, and even users to weigh in how the surprises will affect usage. Still, at the end of this step, you’ll have an instance into which you can move your data.
Once the instance is ready, it’s time to move the data. At this point, it’s much more than lift-and-shift. You’ve already configured the instance according to the plan and maybe even made some adjustments along the way. But moving the data shouldn’t be taken lightly. Care should be given to ensuring data integrity and tests should be performed after migrating to test such. Even if moving the software is successful, failing to guarantee the health of the data can be just as bad as a lift-and-shift.
Once you have the data shifted into your new instance, there’s an opportunity to optimize functionality and other settings before cutting over from the server version to the cloud version. Depending on how long the first two steps have taken, you might even have time to implement other future-state features before meeting your migration deadline. Regardless, much like the first step, this step should involve that cross functional team explained in the first blog working closely with power users (SMEs) to verify that everything works perfectly post-migration.
Not allowing enough time to ensure the cloud-version operates as intended is one of the main reasons migration projects fail. However, running the server and cloud versions in parallel gives you time to fix and optimize, to meet user needs, before cutting over entirely. Avoid this and other common pitfalls with our newest e-book.
Your plan is a clear roadmap for implementing the migration. And there will be very obvious elements you’ll tackle such as simple configuration settings. There will also be clearly-defined elements that, although not as easy as a configuration setting, can be managed. The real test of the migration will be the surprises, especially those that crop up in that first execution step.
Despite the best laid plans, parts of your migration won’t go as you imagined. There will be hiccups and setbacks and derailments. How you deal with them will be just as important to the success of your migration as the plan itself. How will you respond if an unforeseen circumstance requires more money, more time, or more resources? Perhaps you can afford to squeeze it into the budget or timeline. Or, perhaps you will restructure the priorities after communicating the issue with concerned users. However you deal with surprises, just know that they will happen. Having a buffer in your timeline and your budget will allow you to better navigate these surprises so that you can keep your migration on track for success.
Implementation takes expertise. Sure, you can wing it and apply whatever resources you have to pull off the migration, but you won’t be assured success. And, handling the “gotchas” that will undoubtedly pop-up during the process, requires experience. Rather than take the chance of your migration ending up as a line-item in the corporate history book of failed IT projects, you can use a partner with the expertise and the experience to ensure your migration is successful.
With ServiceRocket, you’ll get certainty, expertise, and success built into your migration. When you work with our consultants, you’ll rest assured that not only are the obvious elements being handled, like moving the data and implementing the features, but the opportunities for transforming your business are identified and addressed.
Planning a move to Atlassian cloud? Our newest e-book can help you avoid the most common pitfalls using ten best practices.
