FORM 2
THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENTS RULES, 2003
COMPLETE SPECIFICATION
(See section 10, rule 13)
1. Title of the invention: MIGRATION OF AN ENTERPRISE TO A CLOUD
COMPUTING ENVIRONMENT
2. Applicant(s)
NAME NATIONALITY ADDRESS
TATA CONSULTANCY Indian Nirmal Building, 9th Floor,
SERVICES LIMITED Nariman Point,
Mumbai 400021,Maharashtra,
India
3. Preamble to the description
COMPLETE SPECIFICATION
The following specification particularly describes the invention and the manner in which it
is to be performed.

TECHNICAL FIELD
[0001] The present subject matter, in general, relates to enterprise migration and, in particular, relates to methods and systems for migration of an enterprise to a cloud computing environment.
BACKGROUND
[0002] In a growing global economy, cloud computing is enabling organizations to be more agile and efficient by offering a broad range of applications and hardware as a service, thereby reducing computing infrastructure costs by a considerable extent. Cloud computing is considered to be a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources, such as networks, servers, storage, applications, and services that can be rapidly provisioned and released with minimal management effort or service provider interaction.
[0003] Cloud computing offers attractive benefits which can be persuasive for conventional organizations to migrate to the cloud computing environment for their businesses. However, there are various business, technology, and risk considerations, which can have an effect on the overall success of the cloud initiative for the organization. Furthermore, there is no accurate methodology or framework, which organizations can adopt to effectively migrate to the cloud computing environment. Each enterprise must evaluate its cloud computing migration strategy by assessing a plurality of factors, including its business imperatives, technology strategy, and risk appetite, to determine the best possible migration path.
SUMMARY
[0004] This summary is provided to introduce concepts related to migration of an enterprise to a cloud computing environment, and the concepts are further described below in the detailed description. This summary is not intended to identify essential features of the claimed subject matter nor is it intended for use in determining or limiting the scope of the claimed subject matter.
[0005] In one implementation, a method of migration of at least a part of information technology (IT) infrastructure of an enterprise to a cloud computing environment. In one implementation the method includes categorizing the IT infrastructure of the enterprise into a

plurality of Lines of Businesses (LoB), each of the LoBs being representative of at least a business function, business sponsors, and technologies used therein, wherein each of the LoBs includes a plurality of applications and corresponding databases. The method further includes abstracting selected applications from the LoBs at a database layer thereof to obtain applications separated from their databases, and migrating the databases to a public cloud, where the categorization, abstraction, and the migration include implementing a plurality of factory methodologies. Further, the factory methodologies are based on concepts of at least systematic reuse, model driven development, quality control, and cost reduction.
BRIEF DESCRIPTION OF THE DRAWINGS
[0006] The detailed description is described with reference to the accompanying figures. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The same numbers are used throughout the drawings to reference like features and components.
[0007] Fig. 1 illustrates a network environment implementing a cloud migration system, in accordance with an embodiment of the present subject matter.
[0008] Fig. 2 illustrates a cloud migration system for migration of an enterprise to cloud, in accordance with an embodiment of the present subject matter.
[0009] Fig. 3 illustrates a method for migration of an enterprise to cloud, in accordance with an embodiment of the present subject matter.
[0010] Fig. 4 illustrates an implementation of a factory methodology in a software industry, in accordance with an embodiment of the present subject matter.
DETAILED DESCRIPTION
[0011] Systems and methods for migration of an enterprise to a cloud computing environment are described herein. The systems and methods can be implemented in a variety of computing devices, such as laptops, desktops, workstations, tablet-PCs, smart phones, notebooks or portable computers, tablet computers, mainframe computers, mobile computing devices, entertainment devices, computing platforms, internet appliances, and similar systems. However, a person skilled in the art will comprehend that the embodiments of the present subject matter are

not limited to any particular computing system, architecture or application device, as they may be adapted to take advantage of new computing systems and platforms as they become available. [0012] Conventional organizations or enterprises depend substantially on their own computing infrastructure and in-house computing capabilities to execute and maintain their lines of business (LoB) efficiently. The state of Information Technology (IT) systems within these organizations today is as diverse as the set of organizations themselves. This diversity is due to years of project based system implementation, mergers and acquisitions, ever increasing cost cutting initiatives, and a variety of other factors. Today, organizations are noticing the benefits of the cloud computing environment, or simply cloud, and are giving considerable thought to abandoning their enterprise driven businesses, and adopting cloud computing. Cloud computing offers a vast range of advantages, such as capital expenditure reduction, by converting said capital expenditure to operational expenditure; location and device independence, as computing infrastructure is usually provided off-site by a third party service provider, and users can utilize a thin client or web browser to access and utilize, via a network, said computing infrastructure regardless of their location or what device they are using; multi-tenancy, which facilitates sharing of resources and costs across a large pool of users; reliability improvements, as a well implemented cloud computing environment allows for improved business continuity and disaster recovery; and scalability and elasticity, by a dynamic provisioning of resources within the cloud. These are just some of the business and other benefits offered by cloud computing.
[0013] Conventional cloud service models include Infrastructure as a Service (IaaS), Platform as a Service (Paas), and Software as a Service (SaaS), where IaaS is considered to be the most basic, and each higher model abstracts from the details of the lower models. In the IaaS model, cloud service providers generally offer computers, or computing hardware as virtual machines. Such hardware is generally virtualized and offered as resources-on-demand from their data centers. End users of said resources are usually billed as per usage, where the usage is generally reflective of the amount of resources allocated to, and consumed by the user. Furthermore, the user does not need to pay for unused capacity and resources.
[0014] In the PaaS model, generally, cloud service providers offer computing platforms, such as operating systems, programming language execution environments, databases, and web servers, as a service in addition to the infrastructure. Therefore, software users can run their

