The four virtues of cloud migration

In March 2021 our colleagues discussed ‘7 deadly sins of cloud transformation' in our DevOps Sauna podcast. Lots of tickets have passed through the workflows since their initial session and we would like to revisit the topic from a new angle: The four cardinal virtues of cloud migration.

The original podcast explored what are the cardinal sins that can turn a cloud migration project into a project the likes of which are found on the pages of Dante’s Inferno. We find that most of the original analysis still holds true: indeed, the Seven deadly sins still plague cloud transformation projects. But we find that even for the sinners there ought to be hope of salvation - or at least the proverbial silver lining on the cloud.

It is for this purpose that we offer our Four Virtues of Cloud Migration. For we believe that it is not by avoiding sins, but by actively cultivating our virtues that we can better succeed in life.

The cardinal virtues, as they were originally conceived by Plato in his Republic, were Prudence, Fortitude, Justice and Temperance. In this post we take it upon ourselves to map the original Seven Deadly Sins of Cloud Transformations to their counterparts in our Four Virtues of Cloud Migration. 

Virtue #1: Temperance (Modesty)

Associated with Pride, Gluttony, Lust, and Greed

Some migrations are large projects and others are small, but what they have in common is their nemesis: the scope creep. In the original this was discussed under the sin of Greed: wanting to achieve too much at a single time.

A cloud migration project should have a fairly clearly defined scope: migrate the agreed upon data and functionalities from your server/DC instance to the Cloud and perhaps implement Atlassian Access to enable SSO. Occasionally this might require some re-implementation of some applications as not all the apps are available in the Cloud. But this is all very foreseeable. 

Problems arise, however, when temperance is not applied to the project: instead of porting your current data and functionalities to the Cloud some new functionalities or integrations get added to the project’s scope. It might seem like a simple addition to the bill of items at the moment, but most likely will come haunting you later in the form of blown deadlines and budgets.

Our recommendations

We counsel temperance in setting your migration project’s scope. Stick to the initial scope and don’t unduly add anything to it. Keep your concerns separate. The target of a migration is to get you to the Cloud, adding new functionalities or integrations is a separate concern and as such should be addressed within a separate framework.

Under the heading of Temperance falls also a question related to Pride. In the original podcast the issue of pride was described as sticking to what you have and know now and saying a firm ‘no’ to an outsider’s opinion.

Here we counsel you to apply temperance over your pride. Rest assured, we have absolutely no doubt about your knowledge of your product, requirements and business needs. However, the transition to Cloud is not a 1:1 process: some functionality will be different and some applications will not be available and some work-arounds are required and for some things there might be other, better ways of doing things. So lend us your ear and keep an open mind. Our Atlassian experts have a vast knowledge not only of the Atlassian products but also of the rich ecosystem surrounding them. There might be an application that will replace some of the functionality lost in transition or there might even be an application that can replace some previous workarounds and help you get more out of your tools. Let us help you excel - that’s what we’re here for.

Virtue #2 Fortitude / Patience

Associated with Wrath, Envy and Sloth
“Patience, my friend, patience! You will find in time that it has everything to do with it” - Arthur Conan Doyle. A quote that is applicable almost everywhere, and cloud migrations are no exceptions.

Virtue #3 Justice / Responsibility / Ownership

Associated with Envy and Sloth

A common problem in cloud migrations is the lack of ownership with the server or DC version.

Usually this means that there is not a single person or a group of people who have been clearly designated as people who take ownership of their Atlassian products. With small to medium sized instances this might even work out pretty okay, but the inherent problems inevitably surface when the time for migration comes. Note, though, that the converse is also true: with a large instance there might be a too large and unorganized group of people who share the administrative tasks and nobody has control over how the tool is being used and what it contains and this, too, will lead to surfacing problems when the migration day comes. 

The problems are rather predictable: 

