While there are various ways of placing applications in the cloud, you should consider migration criteria for each project to determine the best choices for your company. One example is applying migration criteria to SAP Business ByDesign, which SAP has marketed to small and medium-sized businesses, as well as subsidiaries of large companies. It provides BlackBerry, iPhone, and iPad support and serves as the underlying platform for on-demand applications that an enterprise of any size could use. If a company does not have SAP Business ByDesign, it can apply these migration criteria to other applications it wants to place in the cloud.

You can use the following five key migration criteria:

1. Data storage and locations
2. Upgrade and maintenance schedules
3. Legal issues and requirements
4. Scalability issues
5. Service level agreements

All these criteria are important items that members of the application development team including developers, programmers, database administrators, and functional specialists should ask the cloud subscriber before entering into any agreement with a provider.

1. Data Storage and Locations

As part of a migration assessment, a potential cloud subscriber should determine how much it is willing to pay for the costs of bandwidth charging and storing the data by the month. It should compare whether the costs of cloud storage would be cheaper than the costs of storing data in a physical server at an internal data center at the company’s own internal data center.

The company needs to determine the type of data it wants to store in the cloud: backup data, archive data, or primary storage. Cloud storage can be expensive, particularly for very large quantities of data, primarily due to frequent movement of data to and from the cloud storage over the bandwidth. It costs more to move the data over the bandwidth rather than send it directly to storage devices (e.g., a CD) connected to a laptop or a desktop computer. If the data size is very large, it would take a longer time to travel over the bandwidth and more money.

If data is no longer actively used but still important and necessary for future reference, it should be archived on separate data storage for long-term retention. When planning a cloud migration, consider data retention policies including those for on-demand applications. The provider must ensure data is not retained any longer than is truly needed. Any data that has reached the retention expiration date should be purged from the cloud storage for primary storage, moved to cloud storage for archived or backup data, or transferred to physical tape storage.

It’s always cheaper to store data in a public cloud than in a private cloud. With a public cloud, you may not know where the locations are, making it very difficult to retrieve data and manage data retention policies. With a private cloud, you may know where the locations of cloud storage are. This is one of the key reasons why SAP runs SAP Business ByDesign on its own private cloud, and not on Amazon’s EC2 cloud, where it runs SAP Carbon Impact, which is less mission critical.

Always query an SAP-certified cloud provider if it is providing its own private clouds for storage or if it is using Amazon Simple Storage Service (S3) to store backups in Amazon Virtual Private Cloud (Amazon VPC). Amazon VPC lets you provision a private, isolated section of Amazon Web Services (AWS). Amazon VPC can span multiple availability zones within and across the regions to protect SAP systems from failure at a single location. This is done by launching instances in each availability zone, so that when one availability zone fails, the other zone within the same region can take over. Currently seven regions are available: US East (Northern Virginia), US West (Oregon), US West (Northern California), EU (Ireland), Asia Pacific (Singapore), Asia Pacific (Tokyo), and AWS GovCloud.

2. Upgrade and Maintenance Schedules

Cloud providers need to update or upgrade their systems from time to time to install the latest patches and new features. If you build on-demand applications using SAP Business ByDesign, for example, you need to be aware of when these patches take place so the applications won’t be adversely affected after the upgrade.  

Cloud providers can decide when the upgrade takes place. To ensure service availability will continue, the vendor should provide cloud subscribers and application developers with two types of environments: testing and production. That way, if any issues arise, they can be worked out in the testing environment without affecting the production system.

Another consideration is that a cloud provider often schedules planned downtime of cloud services to perform maintenance. To prevent excessive outages for users, the company itself, if it so desires, should schedule its own application maintenance in tandem with the maintenance schedule of the cloud provider. Any on-demand applications that you develop with the Software Development Kit (SDK) must be maintained often so they behave correctly on the cloud when the hardware and software infrastructure underlying the cloud services are upgraded.

3. Legal Issues and Requirements