software on a cloud platform without incurring the corresponding hardware and platform computing resource costs.
[0015] In the SaaS model, the cloud service provider usually installs and maintains software, such as applications, in the cloud. The users can then access these applications from various client devices through a client interface, such as a web browser. An example of cloud based software is web based email. The SaaS model is beneficial in that the user is provided with a single access point, without having to worry about any maintenance or hardware related issues, which can be controlled by the cloud service provider.
[0016] Furthermore, broadly three categories exist for the deployment of cloud computing, viz. private cloud, public cloud, and hybrid cloud. Private clouds are deployments of the cloud computing environment specifically for one organization or client. Private clouds can be managed by the organization or by a cloud service provider, and the cloud may exist on-premises, or off-premises with respect to the organization.
[0017] Public clouds are generally created and maintained by the cloud service provider. The services offered via the public cloud can be offered to one or more organizations or the general public. Generally, organizations having greater security or confidentiality concerns may opt to utilize the services of a private cloud rather than the public cloud. Furthermore, in comparison to public clouds, private clouds can present the organization with a greater degree of customization and restricted accessibility.
[0018] Hybrid clouds are those cloud computing infrastructures that generally include a combination of private and public cloud infrastructures. There may be some interaction between the various clouds in the hybrid cloud, for example, for load bearing and distribution requirements.
[0019] The concept of migrating towards cloud for organizations, generally involves a multitude of planning levels, and a host of associated problems and considerations. The organization must consider moving its applications into the cloud computing environment while incurring the least possible interruption in the business and services.
[0020] Depending on the size of the organization, the organization can involve multiple lines of business, utilizing a plethora of applications amidst a sea of different technologies. The

operation of these lines of business typically includes utilization of substantially large amount of resources, such as manpower and computing infrastructure, further branching into the maintenance and operation thereof. Conventional organizations generally tend to run their own in-house IT departments, which exist for the sole purpose of maintaining and operating the organizations IT framework and systems.
[0021] Moreover, at present, no proven methodology or accurate framework exists to assist an organization to migrate to the cloud computing environment with any level of assurance or success.
[0022] The present subject matter describes systems and methods for migration of an enterprise to a cloud computing environment. In one implementation, the migration involves a plurality of distinct phases, to assist an enterprise to take concrete steps for the migration towards the cloud computing environment.
[0023] A first phase includes categorization of the business segments of the organization, where the organization can be split into various Lines of Business (LoB). The categorization can include primarily assessing various technologies and applications being utilized in each LoB to determine their requirements for implementation in the cloud. This assessment can also include analysis of the existing applications being utilized in each LoB, to determine business viability gaps if any, between the existing applications and competitor, or Commercial off the Shelf (COTS) variants. The first phase aims to enforce the need for infrastructure commonality, and exclusion of underperforming and outdated technologies.
[0024] In one implementation, this assessment includes generating an application bibliography. The application bibliography can include mapping various details of each application, such as business functions, LoB, business sponsors, and a list of the technologies utilized by the applications. The application bibliography thus generated is beneficial in gaining an overall understanding of a common need of each application in terms of a technology requirement. This methodology aims to adopt an operational framework across the different LoBs, independent of any organizational boundaries that may exist, thereby overruling the silo approach where each LoB is independent of each other.

[0025] In one implementation, the first phase also involves publishing a support calendar for each of the existing technologies in the organization. This can be referred to as enterprise technology planning, where each existing technology is analyzed for organization strategic fitment, and adoption direction to assist in the migration to the cloud computing environment.
[0026] In another implementation, the assessment can also include creating a technology and version compatibility mapping. This mapping, in one example, can be provided in the form of a matrix, and can include a list of all existing computing hardware and technologies, and their corresponding database compatibilities. Furthermore, information from the support calendars disclosed above can also be utilized in creating the matrix. By utilizing the information from the compatibility matrix and the enterprise technology planning, estimation factors for any current or future upgrade or migration requirements can be derived. Moreover, the possibility of application transformation is also covered in the first phase. For example, in order to render an incompatible application compatible with a target database, transformation of the application is necessary. In this manner, technology planning can be effectively facilitated, which will help the organization move its application portfolio into the cloud. The above steps are beneficial in consolidating technologies for implementation in the cloud across the various LoBs of the organization, instead of a silo approach, where each LoB is migrated individually. In this manner, the data center footprint, with the associated real estate costs are reduced. For the sake of clarity and easy reference, phase one of the migration can also be referred to as the consolidation phase.
[0027] In one implementation, a second phase of migration includes abstraction of the existing applications, using techniques, such as virtualization. In one example, the virtualization is performed through hypervisor technology, or conventional methods to abstract applications from physical resources. The second phase, also referred to as the abstraction phase hereinafter, is aimed at achieving multi-tenancy of applications, whereby running costs are decreased and sharing of infrastructure is facilitated for end users. Reliability can be achieved through conventional strategies, such as ‘for failure’ and ‘for failover’. The ‘For Failover’ strategy expects an application to rely on infrastructure to failover to an idle node in case of an availability issue with a primary node. The “For Failure” strategy is where applications are designed to handle the possibility of Infrastructure failure. According to an implementation of the present subject matter, the abstraction of applications is performed at a database layer,

