System and method for database migration in application environment migration - Patents.com

Abstract

The subject matter discloses a system and method for database migration in an application environment migration. In one embodiment, the method includes evaluating a source database (204) of a source application environment by a processor (122) of an application server (102). The processor (122) predicts evaluation statistics (302) that identify an amount of change for migrating database components (204a, ..., 204n) of the source database (204) to a target database (424) and provide at least one functional readiness (304) and a timeline (306) for completing the migration of the database components (204a, ..., 204n) of the source database (204). The processor (122) further scans the source database (204) to identify dependencies between the database components (204a, ..., 204n) in the form of database links, and generates a refactored database structure (506a, ..., 506n) by partitioning the source database (204) according to the target database (424) while preserving the database links, thereby updating the fine-grained database components (424a, ..., 424n) of the target database (424) according to the predicted evaluation statistics (302) and the refactored database structure (506a, ..., 506n), thus migrating the source database (204) to the target database (424), and the migration replatforming the updated fine-grained database components (424a, ..., 424n).

Description

[Technical Field]

[0001] FIELD OF THE INVENTION The present disclosure relates generally to the field of computers, and more particularly, to a system and method for database migration in application environment migration that allows a database to be automatically migrated from an older environment to a newer, faster environment without user hassle and time, while maintaining architectural integrity and quality standards.

[0002] As times change, so does technology, from the invention of the wheel, we now stand in an era where our commute can be ordered through a mobile device. Thus, technology has made a giant leap from an era where computers were as big as ballrooms to the current era where they are as small as a thumbnail. Little by little, we have carved out technologies that help mankind through multiple applications. In this ever-changing and ever-changing field of technology, the application environment keeps improving, and with these advanced requirements, applications need to be kept updated.

[0003] Traditionally, the database of an application environment has been migrated to a newer environment by completely recreating the database for the newer environment, which is time-consuming and does not provide much benefit to the existing database. As environments update more rapidly, newer versions are released by the time the database is migrated to the newer environment, leaving insufficient time to manually update the database. Additionally, migrating a database to a different environment presented its own challenges, including, but not limited to, ensuring that links are not lost during the conversion and ensuring a compatible migration between the older and newer environments.

[0004] Cloud adoption has become mainstream as enterprises leverage the cloud as a critical part of their IT strategies. This is evident in the year-over-year growth of major cloud providers such as AWS, Azure, and GCP over the past three years. In the initial phase, these enterprises successfully adopted the cloud by developing new applications in the cloud using cloud-native design principles and hosting their databases with cloud database solutions. Having realized this success, enterprises are now exploring how to migrate the remainder of those critical applications to the cloud to maximize the benefits of the cloud. However, the challenge is that migrating existing applications to the cloud presents another set of issues, such as determining the appropriate cloud migration approach, balancing risks, the cost and timeline for completing a cloud migration, the complexity of existing applications, especially older databases or applications without SMEs, maximizing total cost of ownership (TCO) savings, and increasing productivity, execution speed, and performance improvements for future releases.

[0005] Since database and application environment migration requires complex parameters and efforts, there is a need to develop a system and method for database migration in application environment migration that migrates a database from one environment to another without or with minimal manual assistance while addressing various issues related to the database and its components along with crunching in time for periodic updates. Summary of the Invention

[0006] This Summary is provided to introduce concepts related to systems and methods for database migration in application environment migration, which 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.

[0007] In one embodiment, a method for database migration in an application environment migration is disclosed, the method including: evaluating, by a processor of an application server, a source database of a source application environment; and, by the processor, executing a program for migrating database components of the source database to a target database. Quantitative change and predicting, by a processor, evaluation statistics, the evaluation statistics representing at least one step for completing the migration of the database component of the source database. Feature Readiness and providing a timeline. The method further includes scanning, by a processor, the source database to identify dependencies between database components in the form of database links, and generating, by the processor, a refactored database structure, the refactored database structure being generated by splitting the source database according to the target database while preserving the database links. The method further includes, by the processor, splitting the target database according to the predicted evaluation statistics and the refactored database structure. subdivided updating a database component; and migrating the source database to the target database by a processor, wherein the migrating includes: subdivided Replatforming database components.

[0008] In yet another embodiment, a method includes a step of migrating a source database to a target database calculated based on the size and complexity of the source database. Quantitative change It has.

[0009] In yet another embodiment, the method has the refactored database structure generated utilizing a continuous integration and deployment framework and an automated testing framework.

[0010] In yet another embodiment, the method includes evaluation statistics that provide at least one inhibitor to completing the migration of the source database.

[0011] In yet another embodiment, the method includes scanning a source database, including scanning connections between database components of the source database.

[0012] In yet another embodiment, the method includes generating a refactored database structure according to the target database while maintaining connections between database components of the source database.

[0013] In yet another embodiment, the method includes the refactored database structure being identified by the AI ​​engine.

[0014] In another embodiment, the method includes migrating, by a processor, dictionaries and keywords from a source application environment according to a target application environment.

[0015] In another embodiment, a method includes implementing, by a processor, a script from a source application environment according to a target application environment.

[0016] In another embodiment, a method includes accessing, by a processor, application code including business logic, links, a rules engine, libraries of available environments, standard tools, and coding languages.

[0017] In yet another embodiment, a method includes migrating a source database of an application environment to a target database including the steps of re-evolving the environment from the source to the target database, refactoring from the source to the target database, re-hosting from the source to the target database, and re-platforming from the source to the target database.

[0018] In one embodiment, a system for database migration in an application environment migration is disclosed, the system comprising a processor and a memory coupled to the processor, the processor executing a plurality of modules stored in the memory, the plurality of modules being configured to evaluate a source database of a source application environment and migrate database components of the source database to a target database. Quantitative change The evaluation module further includes an evaluation module for verifying at least one evaluation step for completing the migration of the database components of the source database. Feature Readiness and predicting evaluation statistics that provide a timeline. The plurality of modules further comprises a refactoring module for scanning the source database to identify dependencies between database components in the form of database links and generating a refactored database structure, the refactored database structure being generated by splitting the source database according to the target database while preserving the database links. The plurality of modules further comprises a refactoring module for splitting the source database according to the target database while preserving the database links. subdividedThe system further comprises a replatforming module for updating the database components and migrating the source database to the target database, wherein the migrating comprises: subdivided Replatforming database components.

[0019] In yet another embodiment, the system includes a method for migrating a source database to a target database calculated based on the size and complexity of the source database. Quantitative change It has.

[0020] In yet another embodiment, the system has a refactored database structure that is generated utilizing a continuous integration and deployment framework and an automated testing framework.

[0021] In yet another embodiment, the system includes an evaluation statistic that provides at least one inhibitor to completing the migration of the source database.

[0022] In yet another embodiment, the system includes scanning the source database, including scanning connections between database components of the source database.

[0023] In yet another embodiment, the system has a refactored database structure generated according to the target database while maintaining connections between database components of the source database.

[0024] In yet another embodiment, the system has a refactored database structure identified by an AI engine.

[0025] In yet another embodiment, the system includes a refactoring module that further includes migrating, by the processor, dictionaries and keywords from the source application environment according to the target application environment.

[0026] In another embodiment, the system comprises a replatforming module that further includes implementing, by a processor, scripts from the source application environment according to the target application environment.

