Patent Publication Number: US-2022237154-A1

Title: System and method for database migration in an application environment migration

Description:
FIELD OF THE INVENTION 
     The present disclosure generally relates to the field of computers, more specifically the present disclosure relates to a system and method for database migration in an application environment migration which allows a database to be automatically migrated from an older environment to a newer and faster environment without the cumbersome hassle and time being taken by users, while maintaining structural soundness and quality standards. 
     BACKGROUND OF THE INVENTION 
     With the changing times, technology has also changed and from the invention of the wheel, we now stand at an era where commute can be ordered through a mobile device. In such, technology has taken a huge leap from times that computers were as big as ballrooms to now when they are as small as a thumbnail. Little by little, we carved technology to help the human race by way of multiple applications. In this ever-changing and ever-reforming field of technology, the application environments keep improving and there arises a necessity to keep updating the applications to better-suit their advanced requirements. 
     Conventionally, databases of an application environment were migrated onto newer environments by completely reproducing the database in accordance with the newer environment which was time-taking and did not provide much benefit of the already existing database. With quicker environment updates, there has been inadequate time to update databases manually since by the time a database gets migrated to a newer environment, a newer one would be released. Further, migrating database to different environments also came with its own unique challenges including but not limited to assuring the links does not get lost during transformation, and that the migration corresponds to the older and newer environments. 
     Cloud adoption has become mainstream with enterprises leveraging Cloud as a key part of their IT strategy. This is evident from the year on year growth of leading cloud providers like AWS, Azure and GCP over the last 3 years. As a first phase these enterprises have successfully adopted cloud by developing new applications on cloud using cloud native design principle and hosting databases on cloud database solutions. Having realized success with that, enterprises are now looking for ways to migrate rest of their important applications on cloud to realize broad benefits of cloud. The challenge however is migrating existing applications to cloud poses a different set of issues, for example what is the right cloud migration approach, balancing of risk, cost and timeline to complete the cloud migration, complexity of existing applications especially old databases or applications without an SME, maximize total cost of ownership (TCO) savings and increase productivity for future releases, execution speed, enhanced performance, and the like. 
     Due to the complex parameters and effort required in migrating databases and application environments, along with the crunch in time with regular updates, there exists a need for developing a system and method for database migration in an application environment migration which migrates a database from one environment to another without or minimally requiring manual assistance while addressing the variety of issues associated with the database, and its components. 
     SUMMARY OF THE INVENTION 
     This summary is provided to introduce concepts related to systems and methods for database migration in an application environment migration and the concepts are further described below in the detailed description. This summary is neither 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. 
     In one implementation, a method for database migration in an application environment migration is disclosed. The method comprising assessing, by a processor of an application server, a source database of a source application environment and ascertaining, by the processor, a quantum change for migrating database components of the source database to a target database and forecasting, by the processor, an assessment statistic, wherein the assessment statistic provides at least one functional readiness and a timeline to complete the migration of the database components of the source database. The method further comprising scanning, by the processor, the source database for identifying dependencies between the database components in form of database links and generating, by the processor, a re-factored database structure, wherein the re-factored database structure is generated by breaking the source database in accordance with the target database while retaining the database links. The method further comprising updating, by the processor, granular database components of the target database as per the forecasted assessment statistic and the re-factored database structure and migrating, by the processor, the source database to the target database, wherein the migration re-platforms the updated granular database components. 
     In yet another implementation, the method has the quantum change for migrating the source database to the target database calculated on the basis of the size and complexity of the source database. 
     In yet another implementation, the method has the re-factored database structure generated utilizing a continuous integration and deployment framework and an automated test framework. 
     In yet another implementation, the method has the assessment statistic provides at least one inhibitor to complete the migration of the source database. 
     In yet another implementation, the method has scanning the source database includes scanning connections between the database components of the source database. 
     In yet another implementation, the method has the re-factored database structure generated in accordance with the target database while retaining connections between the database components of the source database. 
     In yet another implementation, the method has the re-factored database structure identified by an AI Engine. 
     In another implementation, the method comprises, migrating, by the processor, dictionaries and keywords from the source application environment in accordance with the target application environment. 
     In another implementation, the method comprises, implementing, by the processor, scripts from the source application environment in accordance with the target application environment. 
     In another implementation, the method comprises, accessing, by the processor, an application code comprising a business logic, links, rule engines, libraries of available environments, standard tools, and coding languages. 
     In yet another implementation, the method has the source database of an application environment migrates to the target database comprising the steps of: a source to target database re-development, a source to target database re-factoring, a source to target database re-hosting, and a source to target database re-platforming. 
     In one implementation, a system for database migration in an application environment migration is disclosed. The system comprises a processor and a memory coupled to the processor, wherein the processor executes a plurality of modules stored in the memory. The plurality of modules further comprising an assessment module, for assessing a source database of a source application environment and ascertaining a quantum change for migrating database components of the source database to a target database, wherein the assessment module forecasts an assessment statistic that provides at least one functional readiness and a timeline to complete the migration of the database components of the source database. The plurality of modules further comprises a re-factor module, for scanning the source database for identifying dependencies between the database components in form of database links and generating a re-factored database structure wherein the re-factored database structure is generated by breaking the source database in accordance with the target database while retaining the database links. The plurality of modules further comprises a re-platform module, for updating granular database components of the target database as per the forecasted assessment statistic and the re-factored database structure and migrating the source database to the target database, wherein the migration re-platforms the updated granular database components. 
     In yet another implementation, the system has the quantum change for migrating the source database to the target database calculated on the basis of the size and complexity of the source database. 
     In yet another implementation, the system has the re-factored database structure generated utilizing a continuous integration and deployment framework and an automated test framework. 
     In yet another implementation, the system has the assessment statistic provides at least one inhibitor to complete the migration of the source database. 
     In yet another implementation, the system has scanning the source database includes scanning connections between the database components of the source database. 
     In yet another implementation, the system has the re-factored database structure generated in accordance with the target database while retaining connections between the database components of the source database. 
     In yet another implementation, the system has the re-factored database structure is identified by an AI Engine. 
     In another implementation, the system comprises the re-factor module further comprising: migrating, by the processor, dictionaries and keywords from the source application environment in accordance with the target application environment. 
     In another implementation, the system comprises the re-platform module further comprising: implementing, by the processor, scripts from the source application environment in accordance with the target application environment. 
     In another implementation, the system comprises the plurality of modules further executes accessing, by the processor, an application code comprising a business logic, links, rule engines, libraries of available environments, standard tools, and coding languages. 
     In yet another implementation, the system has the source database of an application environment migrates to the target database comprising the steps of: a source to target database re-development, a source to target database re-factoring, a source to target database re-hosting, and a source to target database re-platforming. 
     It is primary object of the subject matter to provide a system and method for database migration in an application environment migration that may be used to migrate an application from one platform to another and more specifically, it may be used to migrate a database from an older environment to a newer environment. The system and method for database migration in an application environment migration may be customized based on the database to be migrated as well as the environments including the older environment the database is developed in and the newer environment to which the database has to be migrated. 
     It is another object of the subject matter to provide a database migration in an application environment migration that caters to a number of databases while retaining their database links. Furthermore, the system and method for database migration in an application environment migration may be able to migrate the selected database to be migrated from a wide range of environments to another wide range of environments. 
     It is another object of the subject matter to provide a system and method for database migration in an application environment migration that migrates a database environment in an automated manner without the requirement of manual inputs. 
     It is another object of the subject matter to provide a database migration in an application environment migration that reduces the time and effort taken by development teams to migrate a database from an older environment to a newer environment, by eliminating the repeatable patterns of work done by the development team, thereby also reducing costs. 
     It is another object of the subject matter to provide a database migration in an application environment migration that can be utilized by development teams to migrate an existing database from an older environment to a newer environment. 
     It is another object of the subject matter to provide a database migration in an application environment migration that behaves like a parser which studies an existing chunk of database, analyses it, processes it and thereafter repackages/re-platforms it. 
     It is another object of the subject matter to provide a database migration in an application environment migration that can be utilized for migrating a database from an older environment like Oracle/DB2/Sybase, to a newer environment like Azure SQL/Postgres etc. cloud based solutions. 
     It is another object of the subject matter to provide a database migration in an application environment migration that migrates database from an older environment to a newer one by reducing implementation costs, reducing total cost of ownership thereby increasing profitability, increasing the execution speed, enhancing the application&#39;s performance and enhancing the application&#39;s productivity. 
     It is another object of the subject matter to provide a number of advantages depending on the particular aspect, embodiment, implementation and/or configuration. 
     It is another object of the subject matter to provide a platform that can provide reliable execution, scalability, and value-added services, while controlling operating effort and costs. 
     It is another object of the subject matter to efficiently manage numerous instances simultaneously, work in different regulatory requirements, enable resources to collaborate and work together closely, efficiently and collectively with user friendly interfaces. 
     These and other implementations, embodiments, processes and features of the subject matter will become more fully apparent when the following detailed description is read with the accompanying experimental details. However, both the foregoing summary of the subject matter and the following detailed description of it represent one potential implementation or embodiment and are not restrictive of the present disclosure or other alternate implementations or embodiments of the subject matter. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       A clear understanding of the key features of the subject matter summarized above may be had by reference to the appended drawings, which illustrate the method and system of the subject matter, although it will be understood that such drawings depict preferred embodiments of the subject matter and, therefore, are not to be considered as limiting its scope with regard to other embodiments which the subject matter is capable of contemplating. Accordingly: 
         FIG. 1  illustrates a schematic module diagram depicting a method of database migration in an application environment migration, in accordance with an embodiment of the present subject matter. 
         FIG. 2  illustrates a system diagram describing the working of an exemplary database migration system in an application environment migration system, in accordance with an embodiment of the present subject matter. 
         FIG. 3  illustrates an exemplary assessment report automatically generated by an exemplary database migration system in an application environment migration system, in accordance with an embodiment of the present subject matter. 
         FIG. 4  depicts an exemplary view of an exemplary database migration in an application environment migration method, in accordance with an embodiment of the present subject matter. 
         FIG. 5  depicts an exemplary view of an exemplary database migration in an application environment migration method, in accordance with an embodiment of the present subject matter. 
         FIG. 6  illustrates an exemplary flowchart of a method of database migration in an application environment migration, in accordance with an embodiment of the present subject matter. 
         FIG. 7  illustrates another exemplary flowchart of a method of database migration in an application environment migration, in accordance with an embodiment of the present subject matter. 
     
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
     The following is a detailed description of implementations of the present disclosure depicted in the accompanying drawings. The implementations are in such detail as to clearly communicate the disclosure. However, the amount of detail offered is not intended to limit the implementations but it is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the present disclosure. While aspects of described systems and methods for database migration in an application environment migration 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). 
     The present disclosure provides a database cloud re-platforming from a source database of a source application environment to a target database of a target application environment. The cloud re-platform of databases involves migrating an existing on-premise database to cloud to make the source database of the source application environment work efficiently by taking advantage of scalability and elastic features of cloud. The source database of the source application environment structure will also be modified to reduce a total cost of ownership (TCO) of these databases which involve adopting more open source and cloud friendly software to remove a licensing cost for virtual machines, application server and databases. Actual TCO reduction will vary from database to database and determined after the source database assessment. The present disclosure lists a few important steps to be performed in database, although they may vary from database to database, modify existing database to work effectively on Cloud Platform or PaaS, all blocker related to source and on-premise design patterns will be changed, all underlying links, connections, libraries will be upgraded to make the source database compatible with container or PaaS, application servers (Weblogic, WebSphere, JBoss, . . . ) and databases may be replaced with open source cloud friendly software, monolith application may be de-coupled into smaller macro services for efficiency and velocity, monolith databases may be re-factored and re-platformed in target cloud databases. 
     The present disclosure provides a mechanism for cloud re-platforming by simple containerization involves removing all code blockers that impede containerization and deploy a source application in a container like Docker to make it work on Cloud. Further, the source application release process will also be automated which involves, test case and CI/CD automation. Still further, the source application and/or the source database may also be re-platformed to a lightweight open source server like Tomcat for JAVA applications and a legacy DB2 database to reduce the TCO of these applications by eliminating the license cost and reducing the compute cost on cloud. However, to guarantee stability and performance the monolith application will have to be broken down to smaller services or refactored database structure, make all of these applications stateless and deploy them into separate Tomcat servers with each deployed in a separate container. Thus, the source application will be migrated to a target application platform by decoupling the monolith application and exposing it through APIs by using macro-services concepts to make it cloud ready application. Along with breaking monolithic application into macro-services, CI/CD will also be implemented to achieve the fast and automated deployment. It runs DB re-platforming that includes re-factor DB keyword to Postgres DB keyword generating a re-factored database structure. Further, it uses a script generator that generates an Azure Postgres DDL SQL script and an Azure Postgres DML SQL Script, uploads DDL and DML to target Azure Postgres and debugs &amp; corrects errors to make the Azure Postgres DB Ready. A component wise structure and a step wise method is listed below. 
       FIG. 1  illustrates a schematic module diagram  100  depicting a method of database migration in an application environment migration, in accordance with an embodiment of the present subject matter. 
     In one implementation, a database migration in an application environment migration system  120  implements a method for database migration in an application environment migration on a server  102 , the system  120  includes a processor(s)  122 , interface(s)  124 , framework(s)  150 , an AI Engine  152 , and a memory  126  coupled or in communication to the processor(s)  122 . The processor(s)  122  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 database migration instructions. Among other capabilities, the processor(s)  122  is conFIGd to fetch and execute computer-readable instructions stored in the memory  126 . The framework  150  includes but not limited to a continuous integration and continuous deployment framework, an automated test framework, and the like. The AI Engine  152  including but not limited to a database (DB) re-platform engine, an app re-platform engine, a batch and scheduler re-platform engine, a message broker re-platform engine, an open source AI engine, and the like. 
     Although the present disclosure is explained by considering a scenario that the system is implemented as an application on a server, the systems and methods can be implemented in a variety of computing systems. The computing systems that can implement the described method(s) include, but are not restricted to, mainframe computers, workstations, personal computers, desktop computers, minicomputers, servers, multiprocessor systems, laptops, tablets, SCADA systems, smartphones, mobile computing devices and the like. 
     The interface(s)  124  may include a variety of software and hardware interfaces, for example, a web interface, a graphical user interface, etc., allowing the system  120  to interact with a user. Further, the interface(s)  124  may enable the system  120  to communicate with other computing devices, such as web servers and external data servers (not shown in FIG). The interface(s)  124  can facilitate multiple communications within a wide variety of networks and protocol types, including wired networks, for example LAN, cable, etc., and wireless networks such as WLAN, cellular, or satellite. The interface(s)  124  may include one or more ports for connecting a number of devices to each other or to another server. 
     A network used for communicating between all elements in application server and cloud environment may be a wireless network, a wired network or a combination thereof. The network 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 the like. The network may either be a dedicated network or a shared network. The shared network 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, Wireless Application Protocol WAP, and the like, to communicate with one another. Further the network may include a variety of network devices, including routers, bridges, servers, computing devices. The network further has access to storage devices residing at a client site computer, a host site server or computer, over the cloud, or a combination thereof and the like. The storage has one or many local and remote computer storage media, including one or many memory storage devices, databases, and the like. 
     The memory  126  can include any computer-readable medium known in the art including, for example, volatile memory (e.g., RAM), and/or non-volatile memory (e.g., EPROM, flash memory, etc.). In one embodiment, the memory  126  includes module(s)  128  and system data  140 . 
     The modules  128  further includes an assessment module  130 , a re-factor module  132 , a re-platform module  134 , and other modules  136  including but not limited to a blocker assessment module, a script generator module and the like. The script generator module further including but not limited to a test case generator a build script generator, a docker script generator, a pipeline script generator, a deployment script generator, and the like. It will be appreciated that such modules may be represented as a single module or a combination of different modules. Additionally, the memory  126  further includes system data  140  that serves, amongst other things, as a repository for storing data fetched, processed, received and generated by one or more of the modules  128 . The system data  140  includes, for example, operational data, workflow data, and other data at a storage  144 . The system data  140  has the storage  144 , represented by  144   a ,  144   b , . . . ,  144   n , as the case may be. In one embodiment, the system data  140  has access to the other databases over a web or cloud network. The storage  144  includes multiple databases including but not limited to an assessment module data, a re-factor module data, a re-platform module data, libraries, link identifiers, a database adapter, a database dictionary, a database parser, a technology dictionary, a file adapter, an application parser, a pattern recognizer, open source libraries, technology stack, and the like. It will be appreciated that such databases may be represented as a single database or a combination of different databases. In one embodiment data may be stored in the memory  126  in the form of data structures. Additionally, the aforementioned data can be organized using data models, such as relational or hierarchical data models. 
     The server  102  is further connected or connectable or a part of a cloud environment  110  that has a plurality of computing systems including but not limited to a target application environment server  104 , and an another target application environment server  106 , and databases including but not limited to a database  108 . It is imperative that the computing systems and databases communicate with each other under a cloud computing rules and also with the server  102  under the web or other available communication mediums/protocols. The computing systems of the target application server  104 ,  106  generally are distributed processing systems including multiple computing devices connected by and communicating over a network. Software applications may be run “in the cloud” by configuring them to execute across one or more of the computing devices in a particular cloud computing system. The computing devices of a cloud computing system may each execute separate copies of the software application, or, in some cases, the operations of the software application may be split among different computing devices and executed in parallel. A cloud computing system may include a plurality of cloud computing instances representing resources available for executing applications. Each instance may be a physical computing device having particular capabilities (storage size, processing speed, network bandwidth, etc.), or may be a virtual computing device having particular capabilities. A particular cloud computing system may offer different instance types having different sets of capabilities for executing software applications. 
     In one implementation, at first, a user including but not limited to a migration professional, a database administrator, an application developer, a quality analyst or a test professional may use a user access device to access the system  120  via the interface  124  using the server  102 . The working of the system  120  and related method and associated modules, sub modules, methods may be explained in detail also using  FIG. 2 ,  FIG. 3 ,  FIG. 4 ,  FIG. 5 ,  FIG. 6 , and  FIG. 7  explained below. 
     In one embodiment, the system  120  receives a user instruction data through the interface  124  on the server  102 . The modules  128  of the system  120  processes the instructions using the processor  122  while using the system data  140 , the other modules  136 , the frameworks  150  and supporting components. The assessment module  130  for database migration in an application environment migration is utilized before initiating the migration of a database from one environment to another. The assessment module  130  performs an assessment of a source database of a source application environment to ascertain an in-depth understanding of a quantum change the source database of the source application environment will have to undergo while assessing the risk, costs, timeline as well as the impact the change would make to other dependent applications to migrate to a target database of a target application environment. The assessment module  130  understands the underlying database links, connections, dependencies developed by various developers having a variety of styles. Furthermore, a forecasted assessment report  302  generated by the assessment module  130  using the AI engine  152  provides in-depth details regarding but not limited to a timeline required, a percentage of database components/structure that needs to be changed, a plurality of readiness parameters, a plurality of inhibitors or code blockers and warnings along with the reason, highlighted portions where database components needs to be modified, number of services a monolith can be broken into, the kind of services a monolith may be broken into and the readiness of the database for continuous integration and continuous deployment. The assessment report  302  generated by the assessment module  130  provides an accurate estimate and timeline to complete the migration of the source database of the source application environment. In one embodiment, an RPA bot is conFIGd to generate an assessment report  302  using a proactive database migration of an application environment migration forecasting (PAEMF) algorithm. In one embodiment, the RPA bot is a software bot or a combination of a software and hardware bot. In an embodiment, the software bot is a computer program enabling a processor to perform robotic process automation by utilizing AI. In another embodiment, the bot has a combination of hardware and software, where the hardware includes memory, processor, controller and other associated chipsets especially dedicated to perform functions that enable robotic process automation for database migration in an application environment migration. 
     The re-factor module  132  for database migration in an application environment migration supports the automated re-platforming for the source database migration in an application environment migration to the target database migration in an application environment migration by scanning the source database for identifying dependencies between the database components in form of database links and generates a re-factored database structure by breaking the source database in accordance with the target database while retaining the database links. The re-factor module  132  generates the re-factored database structure for the source application environment utilizing the continuous integration and deployment framework  150 , the automated test framework  150 , and middleware re-platform and environment-friendly design patterns. 
     The re-platform module  134  for database migration in an application environment migration supports the automated re-platforming for the source database migration in an application environment migration to the target application environment to transform a database from one environment to another on the basis of the size of the database as well as its complexity. The re-platform module  134  updates granular database components of the target database as per the forecasted assessment statistic and the re-factored database structure and migrates the source database to the target database to re-platform the updated granular database components. The re-platform module  134  also perform activities including but not limited to integrating patterns of the source application environment with design patterns of the target application environment, fine-tuning the code, resolving deployment issues, implementing security in order to ascertain the migrated application to be fully functional, and the like. The re-platform module  134  assists in multiple forms of environment migration including but not limited to a re-hosting environment migration, a database re-platforming, a database re-factoring and a native database development, and the like. 
     The blocker assessment module of the other modules  136 , any application like a monolithic web application having on-premise design patterns may be inputted in the system and method for database migration in an application environment migration wherein the blocker assessment module of the system and method for database migration in an application environment migration may discover patterns in the on-premise design patterns of the monolithic web application. Furthermore, this information may be transferred to the automated re-platforming module of the system and method for database migration in an application environment migration as per  FIG. 1 . 
     The reference architecture of the system  120  further has the supporting components, such as, test generator—test generator generates the test case for unit, functional and performance test cases for generated API. Build Script Generator—build script generator generates the scripts to successfully build and run the application. Docker Script Generator—Docker script generator generates the scripts to containerize the application and its dependencies. Pipeline Script Generator—pipeline script generator generates the scripts to create the CI/CD pipeline for dev, test and prod environments. Deployment Script Generator—deployment script generator generates the scripts to deploy the applications to the target environment. Database Adapter—database adapter utility establishes the connectivity to multiple database servers such as IBM DB2, Oracle, Microsoft SQL Server, Sybase ASE and PostgreSQL. Database Dictionary—database dictionary contains vast database related keywords and built-in functions used by the multiple database servers mentioned above. Database Parser—database parser parses the database objects by using the database dictionary to find the patterns which are not compatible with the target database. AI Engine—AI engine identifies the existing and potential macro/micro services in the legacy application. DB Re-platform Engine—DB re-platform engine re-platforms the source database objects such as tables, constraints, sequences, triggers, functions procedures etc. to the target database compatible objects. File Adapter—file adapter provides access to the source files of the application. the files are scanned to prepare the report and eventually re-platformed as the target application. Technology Dictionary—technology dictionary contains vast technology related patterns used inside the monolith applications. Application Parser—application parser parses the application source code with the help of pattern recognizer to find out the whole inventory of the technologies the application is using. this inventory is used for the assessment and re-platforming. Pattern Recognizer—pattern recognizer recognizes the pattern based on the technology dictionary to find the technologies used in the application. App Re-platform Engine-App re-platform engine re-platforms the source application which was parsed by the application parser. this engine generates the application which is ready to be deployed to the cloud. Technology Stack including but not limited to JAVA 1.8; Maven; JUnit, NUnit, XUnit JMeter; Docker Jenkins; AWS CLI, Azure CLI, and the like. 
       FIG. 2  illustrates a system diagram  200  describing the working of an exemplary database migration system in an application environment migration system, in accordance with an embodiment of the present subject matter. 
     The present disclosure depicts two important activities which are a source application environment assessment and a source database transformation to the desired target platform. These two activities are explained below in the flowchart  200 . 
     In one embodiment, a monolith web application  202 , such as a JAVA application or a .NET application, is a source application of a source application environment. The monolith web application  202  is linked to various supporting components  204 , including but not limited to, databases, batch, integration, App, scheduler, message broker, and the like. Functioning of a source database  204  linked to the source application environment is further detailed out. 
     In a first step, a cloud blocker assessment  206  assess the source application and generates an assessment report  212  comprising code impediments, source code insights, and on-premise design patterns  214 . The cloud blocker assessment  206  also assess the source database and generates an assessment report  212  comprising database connections, links and dependencies. The on-premise design patterns  214  further including, but not limited to EJB, RMI, STRUTS/SPRING, SOAP/XML, JSP/ASP, COM/COM++, ESB, and the like. The assessment of the source application involves technology stack of the current applications and code analysis. The assessment provides automated insights into the time, effort and risk involved in re-platforming the source application, the source database, and other supporting components. The assessment includes analysis of the source database components, where it performs an automated assessment of the source database  204  including links, connection and other dependencies and identifies the inhibitors or blockers (Packages/Frameworks/API/Libraries etc.) 
     which will fail the containerized cloud migration of the database and readiness parameters and thereby provides the detailed assessment report  212  further detailed as the assessment report  302 . It performs this code assessment for entire source application ecosystem including applications, databases, batch programs and schedulers, integration message brokers, build and deployment modules. The cloud blocker assessment  206  gets an in depth understanding of the quantum of changes the source application environment will have to go through to assess the risk, cost, timeline and the impact to other dependent components and applications. The report primarily provides percentage of code that needs to be changed, code readiness, blockers and warnings along with the reason, exact places where the code needs to be modified, number of services into which the monolith can be broken down, DevOps and CI/CD readiness, and a timeline for such execution. 
     In the next step, an automated transformation/re-platforming  208  for application and supporting components re-platforming from a source environment to a target environment is performed to generate a cloud ready application and supporting components  210 , such as a JAVA application or a .NET application, an Oracle database or a DB2 database comprising of a continuous integration and deployment framework  216 , an automated test framework  218 , a middle ware re-platform  220 , and cloud friendly design patterns  222  after re-factoring a source database of the source application environment while retaining database links of the source database in the target application environment. The sub-steps in automated re-platforming  208  is to upgrade database connections, interdependencies, links and other supporting components, convert all database components from source DB like Oracle, Sybase, DB2 and SQL Server to a cloud friendly database like Postgres or My SQL. All of the components will be transformed to work in the target DB and to achieve the same desired result as in the source DB. Once the database components are converted, it executes steps of breaking the source database in to granular components based on the design of the target application environment, fine tuning the rules, resolving deployment issues and, implementing security would be completed by the consultants to make the target database fully functional. In one example, Table A and Table B may be used as an example to illustrate an exemplary code transformation. 
     
       
         
           
               
             
               
                 TABLE A 
               
             
            
               
                   
               
               
                 Exemplary code transformation features 
               
            
           
           
               
               
               
            
               
                 S. No. 
                 Source Technology 
                 Target Technology 
               
               
                   
               
            
           
           
               
               
               
            
               
                 1 
                 Session EJB 
                 Spring Boot 
               
               
                 2 
                 Entity EJB 
                 JPA 
               
               
                 3 
                 Message driven EJB 
                 Spring JMS 
               
               
                 4 
                 Batch 
                 Spring batch 
               
               
                 5 
                 SOAP 
                 service SOAP service +REST end point 
               
               
                 6 
                 JAVA 
                 POJO service Spring boot with REST end points 
               
               
                 7 
                 .NET 
                 .NET Core 
               
               
                 8 
                 Telerik ORM 
                 Entity framework 
               
               
                 9 
                 Weblogic/Web 
                 Sphere Tomcat 
               
               
                 10 
                 Oracle/SQL 
                 Server/DB2 Postgres 
               
               
                   
               
            
           
         
       
     
     
       
         
           
               
             
               
                 TABLE B 
               
             
            
               
                   
               
               
                 Exemplary code generation features 
               
            
           
           
               
               
               
            
               
                   
                 S. No. 
                 Features 
               
               
                   
                   
               
               
                   
                 1 
                 API test automation 
               
               
                   
                 2 
                 Junit and Nunit test cases (asserts are manual) 
               
               
                   
                 3 
                 API Proxy (Zuul) 
               
               
                   
                 4 
                 0Auth2 authentication 
               
               
                   
                 5 
                 Cl/CD framework 
               
               
                   
                   
               
            
           
         
       
     
     Further, database cloud re-platforming involves several repetitive steps like database component analysis, refactoring, library upgrades, compiling build scripts, deployment scripts, containerization scripts etc. This results in significant improvement in Time to Market which in turn can reduce the overall cost and ensure high quality re-platforming. 
       FIG. 3  illustrates an exemplary assessment report  302  automatically generated by an exemplary database migration system in an application environment migration system, in accordance with an embodiment of the present subject matter. 
     In one embodiment, an assessment module  130  generates an assessment report  302  after assessing a source application environment comprising code impediments, source code insights, database links, connections, and on-premise design patterns  214 . The assessment report  302  provides automated insights into the time, effort and risk involved in re-platforming the source application environment. 
     The assessment includes analysis of database components, where it performs an automated assessment of the source database including links, connection and other dependencies and identifies the inhibitors or blockers (Packages/Frameworks/API/Libraries etc.) which will fail the containerized cloud migration of the database and readiness parameters and thereby provides a detailed assessment report  302 . The generation of the report is an automated process along with a few user configurations based on the source application and target application environment. 
     The assessment report  302  gets an in depth understanding of the quantum of changes that the source database will have to go through to assess the risk, cost, timeline and the impact to other dependent components and databases in form of readiness parameters  304  and a visual composition  306 . The quantum of changes is summation of all changes required in the database migration. The assessment report has various sections, a few exemplary illustrations for an application snapshot includes parameters, such as a containerization readiness  304   a , a re-platform readiness  304   b , a DevOps Readiness  304   c , a Macro/Micro API readiness  304   n , a scheduler re-platform readiness  304   n , a batch readiness, a message broker readiness, a DB re-platform readiness  304   n , among others. Each of the parameters shows a readiness state in percentage (%) or the like to showcase how much ready and/or how much not-ready/blocking/inhibitor states are present for the respective parameter. For example, the containerization readiness  304   a  shows a container ready percentage with a readiness state and a refactoring required/inhibitor percentage, the re-platform readiness  304   b  shows a Tomcat ready percentage with a readiness state and a refactoring required/inhibitor percentage, the DevOps Readiness  304   c  shows a CD ready percentage with a readiness state and a CI readiness/inhibitor percentage, the Macro/Micro API readiness  304   n  shows a Macro API existing pointer with a readiness state and a Micro API existing/inhibitor state, the scheduler re-platform readiness  304   n  shows a re-platform readiness percentage with an AWS batch readiness state and an Azure Logic App ready/inhibitor percentage, and the DB re-platform readiness  304   n  shows a re-platform readiness percentage with a PostgresSQL readiness state and a refactoring required blocker/inhibitor percentage, and the like. One of the other section of the report is the visual composition  306 , such as a database object spread [#Objects]  306   a , a database object spread [#LoC]  306   b , a platform composition by Number  306   n , a platform composition by LoC  306   n , and the like. In one example, the database object spread [#Objects]  306   a  depicts a spread or count or percentage of triggers, sequences, packages, procedures, views, materialised views, functions and tables, the database object spread [#LoC]  306   b  depicts a spread or count or percentage of triggers, sequences, packages, procedures, views, materialised views, functions and tables, the platform composition by Number  306   n  depicts a spread or count or percentage of JMS, XML configuration, Web services, Maven build, configuration, HTML, Servlet, Style sheet, reactJS, JSP, Junit, POJO, the platform composition by LoC  306   n  depicts a spread or count or percentage of JMS, XML configuration, Web services, Maven build, configuration, HTML, Servlet, Style sheet, reactJS, JSP, Junit, POJO, and the like. 
     Further in one example, various sections of the assessment report  302  provides following information sections application snapshot consist of framework/libraries/packages used, application containerization readiness, application server re-platforming readiness to Tomcat or Kestrel application server, database server re-platforming readiness to PostgreSQL or alike, containerization readiness (to Docker/Kubernetes), CI/CD readiness (unit/functional/performance test case, build and continuous integration, automation available), macro and micro API candidates, API readiness (existing and potential API in the application). 
     The present method provides end to end transformational capabilities by assessing the source application environment, followed by transforming them to cloud using cloud friendly design patterns and finally manages this entire journey by providing your stakeholders and decision makers with transparent visibility for quick decision making. All application dependencies starting from databases to batch programs, schedulers to message brokers will be holistically transformed to cloud. In application analysis section of the assessment report  302  the method analyses the entire source application to identify blockers in source code including design patterns that inhibits cloud migration. All dependencies are also analysed to provide a holistic view for design and planning purposes. It discovers and analyse application components inventory, technology stacks and their dependencies, identify Application&#39;s business, data Services and their API readiness, identify the Containerization and Cloud Re-platforming blockers &amp; DevOps readiness and efforts for changes such as JAVA vX.X to JAVA v1.8; EJB (Session Bean/Entity Bean/MDB) to Spring Boot Service with Spring Framework (Pojo); .NET vX.X to .NET Core v2.2. 
     In database analysis section of the assessment report  302  the method analyses the database to analyse and discover database inventory, data objects details and database size, identify database re-platform readiness and blockers, identify the application blockers and dependencies for database re-platforming and efforts for changes such as Oracle/SQL Server/DB2/Sybase to Postgres/MySQL. In batch &amp; scheduler analysis section of the assessment report  302  the method analyses the batch &amp; scheduler, to analyse and discover batch program inventory and batch schedulers, identify batch scheduler re-platform readiness, blockers and dependencies, identify application batch services for batch re-platforming and efforts for changes such as Autosys/ControlM to AWS Batch (AWS Cloud)/Azure Logic App (Azure Cloud)/Quartz (Private Cloud). In message broker analysis section of the assessment report  302  the method analyses the message broker to analyse and discover message broker inventory and messaging objects, identify message broker re-platform readiness, blockers and dependencies, identify application blockers and dependencies for message broker re-platforming and efforts for changes such as TIBCO EMS/Rendezvous or WebLogic/Web Sphere or Message Queue or Sonic Message Queue to Active MQ. 
       FIG. 4  depicts an exemplary view  400  of an exemplary database migration in an application environment migration method, in accordance with an embodiment of the present subject matter. 
     In one embodiment, an application deployment view  400  with pre and post re-platforming is depicted using the method and system of a source database migration in an application environment migration to a target application environment, in accordance with an embodiment of the present subject matter. A monolith application is generally belonging to a source application environment residing or accessible by a server  102  transforms or migrates to a modernised re-platformed application belonging to a target application environment residing or accessible by a cloud environment  110 . Firstly, a code assessment  206  happens for the source application environment migration to the target application environment. Assessment of the application determines a quantum of change required in code change to remove and change code inhibitors for containerization. The migration is performed with following steps, an application web server with application as accessible by the server  102  is converted to web front instances  422   a ,  422   b , . . . ,  422   n  as the case may be. An application server (IIS cluster)  202  is further re-factored into API management layer  426  with various App macro-service instances  426   a ,  426   b ,  426   c , . . .  426   n . The macro-service instances are based on the size and complexity of the source application. In one implementation, a re-factor module  132  performs factoring and repackaging  208  of the macro services into the target application environment. 
     The source application database  204  is also re-factored PaaS/CaaS cluster  424   a  to a re-platformed granular database components  424   a , . . . ,  424   n  of a target database  424 . The web front instances  422   a ,  422   b , . . . ,  422   n  and the macro-service instances  426   a ,  426   b ,  426   c , . . .  426   n  are further linked to components, including but not limited to a service mesh, an AKS cluster, an App service, an ACI, and the like of the cloud computing environment  110 . In one implementation, a source Oracle database is migrated to a PostgresSQL database along with a container/orchestration platform of the cloud environment  110 . 
     Virtual machine instances  408   a ,  408   b , . . . ,  408   n  of the source application are migrated to container cluster of the cloud environment  110 . Thus, an on-premise data centre  410  of the source application environment  410  having an on-premise ecosystem  412  is re-platformed  210 /migrated to a private/public cloud  428  of the cloud environment  110 . In one implementation, components ( 412   a ,  412   b , . . . ,  412   n ) of the on-premise ecosystem  412 , including but not limited to, an EBS, a caching, local files, rules engines, a batch and scheduler, a message broker, an authentication protocol, security platforms, and the like are re-platformed  210 /migrated to private/public cloud  428  independent or standard services/components ( 430   a ,  430   b ,  430   c , . . . ,  430   n ) including but not limited to, Azure queues, Event Hub, Service Bus, AppInsights, Redis Cache, Storage, Vnet, Azure AD, and the like. 
     In one implementation, the method modifies existing on-premise application to work efficiently on cloud using a container or PaaS, upgrades or changes all blockers related to source code and design patterns and all underlying libraries to make them compatible with container or PaaS, application servers and database is re-platformed to reduce TCO, and monolith application may be de-coupled into services to improve efficiency and velocity. 
     In one example, Table C may be used as an example to illustrate a re-platforming migration. 
     
       
         
           
               
             
               
                 TABLE C 
               
             
            
               
                   
               
               
                 Exemplary As-Is State to To-Be State 
               
            
           
           
               
               
            
               
                 As-Is State 
                 To-be State 
               
               
                   
               
               
                 JSF, Tiles, Servlets, Struts 
                 JSF, Tiles, Servlets, Struts 
               
               
                 (EJB) Session 
                 Bean REST Client, Redis HttpSession Cache 
               
               
                 (EJB) Entity Bean,  
                 Tomcat Server 
               
               
                 Hibernate 
                 API Gateway 
               
               
                   
                 REST API 
               
               
                   
                 Spring Boot Macro Services 
               
               
                   
                 (ORM) JPA, Hibernate 
               
               
                 WebLogic 
                 App Server 12c Tomcat Server 9 
               
               
                 Oracle Database 12c 
                 PostgreSQL 
               
               
                   
               
            
           
         
       
     
     In one implementation, as-is state is JSP based UI to session EJB calls with a few data services and monolithic web application with commercial application server, session persistence and stateful services as-is and migrated to-be state is decoupled web application with JSF WebFront and RESTful Spring Boot macro-services on containers (independent scaling) over API gateway 
       FIG. 5  depicts an exemplary view  500  of an exemplary database migration in an application environment migration method, in accordance with an embodiment of the present subject matter. 
     In one embodiment, an exemplary database migration in an application environment migration method view  500  from pre to post re-platforming is depicted using the method and system of a source database migration in an application environment migration to a target application environment, in accordance with an embodiment of the present subject matter. A monolith source database is generally belonging to a source application environment residing or accessible by a server  102  transforms or migrates to a modernised re-platformed target database belonging to a target application environment residing or accessible by a cloud environment  110 . Firstly, the method accesses on-premise RDBMS or a source database  204  having database components, such as table &amp; view  204   a , sequences  204   b , procedure &amp; functions  204   c , triggers  204   d , and the like. The method executes assessment  502  that runs and performs an assessment to capture a full inventory of database components like tables, views, stored procedure, functions, DB links and others, size and complexity of the source database  204 , compatibility and risk associated with re-platforming to a cloud friendly target database  424  like Postgres and to break the monolith to granular components. Once this assessment is completed, the assessment step  502  generates an interactive HTML assessment report  302  with drill down features in a format that is easy to be consumed by technical and business users. The assessment report  302  ascertains a quantum change for migrating database components  204   a , . . . ,  204   n  of the source database  204  to a target database  424  and forecasts an assessment statistic  302  that provides functional readiness parameters, inhibitors, and a timeline to complete the migration of the database components  204   a , . . . ,  204   n  of the source database  204 . The assessment report  302  will be used by database architects and application SME to come up with a design for the new re-platformed database and corresponding application. The assessment step  502  also connects a keyword dictionary  512   a , and a DB dictionary  512   b.    
     A database such as a source database  204 , a re-factored database structure  506 , or a target database  424  respectively includes database components such as tables and views  204   a / 506   a / 424   a , sequences  204   b / 506   b / 424   b , procedures and functions  204   c / 506   c / 424   c , triggers  204   d / 506   d / 424   d  and the like. A table of table and view  204   a / 506   a / 424   a  is a collection of data elements organised in terms of rows and columns. A table is also considered as a convenient representation of relations. The one or more tables  204   a / 506   a / 424   a  may represent structured data schemas including one or more columns conFIGd to store data in one or more rows. The tables  204   a / 506   a / 424   a  may include constraints defining rules for data stored in a particular table, relations between different ones of the one or more tables  204   a / 506   a / 424   a  or other constraints. A view of table and view  204   a / 506   a / 424   a  is a subset of a database and is based on a query that runs on one or more database tables. Database views are saved in the database as named queries and can be used to save frequently used, complex queries. There are two types of database views: dynamic views and static views. A sequence  204   b / 506   b / 424   b  is a set of integers 1, 2, 3, . . . that are generated and supported by some database systems to produce unique values on demand. A procedure &amp; functions  204   c / 506   c / 424   c  is a group or set of SQL and PL/SQL statements that perform a specific task. A trigger  204   d / 506   d / 424   d  is a stored procedure in database which automatically invokes whenever a special event in the database occurs. A component  204   n / 506   n / 424   n  is another component of the database. It is to be noted that the terms  204   a , . . . n;  506   a , . . . n;  424   a , . . . n; cannot be interchangeably used as the same refers to components of a source database, a re-factored database, and a target database. The structures, interdependencies, method of storage database links, connections will be different depending on the database types used, the above is only depicted to show the general definitions of the various components that are part of such databases. The same will be input or developed as part of the present subject matter by due process of the system and method detailed here in. 
     In a next database transformation step to execute DB re-platforming  504 , the method will perform the following 2 main functions. First, re-factoring DB keyword to target DB keyword  506  by scanning the source database  204  for identifying dependencies between the database components  204   a , . . . ,  204   n  in form of database links and generating a re-factored database structure  506   a , . . . ,  506   n  by breaking the source database  204  in accordance with the target database  424  while retaining the database links. The method converts all database components from source DB like Oracle, Sybase, DB2 and SQL Server to a cloud friendly database like Postgres or My SQL. All of the components will be transformed to work in the target DB and to achieve the same desired result as in the source DB. Once the database components are converted, then the database is broken to granular components based on the design of the application. The method takes care to avoid data corruption and distributed transactional issues in the target application environment and helps to function properly. Secondly, re-platforming by updating granular database components  424   a , . . . ,  424   n  of the target database  424  as per the forecasted assessment statistic  302  and the re-factored database structure  506   a , . . . ,  506   n  and migrating the source database  204  to the target database  424  by re-platforming the updated granular database components  424   a , . . . ,  424   n . The target database  424  having database components, such as table &amp; view  424   a , sequences  424   b , procedure &amp; functions  424   c , triggers  424   d , and the like. The method uses a script generator  508  that generates a target database DDL SQL script  508   a , and a target database DML SQL Script  508   b  it further executes the steps including but not limited to reading the source DB, understand the DB Structure and generate AS IS Temp DDL and DML. Further, refactor DB keywords and syntaxes from target database dictionary and DDL and DML converted to target database format. It uploads DDL and DML to target database and debugs &amp; corrects errors to make the target database DB Ready. The SQL Scripts are loaded  510  to the target database and the target database  424  with the re-factored database structure  424   a , . . . ,  424   n  powered/managed by cloud. 
     In one example, a legacy DB re-platform to Azure SQL database execution steps include an on-premise RDBMS source database  204  Oracle/DB2/Sybase having database components, such as table &amp; view  204   a , sequences  204   b , procedure &amp; functions  204   c , triggers  204   d , and the like. The method executes assessment  502  that runs and performs an assessment to capture a full inventory of database components like tables, views, stored procedure, functions, DB links and others, size and complexity of Oracle/DB2/Sybase  204 , compatibility and risk associated with re-platforming to a cloud friendly target database  424  to Azure SQL and to break the monolith to granular components. An assessment  502  also lists down Oracle/DB2/Sybase keyword dictionary  502   a , and SQL Server DB dictionary  502   b . The assessment report  302  highlights the level of re-factoring required in the re-platforming to Azure SQL. It runs DB re-platforming  504  that includes re-factor DB keyword to SQL Server DB keyword  506  generating a re-factored database structure  506   a , . . . ,  506   n . The method uses a script generator  508  that generates an Azure SQL Server DDL SQL script  508   a , and an Azure SQL Server DML SQL Script  508   b  it further executes the steps including but not limited to reading the Oracle/DB2/Sybase, understand the Oracle/DB2/Sybase Structure and generate AS IS Temp DDL and DML. Further, refactor DB keywords and syntaxes from Oracle/DB2/Sybase dictionary and DDL and DML converted to Azure SQL Server format. It uploads DDL and DML to Azure SQL Server and debugs &amp; corrects errors to make the Azure SQL Server DB Ready. The SQL Scripts are loaded  510  to the Azure SQL Server and the Azure SQL Server  424  with the re-factored database structure  424   a , . . . ,  424   n  powered/managed by cloud. 
     In another example, a legacy DB re-platform to Azure Postgres database execution steps include an on-premise RDBMS source database  204  Oracle/DB2/Sybase having database components, such as table &amp; view  204   a , sequences  204   b , procedure &amp; functions  204   c , triggers  204   d , and the like. The method executes assessment  502  that runs and performs an assessment to capture a full inventory of database components like tables, views, stored procedure, functions, DB links and others, size and complexity of Oracle/DB2/Sybase  204 , compatibility and risk associated with re-platforming to a cloud friendly target database  424  to Azure Postgres and to break the monolith to granular components. An assessment  502  also lists down Oracle/DB2/Sybase keyword dictionary  502   a , and SQL Server DB dictionary  502   b . The assessment report  302  highlights the level of re-factoring required in the re-platforming to Azure Postgres. It runs DB re-platforming  504  that includes re-factor DB keyword to Postgres DB keyword  506  generating a re-factored database structure  506   a , . . . ,  506   n . The method uses a script generator  508  that generates an Azure Postgres DDL SQL script  508   a , and an Azure Postgres DML SQL Script  508   b  it further executes the steps including but not limited to reading the Oracle/DB2/Sybase, understand the Oracle/DB2/Sybase Structure and generate AS IS Temp DDL and DML. Further, refactor DB keywords and syntaxes from Oracle/DB2/Sybase dictionary and DDL and DML converted to Azure Postgres format. It uploads DDL and DML to Azure Postgres and debugs &amp; corrects errors to make the Azure Postgres DB Ready. The SQL Scripts are loaded  510  to the Azure Postgres and the Azure Postgres  424  with the re-factored database structure  424   a , . . . ,  424   n  powered/managed by cloud. The method provides a capability to understand the current DB components, structure and their dependencies and has the capability to transform the source database components to target components. 
       FIG. 6  illustrates an exemplary flowchart  600  of a method of database migration in an application environment migration, in accordance with an embodiment of the present subject matter. 
     In one implementation, a method  600  for database migration in an application environment migration is shown. The method 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. The method may also be practiced in a distributed computing environment where functions are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, computer executable instructions may be located in both local and remote computer storage media, including memory storage devices. The order in which the method is described and 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 alternate methods. Additionally, individual blocks may be deleted from the method without departing from the spirit and scope of the disclosure described herein. Furthermore, the method may be implemented in any suitable hardware, software, firmware, or combination thereof. However, for ease of explanation, in the embodiments described below, the method may be implemented in the above-described system. 
     At step/block  602 , assess a source database of a source application environment by a processor  122  of a system  120  of an application server  102 . In one implementation, the source database may be assessed by an assessment module  130  of the system  120 . 
     At step/block  604 , ascertain a quantum change for migrating database components of the source database to a target database. In one implementation, the quantum change may be ascertained by the assessment module  130 . 
     At step/block  606 , forecast an assessment statistic that provides at least one functional readiness and a timeline to complete the migration of the database components of the source database. In one implementation, the assessment statistic may be forecasted by the assessment module  130 . 
     Thus, the method  600  helps in database migration in an application environment migration by providing the forecasted assessment statistic and a timeline for migration from a source application environment to a target application environment. 
       FIG. 7  illustrates another exemplary flowchart  700  of a method of database migration in an application environment migration, in accordance with an embodiment of the present subject matter. 
     In one implementation, a method  700  for database migration in an application environment migration is shown. The method 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. The method may also be practiced in a distributed computing environment where functions are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, computer executable instructions may be located in both local and remote computer storage media, including memory storage devices. The order in which the method is described and 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 alternate methods. Additionally, individual blocks may be deleted from the method without departing from the spirit and scope of the disclosure described herein. Furthermore, the method may be implemented in any suitable hardware, software, firmware, or combination thereof. However, for ease of explanation, in the embodiments described below, the method may be implemented in the above-described system. 
     At step/block  702 , assess a source database of a source application environment by a processor  122  of a system  120  of an application server  102 . In one implementation, the source database may be assessed by an assessment module  130  of the system  120 . 
     At step/block  704 , ascertain a quantum change for migrating database components of the source database to a target database. In one implementation, the quantum change may be ascertained by the assessment module  130 . 
     At step/block  706 , forecast an assessment statistic that provides at least one functional readiness and a timeline to complete the migration of the database components of the source database. In one implementation, the assessment statistic may be forecasted by the assessment module  130 . 
     At step/block  708 , scan the source database for identifying dependencies between the database components in form of database links. In one implementation, the source database may be scanned by a re-factor module  132 . 
     At step/block  710 , generate a re-factored database structure by breaking the source database in accordance with the target database while retaining the database links. In one implementation, the re-factored database structure may be generated by the re-factor module  132 . 
     At step/block  712  update granular database components of the target database as per the forecasted assessment statistic and the re-factored database structure. In one implementation, the granular database components of the target database may be updated by a re-platform module  134 . 
     At step/block  714 , migrating the source database to the target database by re-platforming the updated granular database components. In one implementation, the source database may be migrated to the target database by the re-platform module  134 . 
     Thus, the method  700  helps in database migration in an application environment migration by providing a forecasted assessment, re-factoring the code and re-platforming the database for migration from a source application environment to a target application environment. 
     The present solution is used to re-platform complex database to cloud and deploy them in production environments. A few examples are shown using the method and system of the source database migration in an application environment migration to a target application environment, in accordance with an embodiment of the present subject matter. The following shows preparation, planning and execution along with outcome of the studies. In one example, a cloud re-platforming of JAVA Batch App for a leading secondary mortgage firm, a source application environment belongs to a leading secondary mortgage company providing mortgage-backed securities that is a multi-billion-dollar enterprise with operations in USA and is also a publicly traded firm. The primary business challenges are complex JAVA Batch application developed 10 years ago on Autosys &amp; EJB on WebLogic MQ by using Message Driven Bean EJB (MDB) Pojo Services, JDBC etc. alongside using Oracle database. This application is business-critical and handles key long-running processes. Non-availability of the key SME who developed this application posing challenges in cloud re-platforming. Using the present solution approach, the Oracle database was re-platformed to Postgres using the method steps, the Autosys Scheduler was re-platformed to Quartz and back-end EJB (MDB) were re-platformed to independent Spring JMS with Spring Boot/Batch Service Apps with REST end points. Each service App were then deployed on separate containers on AWS ECS VPC providing infinite scalability, high availability, high fault tolerance and improved performance. Centralized JOB dependencies of Autosys were refactored to self-managed dependencies using App specific quartz scheduler resulting in reduced operational complexity. Among the top benefits, TCO reduction by over 50%, mainly due to the elimination of WebLogic &amp; Autosys and also by containerization, increase in development productivity due to macro-services and CI/CD automation, total cost of implementation is reduced by over 50% using automation, implementation is to be completed in 6 weeks (the same would have taken 9 months if done manually). 
     In one another example, present solution is used for cloud re-platforming of .NET Web App for a leading us consulting firm, a source application environment belongs to one of the largest professional services and accounting audits with content management firms with employees in over 700 offices in 150 countries around the world. The primary business challenges are Complex .NET web application developed over the years using ASP .NET, C#, Telerik ORM alongside using SQL Server database. This application is business critical handling the key B2C function for a leading Professional Service provider. This task became more complicated due to the non-availability of key SME who developed this application. Using the present solution approach, the source application is to be broken into Web front-end and Service Back-end. The back-end legacy .NET services with Telerik ORM is re-platformed to independent .NET Core Service Apps with entity framework with REST End Points. The web front and each service App is then deployed in Kestrel &amp; NGINX on separate containers on Azure cloud providing infinite scalability, high availability, high fault tolerance and improved performance. The web front and macro services were made stateless with Redis cache. The service REST API end points were secured with oAuth2. Automated Testing+CI/CD was enabled for Web-Front and All Macro Services. Among the top benefits, re-platform resulted TCO reduction of over 45% mainly due to elimination of IIS &amp; Telerik ORM, total cost of implementation is reduced by over 45%, increased in development productivity due to macro services and CI/CD automation, completed in six weeks compared to 7 months if done manually. 
     Although implementations of system and method for database migration in an application environment migration have been described in language specific to structural features and/or methods, it is to be understood that the appended claims are not necessarily limited to the specific features or methods described. Rather, the specific features and methods are disclosed as examples of implementations for database migration in an application environment migration.