thereby rendering application functionality independent of their database location. Maturity of the database technologies on portability and integration attributes of architecture make this abstraction seamless and least impacting to the architectural layers using the database layer. Therefore, this method of abstraction has little or minimal impact on the applications for operation, as the operation of applications is independent of the location of the database. Therefore, the migration of the organization can be performed with little interruption of business and services. Upon abstraction, the applications can be migrated to a private cloud for implementation.
[0028] In one implementation, a third phase of migration includes resource alignment, allocation of skills and competencies, and development of training plans. These are essentially to improve the agility of the organization in its migration towards cloud, and therefore, the third phase can be referred to hereinafter as the agility phase. In the agility phase, based on the various factors obtained from the consolidation and the abstraction phase, decision bound steps can be taken to achieve a substantially high degree of horizontal scaling for the organization.
[0029] In a further implementation, a fourth phase, viz. a utility phase, involves various implementation related strategies and frameworks for the migration of the organization. In said implementation, the utility phase involves planning various expected contractual liabilities, for example with service providers, in the form of Service Level Agreements (SLA). These contractual liabilities can include pricing details, data security features, dynamic database capacity control features, and autonomic efficiency features.
[0030] According to the present subject matter, in one implementation, a factory methodology is implemented for the migration during the various phases described above. These factory methodologies have been proven in the mechanical industry, and with suitable modifications thereof, can be effectively utilized to impart various improvements to the cloud migration process according to the present subject matter. The factory methodology revolves around ideas, such as systematic reuse, model driven development, development by assembly and process framework. For example, by utilizing information from the application bibliography, and the technology compatibility and version mapping, repeatable tasks can be identified and allotted to a service line. In one implementation the service line in software industry includes people executing well defined repeatable tasks, called widgets. Sizing of a team for a specific

service line is determined based on throughput and effort required for each widget. The service line utilizes a systematic and sequential approach towards identifying and performing repeatable tasks in the enterprise with regard to application functionality and the like. Furthermore, this standardization and reusability can be facilitated through templates, methodologies, tools and best practices, which effectively reduce time to implement the cloud computing environment for the enterprise. Examples of service lines include database migration from one version to another, technology migration say Visual Basic (VB) to .Net where this migration is repeated multiple times across the enterprise.
[0031] The factory methodology is also focused at improving quality control by implementing six sigma processes, cost effectiveness by utilizing low cost models, such as off-shoring and less skilled labor. Therefore, the factory methodology provides an enveloping automation framework for the migration process, which allows for an agile and adaptable, yet accurate method by which an enterprise can migrate towards the cloud computing environment.
[0032] These and other advantages of the present subject matter would be described in greater detail in conjunction with the following figures. While aspects of described systems and methods for migration of an enterprise to a cloud computing environment can be implemented in any number of different computing systems, environments, and/or configurations, the embodiments are described in the context of the following exemplary system(s).
[0033] Fig. 1 illustrates a network environment 100 implementing a cloud migration system 102, according to an embodiment of the present subject matter. In the network environment 100, the cloud migration system 102 is connected to a network 104. Furthermore, a database 106, and one or more client devices 108-1, 108-2...108-N, collectively referred to as client devices 108, are also connected to the network 104.
[0034] The Cloud migration system 102 can be implemented as any set of computing devices connected to the network 104. For instance, the Cloud migration system 102 may be implemented as mainframe computers, workstations, personal computers, desktop computers, multiprocessor systems, laptops, network computers, minicomputers, servers, and the like. In addition, the Cloud migration system 102 may include multiple servers to perform mirrored tasks for users, thereby relieving congestion or minimizing traffic.

[0035] Furthermore, the Cloud migration system 102 can be connected to the client devices 108 through the network 104. Examples of the client devices 108 include, but are not limited to personal computers, desktop computers, smart phones, PDAs, and laptops. Communication links between the client devices 108 and the Cloud migration system 102 are enabled through a desired form of connections, for example, via dial-up modem connections, cable links, digital subscriber lines (DSL), wireless or satellite links, or any other suitable form of communication.
[0036] Moreover, the network 104 may be a wireless network, a wired network, or a combination thereof. The network 104 can also be an individual network or a collection of many such individual networks interconnected with each other and functioning as a single large network, e.g., the internet or an intranet. The network 104 can be implemented as one of the different types of networks, such as intranet, local area network (LAN), wide area network (WAN), the internet, and such. The network 104 may either be a dedicated network or a shared network, which represents an association of the different types of networks that use a variety of protocols, for example, Hypertext Transfer Protocol (HTTP), Transmission Control Protocol/Internet Protocol (TCP/IP), etc., to communicate with each other. Further, the network 104 may include network devices, such as network switches, hubs, routers, host bus adapters (HBAs), for providing a link between the Cloud migration system 102 and the client devices 108. The network devices within the network 104 may interact with the Cloud migration system 102 and the client devices 108 through communication links.
[0037] In one implementation, the Cloud migration system 102 can be configured to assist an enterprise in various phases of migration towards a cloud computing environment (hereinafter referred to simply as the cloud). Using the Cloud migration system 102, the enterprise can take definite steps in achieving a final state of cloud, the benefits of which are well known and are described earlier. In one implementation, the Cloud migration system 102 includes an abstraction module 110, and a factory methodology module 112. In one implementation, the abstraction module 110 can be configured to abstract one or more existing applications in the enterprise, based on a plurality of factors. In one implementation, the abstraction module 110 can be configured to perform the abstraction at a database layer of said applications thereby separating application functionality from their databases. In this manner, the migration is least impacting on the functionality of said applications. These databases can then be migrated to the cloud

