Moving to the Cloud? Did you do your Homework?

We come across so much cloud-related stuff these days that sometimes it feels like winter in Seattle. Most of the time, the reasons that marketing campaigns like to convince C-Level executives around the globe to move their technological platform to a cloud-based solution are mainly business related, for example:

  • Low upfront investment.
  • Easy scalability.
  • Low or non-existing infrastructure maintenance costs.

These are all valid reasons, however, as many things in life, it is never that simple. Unless you can borrow a working crystal ball from a credible fortune teller, the homework decision makers have to do is quite extensive. There are many considerations that need to be weighed for each specific case, to mention a few:

Security. Depending on the characteristics of your application you need to select a provider, and a type of cloud-solution, that meets your security requirements. For example, hosting an application that handles financial and credit card information has different requirements than hosting a website to share cooking recipes, no matter how good your cookies are.

Access. Not all providers give you the same tools or types of accesses to your code and data in the cloud. If you have and application that requires a high degree of customization or interconnectivity you want to make sure you will have the proper ways to support these features.

Compliance. If your software operates within the space of highly regulated industries, it is likely that the hosting environment you select needs to be compliant with one or more of their very specific requirements. If you are familiar with PCI, HIPPA, SOX, or some other of those ugly acronyms, you know what I’m talking about.

Long term deal. Even though the monthly fee you pay for 100 users may sound enticing, you have to do your math and see if it looks equally as attractive as when you have 1,000, or 10,000, or 100,000 users. Then, compare this to the investment in an on-premises solution where the cost will be high at first, but dilutes as the customer base grows.

This is without expanding on topics like performance, support, uptime, SLAs, user training, and many others.

However, let’s say you went through the exercise and, at the end, you decided to move to the cloud. Also, let’s say that, after hours and hours of research and due diligence you were able to select the right cloud provider for you. Now what?

Here is where the technical team has to work its magic and make it happen.

For the purpose of this discussion let’s assume that we are talking about an existing, average complexity, multi-layer, web application that we want to migrate to the cloud. These are some of the activities or practices that are highly recommended for this journey:

Architecture mapping. If you don’t have these already (which is the most common case), create updated versions of:

  • Network and infrastructure diagrams.
  • List of classes, objects, libraries, packages, API’s, etc., used in your code, organized by layers.
  • Entity-Relationship diagrams of all databases.
  • Recent history of builds and branches.
  • Screenshots of all user interfaces.
  • Application workflows.
  • List of third party controls, including versions and vendors.
  • List of internal and external web services.

Plus, anything else that helps you have a detailed picture of all the components of your application and how they interact.

Authentication method review. If your application has been using a local network-based method to authenticate users, like Active Directory, it is possible that when you take your application outside of your premises you may encounter some challenges to keep it the same way. It may be a good time to consider an authentication method that is either database or web-service driven.

Regression testing. The more complex your application is, the higher the chances are of running into errors and unexpected behaviors caused by the migration to a different environment.  The best way to make sure that your software will work as it did before is to run a good battery of regression tests. If you have been diligently creating test cases, along with your software development efforts, it will be relatively simple. If not, it wouldn’t be a bad investment to generate them, either for manual testing or using automated scripts; the more the better.

Creating a migration plan. It is not always possible to move all your application, and its components, at once. In addition, if you don’t like the idea of an angry mob of users knocking at your door because they cannot access your software, it is advisable to have a detailed Migration Plan. A plan where you can describe the order in which every component can be safely moved and stabilized in order to minimize downtime. You can also go with the approach of creating a replica of the application in the cloud, test it and then do the switch. In this case, the switching part will become the focus of your plan.

Keep in mind that when you migrate an application to the cloud it would commonly take several cycles of:

  1. Testing
  2. Bug fixing.
  3. Rinse and repeat

Allocating enough time in the plans for these activities helps substantially to set the right expectations for those who are waiting for you to tell them that you have successfully moved to your new home.

If you would like to talk more about our outsource software development teams please contact me at vhmartinez@tiempodev.com, or get in touch with Tiempo at contact@tiempodev.com. Feel free to connect with me on LinkedIn. You might also find our case studies and other services interesting.

YouTube video