Ten Things to Think About When Moving to the Cloud

Moving applications to the cloud can bring great benefits to your organization and increase the flexibility and responsiveness of your IT department. However, when making this move, there are lots of issues to think about. For example, how secure is my data in the cloud? How reliable is the cloud-based application? What is the actual cost? How can I migrate my existing data to the cloud? And so on.

In this post, we’ll discuss some of these issues and look at the questions that you should ask before you make the move to the cloud. This list is not intended to be exhaustive and, depending upon your particular circumstances, some of these things might not apply – or there might be other things that you need to add to the list.

1.       Objectives/Goals

What are the goals and objectives of moving to cloud? Is it to reduce costs, or reduce time-to-deployment, or free up IT resources for other tasks? If you don’t know what your goals are, then how do you know whether moving to the cloud has been successful or not? If you don’t know your goals, then why are you moving to the cloud at all – just because it seems like a cool idea?

List your goals and objectives, prioritize them, and quantify them. This will give you a measuring stick to determine if the Cloud is successful for you.

2.       Security

Security is important – whether it is securing data stored in the cloud (“data at rest”) or data moving between cloud apps and on-premise apps (“data in motion”). Security breaches can be very embarrassing and can lead to financial loss (and regulatory penalties if the breach affects data covered by privacy laws).

Wherever the data is stored or in motion, it is your data and therefore your responsibility to ensure that it is secure and protected. Just because your app is in the cloud and supplied to you by a cloud provider does not absolve you of responsibility for the security of your data. You need to make sure that your cloud provider is securing and protecting the data on your behalf, whether the data is at rest or in motion.

So you should ask your cloud application provider how they secure your data in the cloud. Do they encrypt the data? What about when the data is in motion? How is it protected then? How do they protect the application against security breaches? Do they perform threat analysis and penetration testing of the application? Are they willing to discuss the results with you? The answers to these types of questions will give you an understanding of whether your application provider is securing and protecting your valuable data.

3.       Reliability

Make sure that the cloud application reliability (as defined in your SLA) matches your needs. If your cloud application is, say, an HR application, then having 12x5 availability is probably going to be OK. But what if the application is a part of a mission critical business process that needs to be available 24x7? Or what if the application must have guaranteed availability and reliability at certain times of the day e.g. at the close of trading for financial applications or at closing time for retail applications (for end of day processing, in both cases)?

Check that your cloud application SLA meets your particular requirements with regards to reliability and availability – don’t just assume that, because the application is in the cloud, it’s always available. Ask your cloud provider how they provide the reliability and availability – do they have load balancing and a high availability architecture in the cloud? Or are there points of failure that could halt the whole application?

4.       Disaster recovery

Disaster Recovery (DR) is somewhat related to reliability and availability, but in a slightly different context. DR covers the situation where there is a total failure of the data center where your cloud application is running. This has happened recently when Amazon lost power to one of their data centers in Virginia due to an electrical storm in the U.S. Mid-Atlantic region. This power outage affected services such as Netflix, Instagram, and Pinterest – albeit only for a few hours. Last year, a transformer failure knocked out the power to Amazon and Microsoft data centers in Dublin, Ireland. It took up to 2 days to restore some of the services running in these data centers.

How would you be able to withstand a loss of your cloud application for an extended period of time? How would this affect your ability to do business? If your cloud application is important, then look for a cloud provider that offers a DR capability. You will almost certainly have to pay for this functionality, but it will be worth it if it prevents extended application outages.

Ask your cloud provider how they support DR e.g. is the DR application located in a physically different data center to protect against problems such has power outages or natural disasters? What is the replication strategy between the ‘live’ data center and the backup (DR) data center? How frequently is the data replicated? How long of an outage at the live data center is required before triggering the DR application to start up? How long does it take for the DR application to start up? What is the recovery strategy for interrupted processes and transactions?

The answers to these questions will help you to determine whether the cloud provider’s DR capability is suitable for your needs.

5.       Cloud operations – who is monitoring your application?

When you use a cloud application, you are effectively outsourcing some of the administration and monitoring of the application to a third party i.e. your cloud provider. You need to understand what application and system health metrics the cloud provider is monitoring on your behalf. You need to make sure that they are monitoring enough metrics to catch problems as soon as possible – preferably before they affect the performance or availability of the cloud application. Items to be monitored by the cloud provider should include:

• CPU Thresholds
• Load balancing functionality
• Disk utilization and volume capacity
• Database metrics, e.g. utilization, I/O, etc.
• Application specific metrics, e.g. listening ports, process pid’s, etc.
• URL availability for user interface access
• Security attacks:
•  Denial of service attacks
•  Brute force attacks
•  Illegal log-in attempts
•  Unauthorized file access, e.g., non-root user attempting access to host files
•  Virus scanning

These metrics – and alerts based on metric thresholds – should provide suitable information about whether the application is running or not and whether anything abnormal has occurred (e.g. a runaway application consuming all CPU cycles). However, system or application level metrics and alerts don’t tell you whether the application is performing as promised. If application performance – whether response time, throughput, etc. – is important, then you need to ask your cloud provider about mechanisms to monitor performance. For example, this could be sending a test transaction through the application on a periodic basis to measure the processing time or response time for the transaction. If they don’t have any such mechanism or process, then how do you know whether your application is meeting your performance criteria?

6.       Self-serve dashboards