computing environment, such as a private cloud, for implementation. It will be understood that the abstraction module 110 and the factory methodology module 112 can reside, or be implemented separately, such as on servers that are a part of the cloud migration system 102.
[0038] In one implementation, the factory methodology module 112 can be configured to implement one or more factory methodologies or practices in the phases of migration of the enterprise towards cloud. These factory methodologies can include identifying repeatable tasks in application functionality, and implementing said repeatable tasks in a service line, where the service line assists in performing a repeated task or tasks in sequential stages of progression. The factory methodology module 112 can also be configured to perform other tasks during the migration of the enterprise, such as quality control, and cost reduction model implementation. The manner in which the factory methodology module 112 implements the one or more factory methodologies is described in the detailed description pertaining to fig. 2.
[0039] In one implementation, the user may utilize the client devices 108 to monitor and carry out specific stages of the migration of the enterprise. In one example, the client devices 108 can be provided with a User Interface (UI), via which the user can monitor and carry out the various phases of the migration of the enterprise. In another example, privilege and access levels can be configured for the users, based on which, the users will be able to monitor and carry out varying levels of the migration of the enterprise.
[0040] Fig. 2 illustrates a Cloud migration system 102, in accordance with an embodiment of the present subject matter. In said embodiment, the Cloud migration system 102 includes one or more processor(s) 202, interface(s) 204, and a memory 206 coupled to the processor 202. The processor 202 can be a single processing unit or a number of units, all of which could also include multiple computing units. The processor 202 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. Among other capabilities, the processor 202 is configured to fetch and execute computer-readable instructions and data stored in the memory 206.
[0041] The interfaces 204 may include a variety of software and hardware interfaces, for example, interface for peripheral device(s), such as a keyboard, a mouse, an external memory, and a printer. Further, the interfaces 204 may enable the Cloud migration system 102 to

communicate with other computing devices, such as web servers and external data repositories, such as the database 106, in the network environment 100. The interfaces 204 may facilitate multiple communications within a wide variety of protocols and networks, such as a network, including wired networks, e.g., LAN, cable, etc., and wireless networks, e.g., WLAN, cellular, satellite, etc. The interfaces 204 may include one or more ports for connecting the Cloud migration system 102 to a number of computing devices.
[0042] The memory 206 may include any computer-readable medium known in the art including, for example, volatile memory, such as static random access memory (SRAM) and dynamic random access memory (DRAM), and/or non-volatile memory, such as read only memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes. The memory 206 also includes module(s) 208 and data 210.
[0043] The module(s) 208 include routines, programs, objects, components, data structures, etc., which perform particular tasks or implement particular abstract data types. In one implementation, the module(s) 208 includes a consolidation module 212, the abstraction module 110, the factory methodology module 112, and other module(s) 214. The other module(s) 214 may include programs or coded instructions that supplement applications and functions of the Cloud migration system 102.
[0044] On the other hand, the data 210, inter alia serves as a repository for storing data processed, received, and generated by one or more of the module(s) 208. The data 210 includes for example, consolidation data 216, abstraction data 218, factory methodology data 220, and other data 222. The other data 222 includes data generated as a result of the execution of one or more modules in the module(s) 208.
[0045] In one implementation, the Cloud migration system 102 is configured to assist an enterprise in various phases of migration towards a cloud computing environment (hereinafter referred to simply as the cloud). By the functionality of the Cloud migration system 102 the enterprise can take definite steps in achieving a final state of cloud. The various phases of migration include a consolidation phase, an abstraction phase, an agility phase, and a utility phase. The manner, in which the Cloud migration system 102 is configured to operate in conjunction with these phases, as well as by implementing a factory methodology framework, is described in the following description.

[0046] In the consolidation phase, the enterprise can be categorized or split into various Lines of Business (LoB). For example, if an enterprise partakes, or conducts itself in various LoBs, the consolidation phase can primarily involve categorizing the enterprise into these individual LoBs. The categorization can be based on factors, such as a business function of the LoB, business sponsors, the applications, and the technologies used therein. Each of the individual LoBs can be assessed for various applications and technologies used therein, and a requirement of these applications in the cloud. In one implementation, the Cloud migration system 102 includes the consolidation module 212. The consolidation module 212 can be configured to assess the various applications and technologies in each LoB, and their requirement for implementation in the cloud. In one example, the consolidation module 212 can be configured to generate an application bibliography based on the assessment. The application bibliography can be generated for each LoB as disclosed earlier, to gain a better understanding of the utilization of the various applications therein. In one example, the application bibliography can include details of each application, such as business functions, LoB, business sponsors, and a list of the technologies utilized by the applications. The application bibliography thus generated for each LoB is beneficial in gaining an overall understanding of a common need of each application in terms of a technology requirement for each LoB or across all the LoBs of the enterprise. Therefore, in the consolidation phase, an operational framework for migration can be adopted across the different LoBs, which is independent of any organizational boundaries that may exist, thereby overruling the conventional silo approach where each LoB is independent of each other. Moreover, infrastructure commonality can be enforced, and old or outdated applications can be excluded from the migration process. In one implementation, the consolidation module 212 can be further configured to store the application bibliography in the consolidation data 216.
[0047] In one implementation, the consolidation module 212 can be configured to publish a support calendar for each of the existing technologies in the various LoBs of the organization, based on the assessment disclosed above. This can be referred to as enterprise technology planning, where the existing technology is analyzed for organization strategic fitment, and adoption direction to assist in the migration to the cloud. For example, various technologies and software can be assessed for future support from the vendors. Furthermore, technology support cycle published by the respective vendor is a key input to the support calendar. For example,

