Nov 06, 2013 (04:11 AM EST)
Cloud Migrations: Don't Forget About The Data

Read the Original Article at InformationWeek

Top 10 Government IT Innovators Of 2013
Top 10 Government IT Innovators Of 2013
(click image for larger view)
Gartner research director Richard Watson once observed, "When the CIO issues the simple directive: 'Move some applications to the cloud,' architects face bewildering choices about how to do this, and their decision must consider an organization's requirements, evaluation criteria and architecture principles."

Unfortunately, many architects assume that migrating your legacy systems means migrating your applications to the cloud. However, the reality is that such a migration involves both data migration and application migration. Each of these must be assessed, planned, designed and executed separately and then integrated. They are two parts of the same migration of a legacy system, but each requires different analysis steps and different skill sets.

By focusing on your data migration separately from your application migration, you will ensure that both will scale properly.

It's worth noting that government agencies are taking the lead in this area. For example, the Department of Defense Cloud Computing Strategy calls for both metadata tagging and a data cloud that will implement "data-as-a-service" (DaaS). The creation of that requires separating the application from its data during the migration phase. This is the same strategy that the Intelligence Community is pursuing with its community cloud.

[ Want to learn more about DOD cloud plans? Read Defense Dept. Seeks $450 Million Cloud Builder. ]

The goal of both data and application migration to the cloud is to achieve scalability and elasticity. Your general migration model for analysis is to start with a clear understanding of the sources of the applications and data to be migrated, examine your options in achieving scalability, and then select the target implementation that achieves those objectives.

Focusing on the source for your data migration, you need to look at how your application currently stores its data. Typically that is in one of three ways: in a relational database management system (accessed via SQL), in a no-SQL data store, or in files on the file system. Your first assessment is whether your data needs to be scalable in terms of processing and storage space. For your target options the major cloud providers all offer SQL stores, no-SQL stores and BLOB (binary large objects) storage.

Data migration consists of three parts: the migration lifecycle on your data subsystem, the transfer of legacy data, and, finally, the integration with the rest of the migrated application. Let's examine each in more detail:

1. Data Migration Lifecycle

Similar to your systems development lifecycle (SDLC), the migration lifecycle begins with an assessment phase instead of a requirements phase. Additionally, the development phase is replaced by the migration phase. I explain this in greater detail in my new book, The Great Cloud Migration; for now, suffice it to say that data migration is assessed by cloud platform type, scalability requirements, data type or by data volume. At the end of the assessment you will have selected a target implementation that achieves your scalability and elasticity goals.

2. Transfer Of Legacy Data

Moving your data from your legacy data stores to the cloud is a unique opportunity for quality control, metadata tagging, data dictionary, data lineage and other data management best practices. While you could assume your data is fine and opt to move it without change, leveraging the cloud migration to clean and harmonize your data across your enterprise is a golden opportunity. Some organizations may go even further and look to cloud migration as an opportunity to centralize their data and abstract it via an enterprise data layer.

3. Integration With The Migrated Application

Once your connectivity to the target platform is completed, you must integrate your data storage subsystem with the rest of your migrated cloud application. This integration depends on how loosely coupled the data storage subsystem is with the rest of the application.

By focusing on your data migration separately from your application migration, you will guarantee that both achieve your goals for scalability, elasticity and metered billing.

Forgetting the steps needed to migrate your data can be costly from both a migration perspective and an enterprise perspective. Instead, seizing upon your cloud migration as an opportunity to implement enterprise-wide information management practices can help the organization become more efficient and more effective at the same time. Yes, you will have killed the proverbial two birds with one stone!