How to migrate data and applications in the cloud

Although there are many reasons and benefits to migrating to a managed datacenter facility, the process is fraught with risks. Previously, we needed a "Plan B" when we needed to end a failed partnership with a data center or cloud service provider, or the service provider itself failed.

Our suggestion is that IT managers should ensure that the ownership of the data in the contract between their enterprise and the cloud service provider is owned by the enterprise. However, this is only part of the problem and we still have the problem of how to deal with the data afterwards.

The final response is "This depends on concrete analysis of specific issues". The first question is the data created around the application: Can you still get access to the same application elsewhere?

If the existing protocol is an infrastructure, a service (IaaS) or a platform as a service (PaaS), your enterprise will have to have its own application anyway, so installing such an application on a different cloud platform should not be an issue of excessive installation.

The difficulty of moving data in the cloud

However, in the case of software as a service (SaaS), there are likely to be larger problems. If the service provided is based on a standard application. For example, SugarCRM or OPENERP, you might need to find another service provider hosting the same application. May vary in execution, but all that is needed is a pull/transform/load (ETL) action to ensure that the data fits into the new service provider architecture.

IT managers should keep in mind that any changes to the application made by their previous service providers (such as ripping out logo tags or adding any additional features and applications) will need to be renewed by the new vendor.

In many cases, it is not possible to get any detailed change lists from previous service providers, so redeploying these will be the hardest part of the transition process. This means that any changes made by previous service providers, even in the SaaS environment, must be documented and stored outside of the SaaS environment. A complete set of service vendor change logs is necessary so that if your business is replacing a service provider, it can be deployed again.

The real problem is when a company is migrating from a proprietary software vendor. This could be some major modification of an open source application by the vendor, making it fundamentally a new application. Alternatively, it may be an application owned by a SaaS provider, but not allowed to run on its own platform by any other cloud provider, such as Salesforce.com.

However, while Salesforce.com is unlikely to encounter Waterloo soon, some of the smaller dedicated SaaS providers are doomed to fail.

Quocirca suggests that your business should consider the risks involved at the beginning of choosing a SaaS provider. If your business is not ready to use software as a service, then you should make sure that you assess the risk of your chosen provider's failure, and what effort you will need if you need to extract system data from your service provider and require it to be in a form that is available in some other system for a short period of time.

SaaS Data Recovery Planning

Organizations that have moved data to a SaaS provider should ensure that a B-plan knows where to get a known recovery-point objective (RPO) and a known recovery-time objective (RTO).

The first thing to determine is what the target application is. Quocirca suggests that this should be a widely used application in SaaS providers, or that applications come from a very large SaaS provider with many proprietary economic security capabilities.

The second thing to determine is the system architecture used by both systems. Matching field names and types is necessary to ensure information fidelity during data migration. This will also define the extraction/conversion/loading activity to be performed.

Then, it is necessary to test. The normal operation of the above activities can not be simply to stay in the hypothetical or expected phase. You need to test it to move the data from the existing environment to the new environment. This does not have to be a migration to a second service provider, but just testing to make sure it works.

Based on successful testing, you can create a complete, formal plan for your business to respond to when the worst-case scenario occurs. This should also include how long it takes to start the activity plan and how the business will continue to operate during this downtime. This may involve manual processes in which any data collected during these manual processes will need to be entered into the new system.

Finally, it should be ensured that the contract stipulates that the old service provider must remove data from your business from its system, which is often overlooked.

(Responsible editor: Fumingli)