Oracle 9i is de-supported in 2010 hence the support calendar would mark this technology as outdated and would suggest to use Oracle 11g instead. In one implementation, the consolidation module 212 can be further configured to store the support calendars in the consolidation data 216.
[0048] In a further implementation, the assessment further includes creating a technology and version compatibility mapping. For example, the consolidation module 212 can be configured to create the technology and version compatibility mapping. The technology and version compatibility mapping includes details of the various existing computing hardware and technologies, and their corresponding database compatibilities, utilized by the LoBs of the enterprise. Furthermore, in one example, the consolidation module 212 can be configured to fetch information from the support calendars stored in the consolidation data 216, and utilize the same for creating the technology and version compatibility mapping. In one implementation, the consolidation module 212 can be further configured to store the technology and version compatibility mapping in the consolidation data 216.
[0049] In an implementation, by utilizing the information from the technology and version compatibility mapping and the enterprise technology planning, the consolidation module 212 can be configured to derive estimation factors for any current or future upgrade or migration requirements. The estimation factors are typically derived from industry productivity to migrate a technology, and are specific to that technology. In one example, Oracle Forms and reports would be number of Forms/reports and Client Specific modules version difference 6i to 11g, or 6i to 10g, Number of modules. In a further example, Oracle database deprecated and obsolete features, number of code components that has these, suggested alternative methods to code, ability to automate, etc. These estimation factors are also beneficial in weeding out old and outdated hardware and technologies, thereby reducing data center footprints, and associated real estate costs. Moreover, a possibility of application transformation is also covered in the consolidation phase. For example, the consolidation module 212 can be configured to transform applications that are determined to be incompatible with a target database. This determination can be performed based on the information received from the application bibliography, and the technology and version compatibility mapping as described earlier. In one implementation, the

consolidation module 212 can be further configured to store information pertaining to the transformed applications in the consolidation data 216.
[0050] The above steps are beneficial in pooling or consolidating technologies for implementation in the cloud across the various LoBs of the enterprise, in a time and cost efficient manner as compared to a silo approach. Furthermore, the data center footprint along with the associated real estate costs can be reduced in this manner.
[0051] In the abstraction phase, the various applications selected in the consolidation phase, which are required to be migrated into the cloud, can be abstracted. By abstracting the applications, the functionality thereof can be virtually separated from associated hardware for effective migration. In one implementation, the abstraction module 110 can be configured to abstract said applications at a database layer, thereby rendering application functionality independent of their databases. Therefore, there is least interruption of business functionality of these applications during the migration process. Once the applications are abstracted at the database layer, these now independent databases can be migrated into a private cloud for preliminary implementation, thereby inducing least impact on the operation of said applications, as the operation of the applications is independent of the location of the database. Furthermore, in this manner, the databases of various applications can be consolidated and offered as a multi-tenant service model. On successful implementation and testing of the applications in the private cloud, a public cloud implementation is similarly possible.
[0052] In one implementation, the abstraction module 110 can be configured to utilize hypervisors to abstract the applications from the physical resources. Moreover, application function reliability and stability can be achieved through various designs, such as ‘for failure’ and ‘for failover’. In another implementation the abstraction module 110 can be configured to store information pertaining to the abstraction of the applications in the abstraction data 218.
[0053] In one implementation, the migration includes an agility phase. The agility phase is designed to improve the agility of the enterprise in its migration towards cloud. Various tasks, such as resource alignment, allocation of skills and competencies, and development of training plans can be performed in the agility phase of the migration. The above mentioned tasks can be tailored according to the type of enterprise and the various LoBs therein. Moreover, in this phase, based on the various factors obtained from the consolidation and the abstraction phase, decision

bound steps can be taken to achieve a substantially high degree of horizontal scaling for the organization. For example, based on the expansion and growth plans of the enterprise, horizontal scaling requirements can be evaluated and implemented to impart agility to the enterprise. In one implementation, the Cloud migration system 102 can be configured to store information generated in the agility phase in any external database, such as the database 106, or internally, within the Cloud migration system 102.
[0054] In one implementation, the migration involves a utility phase. The utility phase involves various implementation related strategies and frameworks for the migration of the organization. In other words, the utility phase aims to deal with how the migration project is going to work in the field. In said implementation, the utility phase can involve planning various expected contractual liabilities, for example with service providers, in the form of Service Level Agreements (SLA). These contractual liabilities can include pricing details, data security features, dynamic database capacity control features, and autonomic efficiency features. Based on the various requirements of the enterprise with regard to scope of operation, the contractual liabilities will vary. In one implementation, the various contracts and details thereof can be stored in an external database, such as the database 106, and accessed by the Cloud migration system 102. In another implementation, these details can be stored by the Cloud migration system 102 in the data 210. At any stage during the migration of the enterprise, users can have access to said contracts and their details for review and scrutiny.
[0055] In one implementation, the Cloud migration system 102 includes a factory methodology module 112. The factory methodology module 112 can be configured to implement one or more factory methodologies or practices, in selected phases of the migration of the enterprise towards cloud. The factory methodology module 112 can be configured to identify similar work packets in different applications in the enterprise, and automate these work packets using a service line concept. For example, the factory methodology module 112 can be configured to identify repeatable tasks in existing application functionality, and implementing said repeatable tasks in a service line, where the service line assists in performing the repeated task or tasks in sequential stages of progression. In one example, the factory methodology module 112 can be configured to fetch information regarding the various applications and their

