5 min read

Pros and Cons of a Cloud Migration

By Luis Machado on Jul 5, 2021 12:23:50 PM

Blogpost-DisplayImage-July_The Pros and Cons of a Cloud MigrationThinking a move to cloud might be the way to go for your company, but you're not exactly sure if such a move is right for you? There are a few questions you should ask yourself about your organization to understand the context of what a migration to cloud would mean for you.  As you're navigating the pros and cons associated with migrating from on-prem solution to cloud, you have to understand that how these factors are weighed largely depend on the context of your organization. Asking the following questions will help you establish that context:

Why move to cloud?

For context, the term 'Cloud' can be somewhat ambiguous, so if not otherwise stated I'm referring to cloud in the SaaS sense (Software as a Service), that is, maintained by a 3rd party and available in a cloud setting, such as the Atlassian product suite. There are other flavors of cloud out there, but the SaaS model is where we'll maintain our focus. The first question you want to answer is why? Why are you considering moving to cloud in the first place? Are there any specific pain points you are feeling in your current setup that you think might be alleviated by moving to cloud? Understanding what your potential need is for a cloud migration will help you to develop a business justification for the endeavor, as well as allow you to start to build the context of your specific situation. If the reason is "We're spending too much time on maintaining infrastructure for our on-prem solutions" then something like having no maintenance in a cloud environment would be weighed very heavily in your case.

What are you moving?

What are you going to be moving?  What does your current on-prem setup look like? How big is your userbase? What 3rd party add ons or apps are you using? Are you using a single instance and are wanting to consolidate in addition to migrating to cloud?  How much historical data do you have? These questions can help to establish the potential complexity of the migration you're looking to perform.  One of the major considerations that has to be factored into a cloud migration is the cost of entry. This extends from just the literal monetary cost to include time and human resources as well. If your company can't afford to divert labor to perform a migration, is it worth it for you to contract the project out to a 3rd party? Having an idea of what you are migrating will help you weigh the various options and give you perspective to consider the impact.

Pros

Now that you've established the context for you migration, let's take a moment to talk about the potential pros around migrating to cloud.  When comparing cloud to an on-prem solution, you can really break down the pros into four main points:

  • Accessibility
  • Scalability
  • Maintenance
  • Cost

Let's take a look at the first point, Accessibility. One of the great things about cloud is that it's accessible from almost anywhere in the world right out of the box. You don't have to configure any VPNs or allow lists, no special permissions groups to modify, all the data replication and content delivery is managed for you, and has a low cost to entry.

Scalability is another major pro in favor of a move to cloud and falls along similar lines as Accessibility, and typically goes hand in hand with Maintenance. The infrastructure behind the application or service is purpose-built on a platform intended to be scalable in order to support multiple customers.

Add to this the fact that you no longer have to be responsible for maintaining that infrastructure, you can focus efforts and resources elsewhere in your organization. If maintaining infrastructure is something in particular your business struggles with, making a shift to cloud can have a huge positive impact.

This leads us nicely into the topic of cost.  Depending on the specific context, cost can sometimes go either way: I'm including it in the pros section because I think in most cases, especially if you factor in for the long term, your costs overall will be lower with a move to cloud. Figuring costs in a cloud move takes some doing because there can be differences in the types of costs you'll encounter in a cloud setting vs. an on-prem. Again, because this can be pretty heavily dependent on the context of the specific situation being analyzed, I'll throw out a few common factors but I don't want to give any potentially wrong impressions. Cloud vs on prem costs infographic

In the table above I've done quick breakdown to illustrate the basic differences around Cloud and On-Prem, and I've added another column to include the option of moving to cloud as SaaS model vs self-hosted cloud. Cloud hosted and On-Prem hosted have some similar costs categories (licensing, infrastructure) but there is some reprieve you get from cloud specifically around the depreciation of hardware and maintaining the infrastructure. In a cloud model this is mostly tied to licensing and the monthly cost operating fees associated with the virtual hardware you have allocated for your purposes. Versus the more traditional model of maintaining physical servers, the personnel costs associated with that upkeep, and the cost you incur with depreciation. In a SaaS model this all mostly wrapped into the licensing cost, which is typically why licensing for cloud is both more expensive and more complex. 

Cons

There are of some potential tradeoffs and downsides to consider as part of a move to the cloud. The biggest areas that might cause you or your organization trouble include Control, Security, and Flexibility.

When you break it down, the concepts of control and security almost go hand-in-hand.  Control is probably the hardest thing to overcome when talking about moving your data to the cloud and understandably so. The bottom line of operating in cloud environment is your data lives somewhere outside of your organization and the infrastructure is managed by another entity. You're putting your data and your trust into someone else's hands. While this is not necessarily a bad thing, it can take some getting used to, and some adjusting of your internal methods or practices. Being familiar with the support process can help with this as know what information you can request and how to get it will help to alleviate some of the disjointed feeling when attempting to manage your application.

On the security front, if your company has very specific security requirements or has specific regulatory bodies you have to comply with, there is an extra layer of consideration when weighing the prospect of moving to cloud. It's important to first identify what those needs are and reach out to the cloud provider ahead of time to find out if those requirements can be accommodated.

