Migration of a local server (database, filed and other resources) into the cloud is a pretty good idea due to the profound benefits that cloud computing offers.
Consequently, cloud computing comes with some challenges which must be considered before making a decision of what goes into the cloud and what stays behind.
Therefore, the first initial step of migrating an organization’s resources into the cloud starts by conducting a preliminary checklist of some important definitions of needs and requirements with its associated risk factors, followed by extensive planning and then migration.
Preliminary checklist/planning for migration
Some important preliminary considerations when planning to migrate traditional computing infrastructures into the cloud include the following:
- Identify all potential benefits for moving from the existing computing infrastructure to cloud services.
- Confirm that the traditional computing infrastructure suits cloud-based services.
- Prepare a cost/opportunity and risk evaluation model to guide decision making about where, when, and how cloud computing services can be adopted.
- Develop a standard guideline and blueprint to optimize the current computing resources for migration to the cloud services (public/private)/
- Identify and prepare in-house technical how-to competencies that will be needed to manage effective adoption of cloud services.
- Appoint a cross-functional team to continually monitor which new services, providers, and standards are available, and to determine if they affect the blueprint.
- Assess technical problems that must be tackled when migrating any current resource (data/application) into a cloud environment.
- Confirm that the current networking/computing environment is ready for migration into a cloud environment.
After a successful preliminary planning, the following are the basic steps to migrate data, application and business services into a cloud environment.
This is depicted in the figure below.
Analyze business requirement
The prospective cloud service consumer must clearly define and analyze the purpose of migrating an application, data, a component or a legacy system into a cloud computing environment.
This is best achieved by establishing the overall business goals and objectives and how the migration can help to achieve them. Furthermore, the prospective cloud service consumer should analyze the data attributes and requirements and understand how the proposed migration to a different computing environment is liable to threaten the integrity of sensitive data for migration.
Evaluate migration decision
At this stage, the significance, purpose, goals, scope and limitations for migration of projects, including data, application and other components into the cloud are defined and assessed.
Migration into the cloud space are often justified by cost savings, scalability, enhanced productivity and capabilities to adapt functionality to new markets, and so on.
Business requirements must be defined by the potential cloud service consumer and how these requirements have an impact on the realization of the organization’s goal and objectives must be identified and understood before a final migration decision is made.
Analyze legacy system
This requires due diligence in analyzing, understanding and documenting the existing system, its associated components and all the related and associated documentation and information regarding the system implementation.
For black box systems, where there is no access to the underlying source program, the inputs, system responses and the outputs must be analyzed and documented.
For while box systems characterized by available and accessible source code, reverse engineering can be employed to break down the system into data functions.
Furthermore, the system is broken down along with the dimension of the type of functions where each function is mapped functionality to specific business objective(s) and requirements.
The decision on which the legacy system functions to migrate into a cloud environment becomes easier to make.
Identify component(s) to be migrated
Having identified the functions to migrate in the previous step, the next step is to identify components to migrate and their associated configurations.
Examples of such components include a function, database , an application layer, an algorithm or the whole legacy system. However, efforts should be made to ensure due privacy and security preservation of the components via data encryption or other encoding techniques.
Offer candidate service
This is a necessary step to identify already deployed services in cloud environments which can readily serve as a migration solution based on the consumer’s business requirements, including the expected security level as contained in contract and SLAs.
To achieve this, a service search can be performed either by the prospective consumer or a cloud service broker. Furthermore, retrieved services must be compared with the expected cloud service behavior that matches the consumer’s business requirements by analyzing the input, the output and the performance level with the expected results.
It is vividly possible not to find a service that meets the requirements, or an incomplete service , or a service that perfectly meets the expected solutions.
Choose migration type
In a bid to choose the migration type, it is important that the prospective cloud service consumer validates the identified components, the service candidate (provided there is any) and the required resources for the migration.
In addition, the consumer is expected to specify the type of migration that meets the business requirements and fulfills its objectives. If a candidate service that meets business requirements is found, the consumer should analyze the rules for the contract for services.
Function or component
At this stage, the cloud service provider locates and extracts each component that has been identified by by the prospective cloud service consumer for its migration via loose coupling and high modularity approaches.
At this level, the data and source code of the current system is backed up for reuse if the need to rollback changes is made to a component during migration.
Depending on the migration type, this also involves the development of appropriate interfaces, function prototyping and conversion as well as mapping of the data schema to the new datastore.
Link migrated component
At this stage, the software solution is deployed into the cloud system. Its configuration as a service from the cloud service provider’s environment is tested.
Furthermore, connections and configurations are established to synchronize the contracted services to the service consumer environment.
More often than not, a cloud service carrier is engaged to securely transport all the migrated components to the provider systems.
Check complete service
The migrated legacy system, applications, solutions, components and data are verified, validated and tested at the cloud service provider’s environment to ascertain that the migrated services and resources exhibit the correct behavior after the migration.
This helps to confirm that the functionality of the migrated system is available and accessible in the new system environment.
The other important quality analysis to conduct unit test, integration test, acceptance test, and pilot test before the control of functionalities of the system is transferred to the new system.
Confirm complete migration
Having confirmed that the migrated services are functioning as expected, the quality assurance test should be conducted relative to the predefined standards and business requirements of the organization.
Appropriate documentation related to the service implementation, configuration settings and all changes made during the migration must be made.
The service consumer should use the service as expected, evaluate the quality of the service periodically and also understand the new processes and necessary changes made to the initial organization procedures due to the migration.
The cloud service consumer may use a backup copy of all migrated services, applications and data to reverse the entire migration process if it is discovered that the migration process violated the minimum acceptable quality standards required or if the entire migration failed.
Types of migration for cloud-enabled applications
There are basically four types of cloud-enabled migrations which are :
- Type I
- Type II
- Type III
- Type IV
Replace component(s) with cloud offerings. This is the least invasive type of migration, where one or more (architectural) components are replaced by cloud services.
As a result, data and/or business logic have to be migrated to the cloud service. A series of configurations, rewiring and adaptation activities to cope with possible incompatibilities may be triggered as part of this migration. Using Google App Engine Datastore in place of a local MySQL database is an example of this migration type.
Partially migrate some of the application functionality to the cloud. This type entails migrating one or more application layers, or a set of architectural components from one or more layers implementing a particular functionality to the cloud.
Using a combination of Amazon SimpleDB and EC2 instances to host the auditing data and business logic for HIC is an example of such a migration.
This is a classic migration in which the entire software stack of the application is migrated to the cloud. This type of migration makes encapsulation in virtual machines and execution in the cloud possible.
This type of migration is also known as Cloudify the application. It typifies a complete migration of the application, data and business logic to the cloud as well as the associated functions and components to manage possible incompatibilities.
However, the application functionality is implemented as a composition of services running on the cloud.