functionalities, such as from the consolidation data 216, the abstraction data 218, and/or the database 106, to identify the repeatable tasks.
[0056] The factory methodology module 112 can also be configured to perform other tasks during the migration of the enterprise, such as quality control, and cost reduction model implementation. The quality control aspect revolves around concepts, such as six sigma analysis and feedback collation from the various implemented service lines as discussed earlier. For example, the factory methodology module 112 can be configured to perform the six sigma analysis, and the feedback collation on the various service lines. The various cost reduction models include increasing cost effectiveness by reducing skilled labor wherever possible, and off-shoring.
[0057] The factory methodology module 112 is configured to operate on concepts, such as systematic reuse, model driven development, development by assembly, and process framework, which are all beneficial in improving application development, operation and transformation during the various phases of the migration of the enterprise towards cloud, thereby reducing time to market, and substantially improving automation and cost benefit of any enterprise wishing to migrate to cloud.
[0058] Fig. 3 illustrates a method 300 for migration of an enterprise to a cloud computing environment, according to one embodiment of the present subject matter. The method 300 may be implemented in a variety of computing systems in several different ways. For example, the method 300, described herein, may be implemented using the Cloud migration system 102, as described above.
[0059] The method 300, completely or partially, may be described in the general context of computer executable instructions. Generally, computer executable instructions can include routines, programs, objects, components, data structures, procedures, modules, functions, etc., that perform particular functions or implement particular abstract data types. A person skilled in the art will readily recognize that steps of the method can be performed by programmed computers. Herein, some embodiments are also intended to cover program storage devices, e.g., digital data storage media, which are machine or computer readable and encode machine-executable or computer-executable programs of instructions, wherein said instructions perform some or all of the steps of the described method 300.

[0060] The order in which the method 300 is described is not intended to be construed as a limitation, and any number of the described method blocks can be combined in any order to implement the method, or an alternative method. Additionally, individual blocks may be deleted from the method without departing from the spirit and scope of the subject matter described herein. Furthermore, the methods can be implemented in any suitable hardware, software, firmware, or combination thereof. It will be understood that even though the method 300 is described with reference to the Cloud migration system 102, the description may be extended to other systems as well.
[0061] The method 300 aims to provide guidelines for an enterprise to migrate to the cloud computing environment hereinafter referred to simply as cloud, via a plurality of migration phases, which have been further split into blocks shown in fig. 3.
[0062] At block 302, the enterprise can be categorized into individual Lines of Business (LoB). The categorization further includes assessing various applications and technologies existing in each LoB. The primary function of splitting up the enterprise into its various LoBs is to gain an overall understanding of the various applications being used in the different LoBs, and furthermore, to reduce or eliminate usage of repeating applications or technologies across the various LoBs. In one implementation, the consolidation module 212 of a Cloud migration system 102 as described earlier can be configured to assess the various applications and technologies in each LoB.
[0063] At block 304, based on the assessment, an application bibliography can be generated. The application bibliography includes various details of the applications assessed earlier. The details can include but are not limited to, business functions, LoB, business sponsors, and a list of technologies utilized by the application. In one example, the consolidation module 212 of the Cloud migration system 102 can be configured to generate the application bibliography.
[0064] At block 306, a support calendar can be published for each of the technologies assessed in the block 302. The support calendar is beneficial in performing enterprise technology planning, where the existing technology can be thoroughly assessed for strategic fitment in the enterprise. In one example, the consolidation module 212 of the Cloud migration system 102 can be configured to publish the support calendar for each of the existing technologies in the various LoBs of the organization.

[0065] At block 308, based on the above assessment, and based on information from the support calendars, a technology and version compatibility mapping can be created. The technology and version compatibility mapping, for example in the form of a matrix, can include details of existing computing hardware in each LoB, along with details of the technologies used therein. Moreover, the technology and version compatibility mapping can also include database compatibilities of such computing hardware and technologies for implementation in the cloud. In one example, the consolidation module 212 of the Cloud migration system 102 can be configured to create the technology and version compatibility mapping.
[0066] At block 310, estimation factors can be derived, based on information from the technology and version compatibility mapping for planning future upgrades of the technology and hardware. For example, the estimation factors are beneficial in ascertaining, which hardware and/technology is outdated, and the same can be excluded from the migration process effectively, thereby reducing maintenance costs and other requirements thereof. In one example, the consolidation module 212 of the Cloud migration system 102 can be configured to derive the estimation factors. Furthermore, based on information received from the application bibliography, and the technology and version compatibility mapping, incompatible applications can be suitably transformed for implementation in the cloud computing environment. For example, the consolidation module 212 can be configured to transform said applications based on information from the application bibliography, and the technology and version compatibility mapping.
[0067] In one implementation, the method steps contained in the blocks 302 to 310 can collectively be referred to as a consolidation phase of the migration of the enterprise towards cloud. The consolidation phase aims to pool various resources across the various LoBs of an enterprise, thereby reducing the need for repeating resources across the various LoBs. This also in turn substantially reduces associated maintenance costs for the resources, such as computing resources and technology.
[0068] At block 312, the applications selected for the migration to cloud, for example, from information extracted from the application bibliography, can be abstracted (hereinafter referred to as the abstraction phase). The abstraction includes virtualization using techniques, such as hypervisor technology, to abstract the various selected applications from their associated