[0027] In another embodiment, the system includes a plurality of modules that further execute the processor and access application code including business logic, links, rule engines, libraries of available environments, standard tools, and coding languages.

[0028] In another embodiment, the system includes a source database of an application environment that is migrated to a target database including the steps of re-evolving the environment from the source to the target database, refactoring from the source to the target database, re-hosting from the source to the target database, and re-platforming from the source to the target database.

[0029] It is a primary objective of the subject matter to provide a system and method for database migration in application environment migration that can be used to migrate an application from one platform to another, and more specifically, that can be used to migrate a database from an older environment to a newer environment. The system and method for database migration in application environment migration can be customized based on the database being migrated and the environment, including the older environment in which the database was developed and the newer environment to which the database is to be migrated.

[0030] Another object of the subject matter is to provide database migration in an application environment migration that accommodates multiple databases while preserving database links. Additionally, the system and method for database migration in an application environment migration may enable selected databases to be migrated from a wide range of environments to another wide range of environments.

[0031] Another object of the subject matter is to provide a system and method for database migration in application environment migration that migrates the database environment in an automated manner without requiring manual input.

[0032] Another object of the subject matter is to provide a database migration in an application environment migration that reduces the time and effort spent by a development team to migrate a database from an older environment to a newer environment by eliminating repeatable patterns of work performed by the development team, thereby also reducing costs.

[0033] Another object of the subject matter is to provide a database migration in an application environment migration that can be utilized by development teams to migrate existing databases from an older environment to a newer environment.

[0034] Another objective of the subject matter is to provide a database migration in application environment migration that acts like a parser that examines an existing chunk of a database, analyzes it, processes it, and then repackages / replatforms it.

[0035] Another object of the subject matter is to provide database migration in application environment migration, which can be utilized to migrate databases from older environments such as Oracle / DB2 / Sybase to newer environments such as cloud-based solutions such as Azure SQL / Postgres.

[0036] Another object of the subject matter is to provide a database migration in an application environment migration that migrates a database from an older environment to a newer environment by reducing implementation costs, reducing total cost of ownership to increase profitability, improving execution speed, improving application performance, and increasing application productivity.

[0037] It is another object of the subject matter to provide a number of advantages depending on the particular aspect, embodiment, implementation and / or configuration.

[0038] It is another objective of the subject matter to provide a platform that can provide reliable execution, scalability, and value-added services while controlling the effort and cost of operations.

[0039] Efficiently managing a large number of instances simultaneously, working with various regulatory requirements, and enabling resources to collaborate and work together closely, efficiently, and collectively with a user-friendly interface are other objectives of the subject matter.

[0040] These and other aspects, embodiments, processes, and features of the subject matter will become more fully apparent when the following detailed description is read in conjunction with the accompanying experimental details. However, both the foregoing summary of the subject matter and the following detailed description thereof represent one potential aspect or embodiment and are not intended to limit other alternative aspects or embodiments of the present disclosure or the subject matter. [Brief explanation of the drawings]

[0041] A clearer understanding of the principal features of the subject matter summarized above can be obtained by reference to the accompanying drawings illustrating the subject methods and systems, however, such drawings depict preferred embodiments of the subject matter and therefore should not be considered limiting in scope with respect to other embodiments the subject matter may contemplate. [Figure 1] 1 shows a schematic modular diagram illustrating a method for database migration in application environment migration according to an embodiment of the present subject matter; [Figure 2] 1 shows a system diagram illustrating the operation of an exemplary database migration in an application environment migration system, according to an embodiment of the present subject matter. [Figure 3] 1 illustrates an exemplary assessment report automatically generated by an exemplary database migration in an application environment migration system, according to an embodiment of the present subject matter. [Figure 4] 1 illustrates an exemplary diagram of an exemplary database migration in an application environment migration method, according to an embodiment of the present subject matter. [Figure 5] 1 illustrates an exemplary diagram of an exemplary database migration in an application environment migration method, according to an embodiment of the present subject matter. [Figure 6] 1 illustrates an exemplary flowchart of a method for database migration in application environment migration, according to an embodiment of the present subject matter. [Figure 7] 1 illustrates another exemplary flowchart of a method for database migration in application environment migration, according to an embodiment of the present subject matter. DETAILED DESCRIPTION OF THE INVENTION

[0042] (Detailed Description of the Invention) The following is a detailed description of embodiments of the present disclosure that are illustrated in the accompanying drawings. The embodiments are in sufficient detail to clearly communicate the disclosure. However, the amount of detail provided is not intended to limit the embodiments, but rather to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the present disclosure. Although aspects of the described systems and methods for database migration in application environment migration may be implemented in any number of different computing systems, environments, and / or configurations, the embodiments are described in the context of the following example system(s).

[0043] This disclosure provides database cloud replatforming from a source database in a source application environment to a target database in a target application environment. Database cloud replatforming involves migrating an existing on-premises database to the cloud and leveraging the scalability and flexibility of the cloud to efficiently function the source database in the source application environment. The source database in the source application environment's architecture is also modified to reduce the total cost of ownership (TCO) of these databases, including adopting more open-source and cloud-friendly software to reduce virtual machine, application server, and database licensing costs. Actual TCO savings vary by database and are determined after an evaluation of the source database. This disclosure lists some key steps to be performed on the database, which will vary from database to database, and existing databases may be modified to work effectively on Cloud Platform or PaaS, but all blockers related to source and on-premise design patterns are changed, all underlying links, connections, libraries are updated to make the source database compatible with containers or PaaS, application servers (Weblogic, WebSphere, JBoss, etc.), and the database may be replaced with open source cloud-friendly software, monolith applications may be separated into smaller macro services for efficiency and speed, and the monolith database may be refactored and replatformed on the target cloud database.

[0044] This disclosure provides a mechanism for cloud replatforming through simple containerization, removing all code blockers that hinder containerization and deploying the source application in a container such as Docker to run it on the cloud. Furthermore, the source application release process, including test case and CI / CD automation, may also be automated. Furthermore, the source application and / or source database may be replatformed to a lightweight open-source server, such as Tomcat for Java applications and a legacy DB2 database, to reduce licensing costs and computing costs in the cloud, thereby lowering the TCO of these applications. However, to ensure stability and performance, the monolith application must be split into smaller services or refactored database structures, all of which are stateless and deployed to separate Tomcat servers, each in its own container. Therefore, the source application may be migrated to the target application platform by decoupling the monolith application and exposing it through an API using a macroservice concept, making it a cloud-ready application. In addition to splitting the monolith application into macroservices, CI / CD may also be implemented to achieve fast and automated deployment. It performs DB replatforming, including refactoring to Postgres DB keywords to generate a refactored database structure. It also uses a script generator to generate Azure Postgres DDL SQL scripts and Azure Postgres DML SQL scripts, uploads the DDL and DML to the target Azure Postgres, and prepares the Azure Postgres DB by debugging and fixing errors. The component-wise structure and step-by-step method are shown below.

[0045] FIG. 1 shows a schematic modular diagram 100 illustrating a method for database migration in application environment migration, according to an embodiment of the present subject matter.