Data protection or other acts may prevent the placement of data in certain locations and allow it in other locations. For example, French law prevents clinical trial data from being transferred to locations in other countries, even within Europe. Rules on intellectual property of any data that is transmitted to a cloud service vary widely from one country to another. A country may not protect your data because it does not consider the data as intellectual property.

The cloud provider may grant some privileged third parties access to cloud users’ stored data. The identity of such parties, if any, must be disclosed to the potential users. Here, the third party could be a legal authority or even an internal employee. The customer should always be informed before the cloud provider allows third parties to access the stored data.

4. Scalability Issues

Traditional applications are designed for traditional hardware configuration in an in-house data center. Cloud service applications are designed for use in the cloud. A company should not put traditional applications on the cloud that are not designed especially for the cloud.

To work like a cloud service application, the behavior in a traditional application may need to be changed. Behavioral changes should be tested to make sure the application can be put on the cloud. If the tests show negative results, consider a different approach to changing the behavior of the application. When changing the behavior of an in-house application, you may be able to use some portions of the application as code inputs to a new on-demand application using SAP Business ByDesign as its platform.

The provider must install applications and place them behind load balancers within the cloud to be scaled up and down on demand. The provider then needs to test if the third-party balancing tool chosen by the consumer works well with the cloud service. Most scaling and balancing solutions provided by the third-party tool or the provider incur some additional expense.

Once the application is behind a load balancer in the cloud, the application itself needs to be tested by the provider to see if it can be interfaced with the load balancer. If the test shows positive results of interfacing, then you can say the application is aware of the load balancer.

If the test shows that the application is not aware of the load balancer, developers need to determine if the problem is due to:

• The third-party tool’s incompatibility with the provider’s load balancer
• The third-party tool’s performance issues in the provider’s cloud service
• Coding issues in the application that was installed

If the problem is due to load-balancer incompatibility or performance issues, the user should opt for another third-party tool that is compatible with the provider’s cloud service. If the problem is due to coding issues, the application may need to be redesigned.

Load balancers alone may not be sufficient to handle spikes in workload demands from multiple users. You may need to supplement load balancers with resource and response thresholds that you should include in the application or as part of the system. Resource thresholds should be set to show the maximum number of resource instances that can be consumed by multiple users or applications at a given time.

If a resource threshold is not set, a load balancer may not know if it has exceeded the maximum number of resource instances for consumption. As the threshold approaches the maximum, a resource threshold alert should be sent to the system administrator about potential problems with resources.

Response thresholds should be set to show the fastest response time to a consumer’s queries from their mobile devices. If the response threshold is not set, the load balancer may not know if it is slowing down the response time the consumer expects to receive. As the resource threshold approaches the maximum allowable slower response time, a response threshold alert should be sent to the system administrator about potential problems with response times.

5. Service Level Agreements

The potential cloud subscriber should be encouraged to ask the provider about what terms are included in a Service Level Agreement (SLA). The SLA should contain a list of services the provider will deliver, metrics to determine whether the provider is delivering the service as promised, and remedies if the provider does not live up to its claims on service availability guarantees. The SLA should indicate what remedies are available: refunds, credits, and free service for a period of time.

Cloud subscribers most likely would opt for an SLA that they can negotiate with the provider, particularly on the level of service availability (e.g., 99.3 or 99.995 percent). They should negotiate with the provider what the agreement exceptions are, such as planned maintenance downtime and accidental cutting off of optical fibers.

Particular attention should be paid to the processes in place in case of collapse or takeover of an SAP-certified cloud provider. For this reason, it is important to take a look at the provider’s backup plans and policies and whether the format the current provider is using in backing up the data and application can be used with a different SAP-certified cloud provider.

The SLA should be tied in with a disaster recovery plan in case of the loss of the provider’s data center that underlies the cloud infrastructure. Find out whether the disaster recovery plan recovers the contents of the virtual servers of applications and data or only recovers the base operating systems.