databases. In one implementation, in said abstraction phase, the applications are abstracted at a database layer, which is beneficial in being the least disruptive for application functionality and hence business operation of the enterprise during the migration. Furthermore, the abstracted databases can then be migrated into a private cloud, thereby effectively implementing application functionality via a cloud computing environment. Based on the outcome of said abstraction, i.e., a success or failure, at a later stage of the migration, the abstracted databases can be migrated into a public cloud computing environment thereby maximizing multi-tenancy across the enterprise. Moreover, in one example, an abstraction module 110 of the Cloud migration system 102 as described earlier can be configured to abstract said applications.
[0069] At block 314, various agility enhancing tasks can be performed across the enterprise to improve the flexibility of the enterprise while migrating as well as post migration, i.e., during operation in the cloud computing environment (hereinafter, this stage of the migration can be referred to as the agility phase). The agility phase can include tasks, such as resource alignment, allocation of skills and competencies, and development of training plans. These tasks provided herein are not to be construed in a limiting manner, but should be understood as customizable tasks, which are primarily aimed at increasing enterprise agility during and post migration into the cloud. Furthermore, these tasks can be suitably customized based on various factors, such as the type of enterprise, and the types of businesses it conducts.
[0070] At block 316, various contracts can be formed and implemented for the enterprise to operate upon migration to the cloud. In one example, the contracts, or contractual liabilities can include various guidelines and policies for the enterprise to operate in a cloud computing environment, such as Service Level Agreements (SLA), pricing and cost metering details, data security features, dynamic database capacity control features, and autonomic efficiency features. This phase can be referred to as a utility phase of the migration.
[0071] At block 318, factory methodologies or practices can be implemented to govern the manner in which the various phases of the migration operate. The factory methodologies offer various distinct frameworks within which the enterprise can organize and perform its migration tasks effectively, and with a substantially high degree of automation and quality control.
[0072] In one implementation, the factory methodology provides a framework by which repeatable tasks can be identified, for example, in application functionality, and implementing

said repeatable tasks along a service line. The service line is indicative of a sequential yet progressive train of operation, where these repeatable tasks can be performed along with substantially high levels of quality control and feedback collation. For example, the quality control techniques can include techniques, such as six sigma processes. Moreover, the factory methodology also includes implementing various cost reduction models, such as identifying areas in the enterprise where off-shoring is possible, or the quanta of skilled labor can be reduced.
[0073] These factory methodologies are driven on concepts, such as systematic reuse, model driven development, development and assembly, and process frameworks. Furthermore, these factory methodologies can be adapted to the cloud migration process and offer various benefits in the different phases of migration by reducing time to market, increasing automation, and provided cost benefits to the enterprise wishing to migrate to cloud. In one example, a factory methodology module 112 of the Cloud migration system 102 can be configured to implement the one or more factory methodologies or practices in the phases of migration of the enterprise towards cloud.
[0074] Fig. 4 illustrates an implementation of a factory methodology in a software industry, in accordance with an embodiment of the present subject matter.
[0075] Fig. 4 illustrates a process flow 400, in a software industry where the factory methodology according to the present subject matter is applied at various process stages therein. For example, at a stage 402, a prioritized list of databases used by the software industry is created. These databases can be split into individual form at a subsequent stage 404, for analysis of each of the databases. At a stage 406, each of the databases can be scanned repeatedly. In one implementation, the factory methodology can be implemented at the stage 406, where for example, these repeatable tasks can be identified and assigned to a service line.
[0076] Furthermore, similar to the stage 406, repeatable tasks can be identified in the software industry depicted in the above example, and assigned accordingly to a service line for increased levels of automation and stricter quality control. For example, the factory methodology can be implemented at a stage 408, where upgrade policies can be applied to each of the scanned databases to adhere to specific security and privacy guidelines. In one example, technology upgrade to a current supported version of an application is a process where the factory

methodology can be implemented. Furthermore, at stage 410, the various migration policies can be built and executed along a service line, and at stage 412, data which is migrated or upgraded by the previous mentioned factory procedures can be validated according to the factory methodology. In one example, a stage 414 depicts a deployment environment, or in another example, a real-time execution environment.
[0077] Furthermore, at a stage 416, a clustering and consolidation analysis can be performed, at a stage 418, tooling and efficiency processes can be performed, and at a stage 420, an environment setup can be investigated. Moreover, the independent stages depicted by 416, 418, and 420 also can be implemented with the factory methodology according to the present subject matter.
[0078] In one implementation, a factory methodology module 112 of the Cloud migration system 102 as disclosed earlier can be configured to implement the one or more factory methodologies or practices in the process flow 400.
[0079] Although implementations of migration of an enterprise to a cloud computing environment have been described in language specific to structural features and/or methods, it is to be understood that the present subject matter is not necessarily limited to the specific features or methods described. Rather, the specific features and methods are disclosed as implementations for migration of an enterprise to a cloud computing environment.