Lastly it's important to consider that moving to a cloud application means you will not have access to anything beyond the application layer. This can mean workarounds previously in use with the on-prem solution may need to be re-considered or re-engineered, and there are potentially additional restrictions around API calls and traffic to/from the application. Spending some time discovering what your needs are vs what is available to you in a cloud setting will be key to realizing these potential pitfalls.

We are getting to a point where we're moving from "Is cloud the right choice?" to "Which form of cloud is the right choice?" Not all situations involving cloud are the same, and careful consideration and weighing of options is important for any potential move.  Having the right tools to plan and execute the transition as well as an understanding of the context of your environment can make all the difference when deciding how to move forward.

If you have any questions on migrating to cloud, have run into trouble implementing a migration, or simply want to see if your organization is making the most of its digital infrastructure and operations, contact us and one of our experts will reach out to you.

Topics: blog saas cloud digital-transformation cloud migration
3 min read

4 Things to Look Out for When Migrating to Atlassian Cloud

By Jerry Bolden on Jun 28, 2021 3:17:41 PM

Blogpost-DisplayImage-June_Challenges moving from server to cloud (# things to look out for)Migrating to cloud can be a challenging move for any organization: there are many moving pieces to keep track of, and with the threat of negatively affecting both internal and front-facing operations, failure is not an option! Here are some key blockers to keep in mind when migrating to Atlassian Cloud from on premise instances, so that you can review ahead of time just how prepared for a successful migration your company is:

  • User Management
  • Automations
  • Size of Attachments
  • Apps

User Management

User Management and how users are set up is a major difference when operating in Atlassian Cloud versus on premise. This is an important obstacle to understand and address, as the approaches for user management are different between cloud and on-premise. Key to this is how users are created and managed; equally important is identifying any users with missing or duplicate email addresses, since these cause problems with data integrity and users being able to use Filters and Queues in Atlassian Cloud. 

Automation

Automations are critical to research, as some automations may not be functional or even allowed in Atlassian Cloud: these will need to be identified and assessed to determine the balance between the value they bring and the level of effort of recreating them. 

Attachments

Size of Attachments becomes critical when using the Jira Cloud Migration Assistant, as this does not support migrating Jira Service Desk projects, which may require importing data via Site Import that forces attachments to be uploaded separately in 5 GB chunks, one chunk at a time. This alone will drive the migration of attachments to exceed a typical outage window, as the Site Import process must first conclude prior to uploading attachments. 

Jira Service Management utilization is tied to the size of the attachments as noted above. While JSM is used heavily it is currently not able to be migrated using the Jira Cloud Migration tool. With that being said this drives the use of site import. With this comes having to migrate the users and attachments separately. This becomes more moving parts during the migration outage and the coordination and timing will become even more critical.  

Apps

Jira Suite Utilities (JSU) / Jira Miscellaneous Workflow Extension (JMWE) / Scriptrunner are apps available in the Atlassian Marketplace that may be used in one or more of your current workflows. While these apps have helped to drive the creation of workflows and processes to automate certain transitions or enforce proper data collection, there is also no current migration pathway to Atlassian Cloud. While JSU has become part of the native cloud, JSU along with the other two apps must be manually fixed in all workflows migrated up to the cloud. You must run a query on your on premise data base to ensure you map out all transitions affected by the apps. Then once the migration to cloud is complete, they must be reviewed and recreated manually to ensure they are all working properly. Where possible utilizing the out of the box options, that mimic JSU, can help to move away from at least one app. 

Specific to Scriptrunner, one common scenario is the use of it in filters can cause them to no longer function, potentially causing boards and dashboard to render incorrectly. These filters must be rewritten using the Scriptrunner Enhanced Search functionality. One good example is any filter that contains the phrase "issueFunction not in" will need be rewritten as "NOT issueFunction in". It would be advisable, when doing the migration to Cloud, to open a ticket with the vendors for advise on how to fix scenarios with JQL that worked in Server/Data Center that no longer work "as-is" in Cloud.

Overall these key obstacles will get you on the correct path to understanding what you know will need to be done in preparation for starting the migration. This by no means is a complete list of the only obstacles that you can encounter, but we hope it will help you to be proactive in fixing obstacles before they become a blocker to the migration.

We are Atlassian experts, and understand how the move to cloud can be fraught with unpleasant surprises. If you have any questions, or are in need of professional assistance, contact us, we would love to help!

Topics: atlassian blog automation best-practices migrations atlassian-cloud marketplace-apps jira-service-management cloud migration
5 min read

3 Tips for Atlassian Cloud Migration

By Bryan Robison on May 7, 2019 10:39:00 AM

It’s no surprise that Atlassian Confluence has become a mission critical application for your customers and support teams alike. You may find yourself in one of these scenarios:

  • Your company has recently acquired another company (with its own Confluence instance) and you’d like to combine the two

  • You’re using Confluence Cloud and have decided to make the switch to Server in order to leverage a particular add-on

  • You just had a successful product launch

  • People are simply adopting it in droves

Whether it’s making the move from Cloud to Server, consolidating two or more instances, or upgrading your instance to Confluence Data Center, migrating and consolidating Confluence may seem like a daunting task. However, migrating can be stress-free by creating an action plan that includes choosing the right strategy, focusing on the different versions of instances and add-ons, and relentlessly testing for errors. Here are 3 simple tips that will ensure that you have a successful Confluence migration.

Tip 1: Choose a Migration Strategy

Confluence instances come in all shapes and sizes and the particulars of your instance(s) can help you choose an effective Migration Strategy. Here are three examples:

Single Cloud Site to a NEW Server/Data Center instance

Export your Cloud site to XML using the backup manager and restore onto the latest version of Confluence Server following Atlassian’s instructions. Please note, in most cases add-on data will not be migrated as part of the XML backup so check with your add-on vendor to determine if they provide any type of data migration assistance.

Complete Server/Data Center instance to an NEW Confluence Cloud Site

The instructions are similar to migrating from Cloud to Server but in the reverse. There are more restrictions on moving from Server to Cloud, the most important is that your XML backup file must be smaller than 200MB. Consult your version matrix to determine add-on availability and compatibility. See Atlassian’s detailed instructions for migrating from Server to Cloud.

Restoring a Confluence Site from XML will overwrite any existing data. If you need to preserve data in your Confluence see the instructions below for migrating to an existing instance.

Confluence Cloud/Server Site to an EXISTING Confluence Instance

To migrate a spaces or spaces from one site into another existing site you have to use the Space Export method rather than backup/restore. This method can be a bit labor intensive as it involves exporting and importing one space at a time. Again, consult your version matrix for any incompatibilities between Confluence or add-on versions.

Users and content permissions will not be migrated using the Space Export method and will have to be recreated in the target instance.

If you’re migrating Jira at the same time, migrate the Jira project first to ensure that macros are updated to the new Jira location.

Tip 2: Create a Version Matrix

Each Confluence instance is different. When you’re changing platforms or consolidating instances you need to carefully review the differences between Confluence and add-on versions, determine whether upgrades are necessary, and identify any “gotchas” prior to starting your migration. A simple version matrix like the one below is an easy way to quickly identify those items you need to pay special attention to.

Product

Source Version

Target Version

Notes

Confluence

6.4

6.8

  • PostgreSQL 9.2 is no longer supported

Secure Content

2.0.3.1

2.2.0.1

  • Required for 6.8 Compatibility

  • Administrators can reassign ownership to any user

  • Improved Reporting Macro

  • Contact SCB owners with custom messages

  • Secure content blocks look better exported to PDFs

  • Improve performance and UI of secure content admin screen

  • Added Autocomplete in Macro editor key field to help locate pre-existing keys

DocuSign for Confluence

1.1.4.1-GA-6.1

1.1.5

  • Improved tabular output for Envelope List Macro

  • Multi-Select status for Envelope List Macro

  • Confluence 6.6 compatibility

 

Tip 3: Test, Test, Test

Testing is a key component of every successful Confluence migration and consolidation. There are a few areas you should review in your test instance (you do have a test instance right?)  prior to performing your production migration:

Content Formatting

The version of Confluence and Space Theme you choose can sometimes alter the formatting of content when you change instances. Carefully review and compare different page types to ensure that they render correctly and pay special attention to any pages that utilize Space or Global Templates and Blueprints. If you have Space Blueprints in your source instance, make sure they are migrated along with your content to your target instance.

Add-on Functionality

Add-ons can differ between versions and platforms so make sure that you review the usage of add-ons that may be incompatible and consider altering the content in your Source instance prior to migration or consolidation. Also note that add-on data is not often migrated when exporting content from Confluence. Consult your add-on’s documentation and contact the vendor for special assistance.

Space Permissions and Page Restrictions

We discussed earlier that users and content permissions will not be migrated using the Space Export method. Ensure that users and groups exist in the target instance prior to importing your Space and the Space Permissions after import. Page Restrictions will automatically be applied once the groups are in the target instance.

Application Links and Integration Points

Remember to migrate any associated Jira projects prior to migrating Confluence. Test your Jira macro links in the source instance to ensure that they are pointing to the correct Confluence instance. If you’re migrating a complete instance from one platform to another, make sure you update the application links between all of your Atlassian applications. Don’t forget to update any 3rd-party integrations you may have in place and notify any teams who may be accessing content or data through the Confluence REST API that the URL will be changing.

Successful Migration

Needs change over time, and migration and consolidation of Confluence instances can become a stressful endeavor. By following these tips you’ll have some tools to ensure success and keep your teams, users and customers happy. Visit Atlassian Cloud Migration's page here.

Topics: atlassian blog confluence migrations tips cloud cloud migration

Praecipio Consulting is an Atlassian Platinum Partner

This means that we have the most experience working with Atlassian tools and have insight into new products, features, and beta testing. Through our profound knowledge of Atlassian environments and their intricacies, we can guide your organization as you navigate these important changes.

atlassian-platinum-solution-partner-enterprise

In need of professional assistance?

WE'VE GOT YOUR BACK

Contact Us