[0046] In one embodiment, database migration in application environment migration system 120 implements a method for database migration in an application environment migration system on server 102, where system 120 includes processor(s) 122, interface(s) 124, framework(s) 150, AI engine 152, and memory 126 coupled to or in communication with processor(s) 122. Processor(s) 122 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuits, and / or any device that manipulates signals based on database migration instructions. Among other functions, processor(s) 122 are configured to fetch and execute computer-readable instructions stored in memory 126. Framework 150 includes, but is not limited to, a continuous integration and continuous deployment framework, an automated testing framework, etc. The AI ​​engine 152 includes, but is not limited to, a database (DB) replatforming engine, an application replatforming engine, a batch and scheduler replatforming engine, a message broker replatforming engine, an open source AI engine, and the like.

[0047] Although the present disclosure is described with respect to a scenario in which the system is implemented as an application on a server, the system and method may be implemented in a variety of computing systems, including, but not limited to, mainframe computers, workstations, personal computers, desktop computers, minicomputers, servers, multiprocessor systems, laptops, tablets, SCADA systems, smartphones, mobile computing devices, etc.

[0048] The interface(s) 124 may include various software and hardware interfaces, such as, for example, a web interface, a graphical user interface, etc., that allow the system 120 to interact with a user. Additionally, the interface(s) 124 may allow the system 120 to communicate with other computing devices, such as web servers and external data servers (not shown). The interface(s) 124 may facilitate multiple communications within a wide variety of network and protocol types, including, for example, wired networks such as LANs, cable, and wireless networks such as WLANs, cellular, or satellite. The interface(s) 124 may include one or more ports for connecting multiple devices to each other or to another server.

[0049] The network used to communicate between all elements in the application server and cloud environment can be a wireless network, a wired network, or a combination thereof. The network can be implemented as one of several different types of networks, such as an intranet, a local area network (LAN), a wide area network (WAN), or the Internet. The network can also be a dedicated network or a shared network. A shared network refers to a collection of different types of networks that communicate with each other using various protocols, such as Hypertext Transfer Protocol (HTTP), Transmission Control Protocol / Internet Protocol (TCP / IP), and Wireless Application Protocol (WAP). The network can also include various network devices, including routers, bridges, servers, and computing devices. The network can also have access to storage devices, such as those located on client-site computers, host-site servers or computers, clouds, or a combination thereof. Storage can include one or many local and remote computer storage media, including one or many memory storage devices, databases, and the like.

[0050] The memory 126 may 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.

[0051] Modules 128 further include evaluation module 130, refactoring module 132, replatforming module 134, and other modules 136, including, but not limited to, a blocker evaluation module, a script generator module, etc. Script generator modules further include, but are not limited to, a test case generator, a build script generator, a Docker script generator, a pipeline script generator, a deployment script generator, etc. It will be understood that such modules may be represented as a single module or a combination of different modules. Furthermore, memory 126 further includes system data 140, which serves as a repository for storing data fetched, processed, received, and generated by one or more of modules 128, among other things. System data 140 includes, for example, operational data, workflow data, and other data in storage 144. System data 140 optionally has storage 144, represented as 144a, 144b, ..., 144n. In one embodiment, system data 140 has access to other databases via the web or a cloud network. Storage 144 includes multiple databases, including, but not limited to, evaluation module data, refactoring module data, replatforming module data, libraries, link identifiers, database adapters, database dictionaries, database parsers, technology dictionaries, file adapters, application parsers, pattern recognizers, open source libraries, technology stacks, etc. 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 memory 126 in the form of data structures. Furthermore, such data may be organized using a data model, such as a relational data model or a hierarchical data model.

[0052] The server 102 is further connected, connectable to, or part of a cloud environment 110 having multiple computing systems, including a target application environment server 104, another target application environment server 106, and databases, including, but not limited to, database 108. The computing systems and databases must communicate with each other under cloud computing rules and with the server 102 under the web or other available communication medium / protocol. The computing systems of the target application servers 104, 106 are generally distributed processing systems including multiple computing devices connected by and communicating over a network. Software applications can be executed "in the cloud" by configuring them to run across one or more computing devices in a particular cloud computing system. Each computing device in a cloud computing system may run a separate copy of the software application, or in some cases, the operation of the software application may be divided among different computing devices and executed in parallel. A cloud computing system may include multiple cloud computing instances, which represent resources available for running applications. Each instance may be a physical computing device with specific capabilities (storage size, processing speed, network bandwidth, etc.) or a virtual computing device with specific capabilities. A particular cloud computing system may offer different instance types with different sets of capabilities for running software applications.

[0053] In one embodiment, a user, including but not limited to a migration specialist, database administrator, application developer, quality analyst, or testing specialist, may initially use a user access device to access system 120 via interface 124 using server 102. The operation of system 120 and associated methods and associated modules, sub-modules, and methods may be explained in more detail using Figures 2, 3, 4, 5, 6, and 7, which are described below.

[0054] In one embodiment, system 120 receives user instruction data via interface 124 on server 102. Modules 128 of system 120 process the instructions using processor 122 while using system data 140, other modules 136, framework 150, and support components. Assessment module 130 for database migration in application environment migration is utilized prior to initiating the migration of a database from one environment to another. Assessment module 130 performs an assessment of the source database of the source application environment to determine the changes that the source database of the source application environment must undergo, while assessing the risk, cost, timeline, and impact of the changes on other dependent applications that will be migrated to the target database of the target application environment. Quantitative change The assessment module 130 understands the underlying database links, connections, and dependencies developed by various developers with different styles. Furthermore, the predictive assessment report 302 generated by the assessment module 130 using the AI ​​engine 152 provides a detailed overview of the required timeline, percentage of database components / structures that need to be changed, and the impact of multiple Readiness ParametersThe assessment report 302 provides in-depth details, including but not limited to, warnings with multiple inhibitors or code blockers and reasons, highlighted areas where database components need to be modified, the number of services the monolith can be split into, the types of services the monolith can be split into, and database preparation for continuous integration and continuous deployment. The assessment report 302 generated by the assessment module 130 provides an accurate estimate and timeline for completing the source database migration of the source application environment. In one embodiment, the RPA bot is configured to generate the assessment report 302 using a proactive database migration of predictive application environment migration (PAEMF) algorithm. In one embodiment, the RPA bot is a software bot or a combination of software and hardware bots. In one embodiment, the software bot is a computer program that enables 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 dedicated memory, processors, controllers, and other related chipsets to perform functions that enable robotic process automation, particularly for database migration in application environment migration.

[0055] The refactoring module 132 for database migration in application environment migration supports automated replatforming from a source database migration in application environment migration to a target database migration in application environment migration by scanning the source database to identify dependencies between database components in the form of database links, and generates a refactored database structure by splitting the source database according to the target database while preserving the database links. The refactoring module 132 generates the refactored database structure for the source application environment by utilizing a continuous integration and deployment framework 150, an automated testing framework 150, and middleware replatforming and environment-friendly design patterns.

[0056] The replatforming module 134 for database migration in application environment migration supports automated replatforming for source database migration in application environment migration to a target application environment to convert a database from one environment to another based on the size of the database and its complexity. The replatforming module 134 replatforms the target database according to predicted evaluation statistics and refactored database structure. subdivided Update the database components, migrate the source database to the target database, and then subdividedReplatforming the database component. The replatforming module 134 also performs activities including, but not limited to, integrating patterns from the source application environment with design patterns in the target application environment, fine-tuning code, resolving deployment issues, implementing security to ensure the migrated application is fully functional, etc. The replatforming module 134 supports multiple forms of environment migration, including, but not limited to, rehosting environment migration, database replatforming, database refactoring, and native database development.