Although moving an application to the cloud means that someone else will be monitoring the health of your application, it doesn’t completely absolve you of all of that responsibility. After all, if something goes wrong with the cloud application, the users within your organization won’t be able to contact the cloud provider to find out what’s happening – they’ll need someone within the organization who can tell them what’s going on.

This means that your cloud application will need some type of self-service dashboard which can provide a view on to the application and its health. Using the dashboard, you will be able to notify your users if there are any problems, such as slow performance, the application being unavailable, etc. This, in turn, will result in a better user experience as they will be informed about problems rather than just staring at a blank screen.

7.       Transparent pricing

Before you sign up for any cloud-based application make sure that you fully understand the pricing model. This sounds obvious but often people are caught unaware by ‘hidden charges’ that were not fully explained before they signed up.

For example, if your cloud application costs are based on a ‘per user’ subscription is this concurrent users or named users? What is the cost of adding more users? How easy is it to add more users?

If your application costs are based on throughput or transactions, what is the cost of going over your quota or limits? Are there ‘overage’ charges (similar to cell phone plans)? Or are you automatically bumped up to a higher quota plan with a higher subscription cost? Is there a grace period if this is a one-off occurrence? Or are the additional fees (overage or plan upgrade) automatic?

Also consider the commitment period for your subscription. If this is month-by-month with no lock in, then this is not going to be a problem. However, if you pay for a year’s subscription in advance, what happens if you decide to cancel before the year is up? Do you get a refund for the unused portion of your annual subscription?

The answers to these questions might not affect your decision to use a particular cloud application, but you should at least be aware of the costs before you sign up, so that you’re not hit with unexpected fees when it’s too late to change.

8.       Migration

Unless you are starting from scratch with a brand new application, the chances are that you’ll have some existing data that you want to convert and migrate to your new cloud application. You’ll need to understand what bulk data import capabilities are provided with your application. Most applications offer some form of data import capability and they are usually fairly easy and straightforward to use.

However, you shouldn’t underestimate the amount of effort involved in migrating your data to the cloud. The data import mechanisms usually require that your data is in a certain format before it can be imported, so you will need extract and convert your existing data to match the import format. You should also take this opportunity to cleanse and refresh the data before you import it into the cloud application. If you’re importing CRM data, this is a good chance to go through the data and refresh any old and old-of-date customer information or delete any obsolete product or pricing data. If you need to enhance or extend the data, e.g. by merging in data from another source, now is a good time to do this.

Migration should also include the training users on the new application and planning their switch over to the cloud. Is this going to be a ‘big bang’ approach where everyone will move to the new application at the same time and any old applications will be switched off? Or will you have a phased approach to moving user to the new cloud application? Both approaches have pros and cons and you need to decide upon your approach to this.

9.       Integration

While using applications in the cloud can bring great benefits to your organization, you won’t truly realize those benefits until you integrate your cloud application with your existing applications and business processes. If you don’t do this then you get application silos that result in fragmented business processes with too many manual steps or data duplication and data rekeying. If you consider a basic application, such as an HR application, even this needs to be integrated to other applications, such as your talent management application, your IT systems for provisioning of email accounts and system logins, etc. Additionally, your HR application is just one part of your new employee on-boarding business process, so your HR application needs to be integrated into the process flows for on-boarding your new employees.

When planning to integrate your new cloud applications with your existing applications and business processes, you need to consider how you access the data and functionality of the new application. Is this via an API? If so, what standards and formats does the API use? The most common cloud application APIs are Web Services based, but do they support SOAP/XML or REST protocols? If the cloud application has a ‘batch’ import/export interface, what sort of data format does it support (e.g. XML, CSV, or JSON)? Are these protocols and formats compatible with your existing applications? Do you have in-house knowledge of the protocols and formats?

Answering these types of questions will help you to prepare the integration of your new cloud application to your existing applications and processes.

10.   Managed Services

Last but not least, we have managed services. Cloud providers are increasingly complementing their cloud-based applications with managed services offerings to help you to get the best out of the application. These managed services can range from offerings to get you started quickly, such as migration services or ‘quick start’ services, all the way through to managing the full solution on your behalf. These managed services can complement the skills and expertise that you have in-house and make it easier to get value from your new application.

Managed services are also a good way to free the IT staff from the routine tasks of managing and administering the cloud application. Hopefully, with the time freed up they can focus on more valuable work for the organization. Ask your cloud provider about any managed services that they offer. If these are of interest, find out about the scope of the services – exactly what does the cloud provider do? And what is still left for you to do? For example, if you are using a full managed service to run and administer the cloud application on your behalf, are there any limits on the work provided? Is it based on hours of effort? Or number of tasks? Or will they do anything requested? How do you request work to be done such as adding a new user to the application)? How long does it take before they perform the requested work? How can you get urgent work performed as a priority task e.g. if your CEO wants a report immediately?

This type of information should be supplied, by your cloud application provider, as a definition of the scope of a particular managed service offering. Make sure that you understand what you are getting before you sign up for a managed service for your new application.

So there it is – ten things to think about when moving to the cloud. As I said earlier, this list is not exhaustive. Your particular circumstances might add new things to the list and make some of the above things irrelevant. However, if you use this list as a starting point, you will be able to ask the right questions to your cloud providers and your move to the cloud will be from a perspective of knowledge and understanding the challenges, and not from one of blind optimism and hope.