I/we claim:
1. A computer implemented method for migration of at least a part of information
technology (IT) infrastructure of an enterprise to a cloud computing environment, the method
comprising:
categorizing the IT infrastructure of the enterprise into a plurality of Lines of Businesses (LoB), each of the LoBs representing at least a business function, business sponsors, and technologies used therein, wherein each of the LoBs includes a plurality of applications and corresponding databases;
abstracting selected applications from the LoBs at a database layer of the applications to obtain applications separated from their databases; and
migrating the databases to a private cloud;
wherein the categorization, abstraction, and the migration comprise implementing a plurality of factory methodologies, and wherein the factory methodologies are based at least on systematic reuse, model driven development, quality control, and cost reduction.
2. The method as claimed in claim 1, wherein the categorizing includes:
assessing the plurality of applications and corresponding databases to ascertain requirements of the applications and the technologies in the cloud computing environment;
generating an application bibliography based on the assessing, wherein the application bibliography includes at least a business function, LoB, business sponsor, and technologies associated with each of the plurality of applications;
publishing a support calendar for each of the technologies, wherein the support calendar is indicative of a future support by respective vendors for enterprise technology planning; and
creating a technology and version compatibility mapping based on the assessment and the support calendars, wherein the technology and version compatibility mapping includes details of computing hardware and the technologies associated with each of the

plurality of LoBs, and database compatibilities of the computing hardware and technologies.
3. The method as claimed in claim 2, wherein the method further comprises deriving estimation factors based on the support calendars, and the technology and version compatibility mapping, and identifying old and outdated computing hardware and technologies based on the estimation factors.
4. The method as claimed in claim 2, further comprising selecting applications, based on the application bibliography, for migration to the cloud computing environment.
5. The method as claimed in claim 1, further comprising migrating the databases from the private cloud to a public cloud, based on an outcome of the migration to the private cloud.
6. The method as claimed in claim 1 wherein the implementing comprises:
identifying repeatable tasks in existing application functionality;
implementing said repeatable tasks in a service line, wherein the service line assists in performing the repeated task or tasks in sequential stages of progression; and
performing a six sigma analysis, and a feedback collation on the service line.
7. A Cloud migration system (102) for migration of an enterprise to a cloud computing
environment, the Cloud migration system (102) comprising:
a processor (202); and
a memory (206) coupled to the processor (202), the memory (206) comprising:
a consolidation module (212) configured to categorize the enterprise into a plurality of Lines of Businesses (LoB), based on at least a business function, business sponsors, a plurality of applications, and technologies utilized therein;
an abstraction module (110) configured to abstract applications at a database layer to obtain application functionality separate from their associated databases, wherein each of the LoBs includes the applications; and
a factory methodology module (112) configured to implement a plurality of factory methodologies during the migration of the enterprise to the cloud

computing environment, wherein the plurality of factory methodologies are based at least on systematic reuse, model driven development, quality control, and cost reduction.
8. The Cloud migration system (102) as claimed in claim 7, wherein the consolidation
module (212) is further configured to:
assess each of the plurality of applications and technologies, to ascertain requirements of the applications in the cloud computing environment.
9. The Cloud migration system (102) as claimed in claim 8, wherein the consolidation
module (212) is further configured to:
generate an application bibliography based on the assessment, wherein the application bibliography includes at least a business function, LoB, business sponsor, and technologies of each of the plurality of applications;
publish a support calendar for each of the technologies; and
create a technology and version compatibility mapping based on the assessment and the support calendars, wherein the technology and version compatibility mapping includes details of computing hardware and the technologies associated with each of the plurality of LoBs, and database compatibilities of the computing hardware and the technologies.
10. The Cloud migration system (102) as claimed in claim 9, wherein the consolidation
module (212) is further configured to:
derive a plurality of estimation factors for current or future upgrade requirements of the computing hardware and technologies, based on the support calendars, and the technology and version compatibility mapping.
11. The Cloud migration system (102) as claimed in claim 10, wherein the consolidation module (212) is further configured to transform incompatible applications to render them compatible with the cloud computing environment.
12. The Cloud migration system (102) as claimed in claim 7, wherein the cloud computing environment is one of a private cloud, a public cloud, or a hybrid cloud.

13. The Cloud migration system (102) as claimed in claim 7, wherein the abstraction module (110) is further configured to migrate the databases to a private cloud.
14. The Cloud migration system (102) as claimed in claim 7, wherein the factory methodology module (112) is further configured to identify repeatable tasks in existing application functionality, and implement said repeatable tasks in a service line, wherein the service line assists in performing the repeated task or tasks in sequential stages of progression.
15. The Cloud migration system (102) as claimed in claim 7, wherein the factory methodology module (112) is further configured to perform a six sigma analysis, and a feedback collation on a service line.
16. A computer-readable medium having embodied thereon a computer program for executing a method comprising:
categorizing an enterprise into a plurality of Lines of Businesses (LoB), each of the LoBs representative of at least a business function, business sponsors, and technologies used therein;
abstracting selected applications from the LoBs at a database layer of the applications to obtain applications separated from their databases;
migrating the databases to a private cloud; and
implementing a plurality of factory methodologies during the categorization, abstraction, and the migration, wherein the factory methodologies are based at least on systematic reuse, model driven development, quality control, and cost reduction.