[0057] In the blocker assessment module of other modules 136, any application, such as a monolithic web application with on-premise design patterns, can be input to the system and method for database migration in application environment migration, and the blocker assessment module of the system and method for database migration in application environment migration can discover patterns of on-premise design patterns in the monolithic web application. Further, this information can be forwarded to the automated replatforming module of the system and method for database migration in application environment migration, as shown in FIG. 1.

[0058] The reference architecture of system 120 further includes supporting components such as a test generator that generates unit, functional, and performance test cases for generated APIs; a build script generator that generates scripts to successfully build and run an application; a Docker script generator that generates scripts to containerize an application and its dependencies; a pipeline script generator that generates scripts to create a CI / CD pipeline for development, test, and production environments; a deployment script generator that generates scripts to deploy an application to a target environment; a database adapter that establishes connections to multiple database servers, such as IBM DB2, Oracle, Microsoft SQL Server, Sybase ASE, and PostgreSQL; a database dictionary that contains a vast number of database-related keywords and built-in functions used by the above multiple database servers; a database parser that uses the database dictionary to parse database objects and find patterns that are incompatible with the target database; and an AI engine that identifies existing and potential macros / microservices in legacy applications. DB Replatforming Engine - DB Replatforming Engine replatforms source database objects such as tables, constraints, sequences, triggers, functions procedures etc. into target database compatible objects. File Adapter - File adapter provides access to application source files. The files are scanned, reports are generated and finally replatformed as the target application.Technology Dictionary - The technology dictionary contains a vast number of patterns related to the technologies used within the monolith application. Application Parser - The application parser uses a pattern recognizer to analyze the application source code and find the entire inventory of technologies used by the application. This inventory is used for assessment and replatforming. Pattern Recognizer - The pattern recognizer recognizes patterns based on the technology dictionary and finds the technologies used in the application. AppliPlatform Engine - The AppliPlatform Engine replatforms the source application analyzed by the application parser. This engine generates an application ready to be deployed to the cloud. The technology stack includes but is not limited to JAVA 1.8; Maven; JUnit, NUnit, XUnit JMeter; Docker Jenkins; AWS CLI, Azure CLI, etc.

[0059] FIG. 2 shows a system diagram 200 illustrating the operation of an exemplary database migration in an application environment migration system, according to an embodiment of the present subject matter.

[0060] This disclosure presents two key activities: source application environment assessment and source database conversion to the desired target platform, which are illustrated in flowchart 200 below.

[0061] In one embodiment, a monolith web application 202, such as a JAVA or .NET application, is a source application of a source application environment. The monolith web application 202 is linked to various support components 204, including, but not limited to, databases, batch, integration, apps, schedulers, message brokers, etc. The functionality of the source database 204 linked to the source application environment is described in further detail below.

[0062] In a first step, Cloud Blocker Assessment 206 assesses the source application and generates an assessment report 212 that includes code defects, source code insights, and on-premise design patterns 214. Cloud Blocker Assessment 206 also assesses the source database and generates an assessment report 212 that includes database connections, links, and dependencies. On-premise design patterns 214 include, but are not limited to, EJB, RMI, STRUTS / SPRING, SOAP / XML, JSP / ASP, COM / COM++, ESB, etc. The assessment of the source application includes a technology stack and code analysis of the current application. The assessment provides automated insights into the time, effort, and risk involved in replatforming the source application, source database, and other supporting components. The assessment includes an analysis of the source database components, performing an automated assessment of the source database 204, including links, connections, and other dependencies, and providing a detailed analysis of the database and its dependencies. Readiness ParametersThe cloud blocker assessment 206 identifies impediments or blockers (packages / frameworks / APIs / libraries, etc.) that could cause a containerized cloud migration to fail, thereby providing a detailed detailed assessment report 212 as an assessment report 302. It performs this code assessment on the entire source application ecosystem, including applications, databases, batch programs and schedulers, integration message brokers, build and deploy modules. The cloud blocker assessment 206 analyzes the code that the source application environment must go through to assess risk, cost, timeline, and impact to other dependent components and applications. Quantitative change The report primarily provides the percentage of code that needs to be changed, code readiness, blockers and warnings with reasons, exact locations where the code needs to be changed, number of services into which the monolith can be decomposed, DevOps and CI / CD readiness, and a timeline for such execution.

[0063] The next step is to perform an automated conversion / replatforming 208 to replatform the application and supporting components from the source environment to the target environment, while preserving the database links of the source database in the target application environment, to generate a cloud-ready application and supporting components 210, such as an Oracle database or DB2 database, consisting of a JAVA or .NET application, a continuous integration and deployment framework 216, an automated testing framework 218, a middleware replatforming 220, and a cloud-friendly design pattern 222 after refactoring the source database of the source application environment. Substeps of the automated replatforming 208 are to upgrade database connections, interdependencies, links, and other supporting components, and convert all database components from source DBs, such as Oracle, Sybase, DB2, and SQL Server, to cloud-friendly databases, such as Postgres or MySQL. All components are converted to work with the target DB and achieve the same desired results as the source DB. Once the database component conversion is complete, it converts the source database based on the design of the target application environment. subdivided Breaking down into components, fine-tuning rules, taking steps to resolve deployment issues, and implementing security are completed by the consultant to make the target database fully functional. In one example, Table A and Table B can be used as examples to explain an exemplary code conversion.

[0064] [Table A]

[0065] [Table B]

[0066] Furthermore, database cloud replatforming involves several iterative steps, such as database component analysis, refactoring, library updates, compiling build scripts, deployment scripts, containerization scripts, etc. The result can significantly improve time to market, subsequently reducing overall costs and achieving high-quality replatforming.

[0067] FIG. 3 illustrates an exemplary assessment report 302 automatically generated by an exemplary database migration in an application environment migration system, according to an embodiment of the present subject matter.

[0068] In one embodiment, the assessment module 130 generates an assessment report 302 after assessing the source application environment, including code defects, source code insights, database links, connections, and on-premise design patterns 214. The assessment report 302 provides automated insight into the time, effort, and risk involved in replatforming the source application environment.

[0069] The assessment includes an analysis of database components, performing an automated assessment of the source database, including links, connections, and other dependencies, and identifying the database and Readiness Parameters It identifies inhibitors or blockers (packages / frameworks / APIs / libraries, etc.) that cause containerized cloud migration to fail, thereby providing a detailed assessment report 302. The report generation is an automated process that involves some user configuration based on the source application and target application environment.