1. Nobody really knows how the product is being administered and how it is being used,
2. As a consequence there’s a lot of feet shuffling when it comes to making decisions about what to migrate and how it should be migrated
3. Nobody really knows what kind of data is stored in, for example, Jira tickets. 

From this arises the foreseeable problem of indecision: nobody really has the required knowledge, ownership and authority to say what needs to be migrated and how and the various stakeholders start to champion their particular interests. In a very classical case nobody really knows what’s stored in their Atlassian products and, as a consequence, decide to migrate literally everything - even over 10 years old projects and sandbox projects as nobody wants to be the person who flushes out data that might be needed one day. This, in turn, bloats the amount of data to be migrated, which means a more complex migration operation, which means more resources and time. And there’s a more serious implication here, too: there probably are no clear guidelines what kind of information should be stored and where it should be stored. Truly, what kind of data IS there in those tickets?

Our recommendations

Here we counsel to cultivate the virtue of ownership. Before the migration, take stock of the current situation of your Atlassian products and gather your stakeholders to equitably and clearly share the ownership of your tools. The past lack of ownership cannot be undone, but use the migration project as a chance not only to clean up, but also as a chance to level up. Simply getting over the migration hurdle just isn’t enough: the past problems will not magically disperse by migrating to the Cloud. Define in clear terms how the tool should be used and who has ownership over which parts of the tool and you will get the most out of your tools. 

Virtue #4 Prudence / Humility

Associated with Pride and Greed

It often happens that the Atlassian stack’s products are seen as auxiliary tools of everyday work. And that they are: tools to help you get your everyday work done in an orderly and efficient fashion. As such their migration is occasionally seen as a trivial project on the side of all the other work that needs to get done - preferably ASAP. 

However, even the migration of your auxiliary tools is a project not unlike other projects: it requires time and resources. If you approach your migration project without the due prudence (or humility) even a rather straightforward migration case can turn into a lagging project that ends up consuming far more time and resources than it should have in the first place. For example, a common mistake is to not factor UAT resourcing into the migration project. With large instances it is simply inconceivable that a couple of people can exhaustively test the migrated application in a reasonable amount of time and some problems will only emerge once the end-users start using the application in Cloud.

Another problem is the common nemesis of all projects: scope creep. The migrations are all about migrating your tools to the cloud environment with all their core functionalities intact. A migration project is hardly the place to introduce new major functionalities to your tools. In a worst case scenario the introduction of a completely new integration into the project completely sidetracks the project from its original framework and goals.

Then there is the question of pride. As pointed out in the original podcast, some believe that by the virtue of thoroughly knowing their server or DC instance, they also know all about the migration process and how the products will work in the Cloud environment. Admittedly, there is a grain of truth there. However, the migration project will have its own pitfalls and the Cloud environment is not 1:1 with the DC and Server versions. To point out an obvious difference: user management. The user management in server/DCand in the Cloud differs greatly (see here for details) - especially if you do the smart thing and take Atlassian Access.

Our recommendations

So, these are the sins that we have mapped to the virtue of Patience / Humility. But how to cultivate that virtue? We counsel you to have humility and prudence in approaching a migration project. Firstly, accept that the project will require time and effort. Trying to achieve your goals with insufficient resourcing will guarantee problems down the road. Second, don’t overreach - be prudent. Keep the scope of the migration project limited to migrating your tools and their core functionalities to the Cloud. Adding new functionalities can wait until the migration is done. 

Lastly, ask for help in planning and executing  the migration. Our experts have loads of experience with all possible migration scenarios and can help you to plan, resource and execute the migration process smoothly.

Conclusion: Virtuous Migration

So far we have covered the theme of cloud migrations in rather biblical terms, but do not let that intimidate you. For the sins and virtues are, after all, rather mundane and human in their nature. The real key component for a successful migration to the Cloud is to carefully plan out your migration process and to ask for help - preferably at the earliest possible stage. Our specialists have extensive knowledge on Cloud migrations and are more than happy to provide you anything from analysis to execution to help you smooth out your migration to the Cloud.