The ‘how’ of cloud migration

Before discussing the details involved in moving to a cloud environment it is worth making a few introductory comments on the subject itself. To begin with, there are three primary scenarios that involve cloud adoption:

• You want to use the cloud as a platform to host one or more databases in which you will store corporate data, which has to be moved from one or more on-premise databases to the cloud.
• As above but this is a new deployment (for example, you are implementing Hadoop in the cloud): whereby you will be loading data into the cloud but you will not be migrating from an existing environment.
• You want to use the cloud as a platform for hosting one or more technologies, for example, application development, data preparation, data cleansing and so on, which do not actually involve storing data in the cloud or moving data into the cloud.
• You are adopting one or more SaaS (software as a service) applications that run in the cloud, such as Salesforce.com, Marketo, Workday.

Before discussing the issues arising from any move to the cloud in detail, it will be as well to outline them briefly, and where they apply, as not all topics will be relevant to all readers. In summary, therefore, the issues are:

1. Moving your data into the cloud, when this is a green-field deployment.
2. Migrating your data to the cloud, when this is a replacement for an existing application or solution.
3. In the case of a migration do you want to move all of your existing information into the cloud? And, if not, what do you do with the remainder?
4. Similarly, what do you do with your old applications?
5. How do you integrate your new cloud-based deployments with other applications that remain on-premise?
6. How do you integrate your cloud-based solutions with other cloud-based applications and data sources?
7. Compliance, security and data governance.

My recent Spotlight provides a list of Best Practices for conducting migration, covering such areas as the separation of projects, data profiling, the use of tools and gaining business engagement in the process.

It also covers the important area of application retirement and archiving. This is, as Howard, observes, an important issue infused as much with emotion as with logic. ‘When you replace an existing in-house application with a SaaS application we can assume that you then intend to retire the pre-existing application. This is all the more the case if several applications are to be replaced during the same project. However, users are often reluctant to agree to turn off old applications that have been known and loved (a bit like an old sweater!) for many years.’

Another important migration issue is data integration, for the cloud holds out the possibility for disparate applications to collaborate to create functionally rich, highly focused services for users. He identifies three main options for achieving this, using APIs, using the canonical form of data as an intermediary tool between the source and target data forms, and using – or using software development kits to build your own – connectors between source and target applications. In each case he outlines the benefits and pitfalls.

Lastly, the paper covers the compliance, security and data governance issues that go with the actual work of migrating applications and workloads into the cloud. This does include some ‘good stuff’, such as on-demand access to server capacity, scalability of that capacity as required, and the payment for resources only as they are consumed, rather than upfront whether they end up being required or not.