[0070] The assessment report 302 is a summary of the data that the source database must go through to assess the risk, cost, timeline, and impact on other dependent components and databases. Quantitative change A deep understanding of Readiness Parameters 304 and visual composition 306 . Quantitative changeis the sum of all changes required for the database migration. The assessment report has various sections, and some example diagrams for an application snapshot include parameters such as containerization readiness 304a, replatforming readiness 304b, DevOps readiness 304c, macro / micro API readiness 304n, scheduler replatforming readiness 304n, batch readiness, message broker readiness, and DB replatforming readiness 304n, among others. Each parameter indicates a readiness state, such as a percentage (%), indicating how much is ready and / or how many not-ready / blocking / blocking conditions exist for the respective parameter. For example, Containerization Readiness 304a shows container readiness rate with readiness state and required refactoring / blocker rate, Replatform Readiness 304b shows Tomcat readiness rate with readiness state and required refactoring / blocker rate, DevOps Readiness 304c shows CD readiness rate with readiness state and CI readiness / blocker rate, Macro / Micro API Readiness 304n shows Macro API existing pointer with readiness state and Micro API existing / blocker state, Scheduler Replatform Readiness 304n shows replatforming readiness rate with AWS Batch readiness state and Azure Logic App readiness / blocker rate, and DB Replatform Readiness 304n shows replatforming readiness rate with PostgresSQL readiness state and required refactoring / blocker rate, etc. Another section of the report includes visual configurations 306 such as Database Objects Spread [#Objects] 306a, Database Objects Spread [#LoC] 306b, Platform Configuration by Number 306n, and Platform Configuration by LoC 306n.In one example, Database Objects Spread [#Objects] 306a indicates the spread or count number or percentage of triggers, sequences, packages, procedures, views, materialized views, functions, and tables; Database Objects Spread [#LoC] 306b indicates the spread or count number or percentage of triggers, sequences, packages, procedures, views, materialized views, functions, and tables; Platform Configuration by Number 306n indicates the spread or count number or percentage of JMS, XML Config, Web Services, Maven Build, Configuration, HTML, Servlets, Stylesheets, ReactJS, JSP, JUnit, POJO; Platform Configuration by LoC 306n indicates the spread or count number or percentage of JMS, XML Config, Web Services, Maven Build, Configuration, HTML, Servlets, Stylesheets, ReactJS, JSP, JUnit, POJO, etc.

[0071] Further, in one example, various sections of the assessment report 302 provide the following information sections: application snapshot consisting of frameworks / libraries / packages used, application containerization readiness, application server replatforming readiness to Tomcat or Kestrel application server, database server replatforming readiness to PostgreSQL etc., containerization readiness (to Docker / Kubernetes), CI / CD readiness (unit / functional / performance test cases, build and continuous integration, available automation), macro and micro API candidates, API readiness (existing and potential APIs in the application).

[0072] This methodology provides end-to-end conversion capabilities by assessing the source application environment, then converting it to the cloud using cloud-friendly design patterns, and finally managing the entire journey by providing your stakeholders and decision makers with transparent visibility for rapid decision-making. Convert all application dependencies holistically to the cloud, from databases to batch programs, schedulers to message brokers. In the application analysis section of the assessment report 302, the methodology analyzes the entire source application and identifies blockers in the source code, including design patterns that inhibit cloud migration. All dependencies are also analyzed, providing a holistic view for design and planning purposes. It discovers and analyzes the application component inventory, technology stack, and its dependencies; identifies the application's business, data services, and its API readiness; identifies blockers and DevOps readiness for containerization and cloud replatforming; and identifies change initiatives such as JAVA vX.X to JAVA v1.8; EJB (Session Bean / Entity Bean / MDB) to Spring Boot Service with Spring Framework (POJO); and .NET vX.X to .NET Core v2.2.

[0073] In the database analysis section of assessment report 302, the methodology analyzes databases to analyze and discover database inventory, data object details and database size, identify database replatforming preparation and blockers, identify application blockers and dependencies for database replatforming, and identify efforts for change such as from Oracle / SQL Server / DB2 / Sybase to Postgres / MySQL. In the batch & scheduler analysis section of assessment report 302, the methodology analyzes batch & schedulers to analyze and discover batch program inventory and batch schedulers, batch scheduler replatforming preparation, identify blockers and dependencies, identify application batch services for batch replatforming, and identify efforts for change such as from Autosys / ControlM to AWS Batch (AWS Cloud) / Azure Logic App (Azure Cloud) / Quartz (Private Cloud). In the message broker analysis section of the assessment report 302, the methodology analyzes message brokers, analyzes and discovers message broker inventory and messaging objects, identifies message broker replatforming readiness, blockers and dependencies, identifies application blockers and dependencies for message broker replatforming, efforts for change such as from TIBCO EMS / Rendezvous or WebLogic / WebSphere or Message Queue or Sonic Message Queue to Active MQ.

[0074] FIG. 4 illustrates an example diagram 400 of an example database migration in an application environment migration method, according to an embodiment of the present subject matter.

[0075] In one embodiment, an application deployment view 400 with pre- and post-replatforming is depicted using a method and system for source database migration in application environment migration to a target application environment according to an embodiment of the present subject matter. A monolith application typically resides in a source application environment residing or accessible by a server 102 and is transformed or migrated to a modernized, replatformed application residing in a target application environment residing or accessible by a cloud environment 110. First, code evaluation 206 occurs for the migration of the source application environment to the target application environment. The application evaluation determines the amount of code changes required to remove and modify code inhibitors for containerization. The migration is performed in the following steps: the application web server with the application accessible by the server 102 is optionally converted to web front-end instances 422a, 422b, ..., 422n. The application server (IIS cluster) 202 is further refactored into an API management layer 426 with various App macro service instances 426a, 426b, 426c, ..., 426n. The macro service instance is based on the size and complexity of the source application. In one embodiment, the refactoring module 132 performs factoring and repackaging 208 of the macro service into the target application environment.

[0076] The source application database 204 also maps the PaaS / CaaS cluster 424a to the replatformed version of the target database 424. subdividedThe web front instances 422a, 422b, ..., 422n and macro service instances 426a, 426b, 426c, ..., 426n are further linked to components of the cloud computing environment 110, including but not limited to a service mesh, an AKS cluster, App services, ACI, etc. In one embodiment, the source Oracle database is migrated to a PostgresSQL database along with the container / orchestration platform of the cloud environment 110.

[0077] The source application's virtual machine instances 408a, 408b, ..., 408n are migrated to a container cluster in the cloud environment 110. Thus, the on-premises data center 410 of the source application environment 410 with its on-premises ecosystem 412 is replatformed 210 / migrated to a private / public cloud 428 in the cloud environment 110. In one embodiment, the components (412a, 412b, ..., 412n) of the on-premises ecosystem 412, including but not limited to EBS, caching, local files, rules engines, batch and schedulers, message brokers, authentication protocols, security platforms, etc., are replatformed 210 / migrated to a private / public cloud 428 in the cloud environment 110. In one embodiment, the components (430a, 430b, 430c, ..., 430n) of the on-premises ecosystem 412, including but not limited to EBS, caching, local files, rules engines, batch and schedulers, message brokers, authentication protocols, security platforms, etc., are replatformed 210 / migrated to a private / public cloud 428 in the cloud environment 110.

[0078] In one embodiment, a method modifies existing on-premise applications to run efficiently on the cloud using containers or PaaS, updating or modifying all blockers related to source code and design patterns and all underlying libraries to make them compatible with containers or PaaS, replatforming application servers and databases to reduce TCO, and monolith applications can be decoupled into services to improve efficiency and speed.

[0079] In one example, Table C can be used as an example to explain the replatforming migration.

[0080] [Table C]

[0081] In one embodiment, the current state is a monolithic web application with JSP-based UI to session EJB calls and a commercial application server with some data services, session persistence and stateful services are the current state, and the migrated future state is a decoupled web application with JSF WebFront and RESTful Spring Boot macro services (independently scaling) on ​​a container via an API gateway.

[0082] FIG. 5 illustrates an example diagram 500 of an example database migration in an application environment migration method, according to an embodiment of the present subject matter.

[0083] In one embodiment, an exemplary database migration is depicted in application environment migration methodology view 500 from pre-replatforming to post-replatforming using a method and system for source database migration in application environment migration to a target application environment according to an embodiment of the present subject matter. A monolith source database typically resides in a source application environment residing or accessible by a server 102 and is transformed or migrated to a modernized, replatformed target database residing in a target application environment residing or accessible by a cloud environment 110. First, the method accesses an on-premise RDBMS or source database 204 having database components such as tables and views 204a, sequences 204b, procedures and functions 204c, triggers 204d, etc. The method considers a complete inventory of database components such as tables, views, stored procedures, functions, DB links, etc., the size and complexity of the source database 204, the compatibility and risks associated with replatforming to a cloud-friendly target database 424 such as Postgres, and the need to replatform the monolith. subdivided , 204n of the source database 204 to the target database 424. Quantitative change Functionality for verifying and completing the migration of database components 204a, ..., 204n of source database 204 Readiness ParametersThe evaluation step 502 also includes a keyword dictionary 512a and a DB dictionary 512b.

[0084] A database, such as the source database 204, the refactored database structure 506, or the target database 424, includes database components, such as tables and views 204a / 506a / 424a, sequences 204b / 506b / 424b, procedures and functions 204c / 506c / 424c, and triggers 204d / 506d / 424d, respectively. Tables in the tables and views 204a / 506a / 424a are collections of data elements organized by rows and columns. Tables can also be thought of as convenient representations of relationships. One or more tables 204a / 506a / 424a may represent a structured data schema, including one or more columns configured to store data in one or more rows. Tables 204a / 506a / 424a may include constraints that define rules for the data stored in a particular table, relationships between different ones of the one or more tables 204a / 506a / 424a, or other constraints. Tables and Views 204a / 506a / 424a are subsets of database tables and are based on queries executed on one or more database tables. Database views are stored in the database as named queries and can be used to store frequently used complex queries. There are two types of database views: dynamic and static. Sequences 204b / 506b / 424b are sets of integers (1, 2, 3, ...) that are generated and supported by some database systems to generate unique values ​​on demand. Procedures and Functions 204c / 506c / 424c are groups or sets of SQL and PL / SQL statements that perform specific tasks. Triggers 204d / 506d / 424d are stored procedures in the database that are automatically invoked whenever a specific event occurs in the database. Components 204n / 506n / 424n are other components of the database. It should be noted that the terms 204a,...n; 506a,...n; 424a,...n; cannot be used interchangeably as they refer to components of the source database, the refactored database, and the target database.The structure, interdependencies, methods of storage database linkages, and connections will vary depending on the type of database used, and the above is provided only to give a general definition of the various components that are part of such a database. The same may be entered or developed as part of the present subject matter by due process of the systems and methods detailed herein.

[0085] In the next database conversion step to perform DB replatforming 504, the method mainly performs two functions: first, refactoring DB keywords into target DB keywords 506 by scanning the source database 204 to identify dependencies between database components 204a, ..., 204n in the form of database links, and then generating refactored database structures 506a, ..., 506n by splitting the source database 204 according to the target database 424 while preserving the database links. The method converts all database components from source DBs such as Oracle, Sybase, DB2, and SQL Server to cloud-friendly databases such as Postgres or MySQL. All components are converted to work with the target DB and achieve the same desired results as the source DB. Once the database components are converted, the database is re-platformed based on the application design. subdivided The method is divided into components. The method helps to avoid data corruption and distributed transaction issues in the target application environment and function properly. Second, the target database 424 is refactored according to the predicted evaluation statistics 302 and the refactored database structure 506a, ..., 506n. subdivided Replatforming by updating database components 424a, ..., 424n and updating subdividedThe method migrates the source database 204 to a target database 424 by replatforming database components 424a, ..., 424n. The target database 424 has database components such as tables and views 424a, sequences 424b, procedures and functions 424c, and triggers 424d. The method uses a script generator 508 to generate target database DDL SQL scripts 508a and target database DML SQL scripts 508b, which further perform steps including, but not limited to, reading the source DB, understanding the DB structure, and generating AS IS Temp DDL and DML. It also refactors DB keywords and syntax from the target database dictionary and converts the DDL and DML to the target database format. It uploads the DDL and DML to the target database, debugs and fixes errors, and makes the target database DB Ready. The SQL scripts are loaded 510 into the target database 424, which has a refactored database structure 424a, ..., 424n driven / managed by the target database and the cloud.

[0086] In one example, the execution steps for legacy DB replatforming to Azure SQL Database include Oracle / DB2 / Sybase on-premise RDBMS source database 204 having database components such as tables and views 204a, sequences 204b, procedures and functions 204c, triggers 204d, etc. The method involves taking a complete inventory of database components such as tables, views, stored procedures, functions, DB links, etc., the size and complexity of the Oracle / DB2 / Sybase 204, compatibility and risks associated with replatforming the cloud-friendly target database 424 to Azure SQL, and the ability to re-platform the monolith. subdividedThe method performs an assessment 502 to perform and execute the assessment to break down the database into components. The assessment 502 also lists an Oracle / DB2 / Sybase keyword dictionary 502a and a SQL Server DB dictionary 502b. The assessment report 302 highlights the level of refactoring required for replatforming to Azure SQL. It performs DB replatforming 504, which includes refactoring DB keywords into SQL Server DB keywords 506 to generate refactored database structures 506a, ..., 506n. The method uses a script generator 508 to generate Azure SQL Server DDL SQL scripts 508a and Azure SQL Server DML SQL scripts 508b, which perform further steps including, but not limited to, reading the Oracle / DB2 / Sybase database, understanding the Oracle / DB2 / Sybase structure, and generating AS IS Temp DDL and DML. The method further refactors the DB keywords and syntax from the Oracle / DB2 / Sybase dictionary and the DDL and DML converted to Azure SQL Server format. Upload DDL and DML to Azure SQL Server, debug and fix errors, and get the Azure SQL Server DB ready. The SQL scripts are loaded into Azure SQL Server424 with a refactored database structure424a, …, 424n powered / managed by the cloud510.

[0087] In another example, the execution steps for legacy DB replatforming to Azure Postgres database include Oracle / DB2 / Sybase on-premise RDBMS source database 204 having database components such as tables and views 204a, sequences 204b, procedures and functions 204c, triggers 204d, etc. The method involves taking a complete inventory of database components such as tables, views, stored procedures, functions, DB links, etc., the size and complexity of Oracle / DB2 / Sybase 204, compatibility and risks associated with replatforming a cloud-friendly target database 424 to Azure Postgres, and the ability to re-platform a monolith. subdividedAn assessment 502 is performed to conduct and execute the assessment to break down the database into components. The assessment 502 also lists an Oracle / DB2 / Sybase keyword dictionary 502a and a SQL Server DB dictionary 502b. The assessment report 302 highlights the level of refactoring required for replatforming to Azure Postgres. It performs DB replatforming 504, which includes refactoring DB keywords into Postgres DB keywords 506 and generating refactored database structures 506a, ..., 506n. The method uses a script generator 508 to generate Azure Postgres DDL SQL scripts 508a and Azure Postgres DML SQL scripts 508b, which further perform steps including, but not limited to, reading the Oracle / DB2 / Sybase database, understanding the Oracle / DB2 / Sybase structure, and generating AS IS Temp DDL and DML. The method further refactors the DB keywords and syntax from the Oracle / DB2 / Sybase dictionary and the DDL and DML converted to Azure Postgres format. The DDL and DML are uploaded to Azure Postgres, errors are debugged and fixed, and the Azure Postgres DB is ready. The SQL scripts are loaded into Azure Postgres424 with a refactored database structure 424a, …, 424n powered / managed by the cloud 510. The method provides the ability to understand the current DB components, structure, and their dependencies, and to transform source database components into target components.

[0088] FIG. 6 illustrates an exemplary flowchart 600 of a method for database migration in application environment migration, according to an embodiment of the present subject matter. In one embodiment, a method 600 for database migration in application environment migration is illustrated. The method may be described in the general context of computer-executable instructions. Generally, computer-executable instructions may 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 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 is not intended to be construed as limiting; any number of the described method blocks may be combined in any order to implement the method or alternative methods. Furthermore, individual blocks may be omitted 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 system described above.

[0089] In step / block 602, a source database of a source application environment is evaluated by the processor 122 of the system 120 of the application server 102. In one embodiment, the source database may be evaluated by the evaluation module 130 of the system 120. At step / block 604, a method for migrating database components of the source database to the target database is performed. Quantitative change In one embodiment, Quantitative change may be verified by the evaluation module 130.

[0090] At step / block 606, at least one database component for completing the migration of the database components of the source database is selected. Feature Readinessand predicting evaluation statistics that provide a timeline. In one embodiment, evaluation statistics may be predicted by the evaluation module 130.

[0091] Thus, the method 600 assists database migration in application environment migration by providing predicted evaluation statistics and a timeline for migration from a source application environment to a target application environment.

[0092] FIG. 7 illustrates another exemplary flowchart 700 of a method for database migration in application environment migration, according to an embodiment of the present subject matter.

[0093] In one embodiment, a method 700 for database migration in application environment migration is illustrated. The method may be described in the general context of computer-executable instructions. Generally, computer-executable instructions may 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 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 is not intended to be construed as limiting; any number of the described method blocks may be combined in any order to implement the method or alternative methods. Furthermore, individual blocks may be omitted 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 system described above.

[0094] In step / block 702, a source database of a source application environment is evaluated by the processor 122 of the system 120 of the application server 102. In one embodiment, the source database may be evaluated by the evaluation module 130 of the system 120.

[0095] At step / block 704, a method for migrating database components of the source database to the target database is performed. Quantitative change In one embodiment, Quantitative change may be verified by the evaluation module 130.

[0096] At step / block 706, at least one database component for completing the migration of the database components of the source database is selected. Feature Readiness and predicting evaluation statistics that provide a timeline. In one embodiment, evaluation statistics may be predicted by the evaluation module 130.

[0097] The source database may be scanned by the refactoring module 132 to identify dependencies between database components in the form of database links, in step / block 708. In one embodiment, the source database may be scanned by the refactoring module 132.

[0098] In step / block 710, a refactored database structure is generated by splitting the source database according to the target database while preserving database links. In one embodiment, the refactored database structure may be generated by refactoring module 132.

[0099] In step / block 712, the target database is refactored according to the predicted evaluation statistics and the refactored database structure. subdivided Update the database components. In one embodiment, subdividedThe database components may be updated by the replatforming module 134.

[0100] In step / block 714, the updated subdivided Migrating a source database to a target database by replatforming database components: In one embodiment, a source database may be migrated to a target database by the replatforming module 134.

[0101] Thus, the method 700 assists in database migration in application environment migration by providing predictive assessment, refactoring code, and replatforming databases for migration from a source application environment to a target application environment.

[0102] This solution is used to replatform complex databases to the cloud and deploy them to a production environment. Several examples are presented using the method and system for source database migration in application environment migration to a target application environment according to embodiments of the present subject matter. The following describes the preparation, planning, and execution steps, along with the results of the study. As an example, in the cloud replatforming of a Java batch application for a leading secondary mortgage company, the source application environment belongs to a leading secondary mortgage company, a multi-billion dollar company operating in the United States and a publicly traded company that provides mortgage-backed securities. The primary business challenge is a complex Java batch application developed 10 years ago with Autosys and EJBs on WebLogic MQ, using an Oracle database along with message-driven bean EJBs (MDBs), Pojo Services, JDBC, and other data. The application is business-critical and handles important long-running processes. Cloud replatforming presented challenges due to the unavailability of key SMEs who developed the application. Using this solution approach, the Oracle database was replatformed to Postgres using method steps, the Autosys scheduler was replatformed to Quartz, and the backend EJBs (MDBs) were replatformed to independent Spring JMS with Spring Boot / Batch Service Apps with REST endpoints. Each service app was then deployed on a separate container on an AWS ECS VPC to provide infinite scalability, high availability, high fault tolerance, and improved performance. Autosys' centralized JOB dependencies were refactored into self-managed dependencies using app-specific Quartz schedulers, reducing operational complexity.Among the key benefits, TCO was reduced by over 50%, mainly due to the elimination of WebLogic & Autosys and also due to containerization, development productivity was improved due to macro services and CI / CD automation, and using automation the total cost of implementation was reduced by over 50%, with the implementation being completed in 6 weeks (compared to the same 9 months if done manually).

[0103] In another example, our solution was used to cloud replatform a .NET web application for one of our leading consulting firms. The source application environment is a content management company, one of the largest professional services and auditing organizations, with employees in over 700 offices in 150 countries around the world. The primary business challenge was a complex .NET web application developed over several years using ASP.NET, C#, and Telerik ORM alongside a SQL Server database. This application is business-critical, handling key B2C functions for the leading professional services provider. The task was further complicated by the unavailability of a key SME who developed the application. Using the current solution approach, the source application will be split into a web front-end and a service back-end. The back-end legacy .NET service using Telerik ORM will be replatformed into independent .NET Core service apps with Entity Framework and REST endpoints. The web front-end and each service app will be deployed in separate containers on the Azure cloud with Kestrel & NGINX, providing infinite scalability, high availability, high fault tolerance, and improved performance. The web front and macro services were made stateless with Redis caching. The REST API endpoints for the services are secured with oAuth2. Automated testing + CI / CD was enabled for the web front and all macro services. Among the top benefits, the replatforming resulted in a TCO reduction of over 45% mainly due to the deprecation of IIS & Telerik ORM, a total cost of implementation reduction of over 45%, and increased development productivity due to macro services and CI / CD automation, which was completed in 6 weeks compared to 7 months if done manually.

[0104] Although embodiments of the system and method for database migration in application environment migration are 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 particular features or methods described. Rather, the specific features and methods are disclosed as example embodiments for database migration in application environment migration.

Claims

1. evaluating, by a processor (122) of the application server (102), a source database (204) of the source application environment; determining, by the processor (122), quantitative changes between the database components (204a, ..., 204n) of the source database (204) and the database components (424a, ..., 424n) of the target database (424) for migrating the database components (204a, ..., 204n) of the source database (204) to the target database (424); the processor (122) using an AI engine (152) to predict evaluation statistics (302), the evaluation statistics (302) providing at least one functional readiness (304) and a timeline (306) for completing the migration of the database components (204 a, ..., 204 n) of the source database (204), the at least one functional readiness (304) including impacts on dependent database components in the form of readiness parameters; scanning, by the processor (122), the source database (204) to identify dependencies between the database components (204a, ..., 204n) in the form of database links; generating, by the processor (122), a refactored database structure (506a, ..., 506n), the refactored database structure (506a, ..., 506n) being generated by splitting the source database (204) according to the target database (424) while preserving the database links; updating, by the processor (122), the subdivided database components (424a, ..., 424n) of the target database (424) according to the predicted evaluation statistics (302) and the refactored database structure (506a, ..., 506n); migrate, by the processor (122), the source database (204) to the target database (424), wherein the migrating includes replatforming the updated granular database components (424a, ..., 424n).

2. Executing, by a processor (122) of an application server (102), an evaluation module (130) in a memory (126) coupled to the processor (122) to evaluate a source database (204) of a source application environment; confirming, by the evaluation module (130), quantitative changes between the database components (204a, ..., 204n) of the source database (204) and the database components (424a, ..., 424n) of the target database (424) for migrating the database components (204a, ..., 204n) of the source database (204) to the target database (424); the assessment module (130) using an AI engine (152) to predict assessment statistics (302), the assessment statistics (302) providing at least one functional readiness (304) and a timeline (306) for completing the migration of the database components (204a, ..., 204n) of the source database (204), the at least one functional readiness (304) including impacts on dependent database components in the form of readiness parameters; scanning the source database (204) by a refactoring module (132) in the memory (126) to identify dependencies between the database components (204a, ..., 204n) in the form of database links; generating, by the refactoring module (132), a refactored database structure (506a, ..., 506n), the refactored database structure (506a, ..., 506n) being generated by splitting the source database (204) according to the target database (424) while preserving the database links; updating, by a replatforming module (134) in the memory (126), the granular database components (424a, ..., 424n) of the target database (424) according to the predicted evaluation statistics (302) and the refactored database structure (506a, ..., 506n); migrate, by the replatforming module (134), the source database (204) to the target database (424), wherein the migrating includes replatforming the updated granular database components (424a, ..., 424n).

3. The method of claim 1 or 2, wherein the quantitative change for migrating the source database (204) to the target database (424) is calculated based on the size and complexity of the source database (204).

4. 3. The method of claim 1, wherein the refactored database structure (506a, ..., 506n) is generated using a continuous integration and deployment framework (150) and an automated testing framework (150).

5. 3. The method of claim 1 or 2, wherein the evaluation statistics (302) provide at least one impediment to completing the migration of the source database (204), including, but not limited to, risk, cost, timeline, and the impact on the dependent database components.

6. The method of claim 1 or 2, wherein scanning the source database (204) comprises scanning connections between the database components (204a, . . . , 204n) of the source database (204).

7. 3. The method of claim 1, wherein the refactored database structure (506a, ..., 506n) is generated according to the target database (424) while maintaining connections between the database components (204a, ..., 204n) of the source database (204).

8. The method of claim 1 or 2, wherein the refactored database structure (506a, ..., 506n) is identified by an AI engine (152).

9. The method of claim 1 or 2, further comprising migrating, by the processor (122), dictionaries and keywords from the source application environment according to the target application environment.

10. The method of claim 1 or 2, further comprising implementing, by the processor (122), a script from the source application environment according to a target application environment.

11. 3. The method of claim 1, further comprising accessing, by the processor, application code including business logic, links, a rules engine, libraries of available environments, standard tools, and coding languages.

12. 3. The method of claim 1 or 2, wherein the source database (204) of an application environment is migrated to the target database (424) including the steps of re-evolving the environment from the source to the target database, refactoring from the source to the target database, re-hosting from the source to the target database, and re-platforming from the source to the target database.

13. a processor (122), a memory (126) coupled to the processor (122), and an AI engine (152); The processor (122) executes a plurality of modules (128) stored in the memory (126); The plurality of modules (128) evaluates a source database (204) of a source application environment; an assessment module (130) for identifying quantitative changes between the database components (204a, ..., 204n) of the source database (204) and the database components (424a, ..., 424n) of the target database (424) for migrating the database components (204a, ..., 204n) of the source database (204) to the target database (424), wherein the assessment module (130) uses the AI ​​engine (152) to predict assessment statistics (302) that provide at least one functional readiness (304) and a timeline (306) for completing the migration of the database components (204a, ..., 204n) of the source database (204), and further wherein the at least one functional readiness (304) includes an impact on dependent database components in the form of a readiness parameter; a refactoring module (132) for scanning the source database (204) to identify dependencies between the database components (204a...204n) in the form of database links and for generating a refactored database structure (506a...506n), the refactored database structure (506a...506n) being generated by splitting the source database (204) according to the target database (424) while preserving the database links; a replatforming module (134) for updating the granular database components (424a, ..., 424n) of the target database (424) according to the predicted evaluation statistics (302) and the refactored database structure (506a, ..., 506n) and migrating the source database (204) to the target database (424), wherein the migration replatforms the updated granular database components (424a, ..., 424n).

14. 14. The system of claim 13, wherein the quantitative change for migrating the source database (204) to the target database (424) is calculated based on the size and complexity of the source database (204).

15. 14. The system of claim 13, wherein the refactored database structure (506a, ..., 506n) is generated utilizing a continuous integration and deployment framework (150) and an automated testing framework (150).

16. 14. The system of claim 13, wherein the evaluation statistics (302) provide at least one inhibiting factor to complete the migration of the source database (204), including, but not limited to, risk, cost, timeline, and the impact on the dependent database components.

17. The system of claim 13 , wherein scanning the source database (204) includes scanning connections between the database components (204 a, . . . , 204 n) of the source database (204).

18. 14. The system of claim 13, wherein the refactored database structure (506a, ..., 506n) is generated according to the target database (424) while maintaining connections between the database components (204a, ..., 204n) of the source database (204).

19. The system of claim 13 , wherein the refactored database structure (506 a, ..., 506 n) is identified by an AI engine (152).

20. The system of claim 13 , wherein the refactoring module (132) further comprises migrating, by the processor (122), dictionaries and keywords from the source application environment according to a target application environment.

21. The system of claim 13 , wherein the replatforming module (134) further comprises implementing, by the processor (122), scripts from the source application environment according to a target application environment.

22. 14. The system of claim 13, wherein the plurality of modules (128) are further configured to access, by the processor (122), application code (202) including business logic, links, rules engines, libraries of available environments, standard tools, and coding languages.

23. 14. The system of claim 13, wherein the source database (204) of an application environment is migrated to the target database (424) including the steps of re-evolving the environment from the source to the target database, refactoring from the source to the target database, re-hosting from the source to the target database, and re-platforming from the source to the target database.

Images