Systems, methods, and apparatuses for scanning a legacy database

Abstract

Embodiments herein relate to replacing a legacy Pick environment with a modern microservice architecture. A legacy database and a modern database may be operated in parallel for data validation. Part of the data validation may include scanning the legacy database for updates to items stored thereon. Embodiments herein may generate an update message by combining item keys from across the multiple files that correspond with a same business object.

Description

TECHNICAL FIELD

The present disclosure relates generally to data validation when replacing a database. More specifically, the present disclosure relates to methods, systems, and apparatuses for detecting updates to records in a legacy database that is running in parallel with a modern database.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

To easily identify the discussion of any particular element or act, the most significant digit or digits in a reference number refer to the figure number in which that element is first introduced.

FIG. 1 illustrates a block diagram of a data system transitioning from a dealer management system to a microservice system in accordance with one embodiment.

FIG. 2 illustrates a signal flow diagram for scanning a dealer management system for updates in accordance with one embodiment.

FIG. 3 illustrates a method for scanning for updates in a legacy database system in accordance with one embodiment.

FIG. 4 is a block diagram of an update scanner in accordance with one embodiment.

DETAILED DESCRIPTION

Described herein are embodiments of systems, apparatuses, and methods for data validation when replacing a database. A system may periodically request updates to records in a legacy database that is running in parallel with a modern database. The system may convert the legacy database records into update messages that are more efficient for the modern database to use for data validation.

Businesses occasionally replace and modernize their database environments. Often the move from a legacy database environment to a modern database environment involves moving between two different incompatible data architectures. Additionally, there is often a desire to gradually transition between the legacy database and the modern database to allow for data validation of the modern database while allowing applications to take advantage of the modern database. To provide data validation in some embodiments the two databases may be run in parallel and a validation system may compare updates to records in the legacy database against updates to the modern database. However, because the databases have different data architectures, comparing the updates may be inefficient.

One of the challenges of the transition between databases is handling the large number of updates to the legacy database. To address this challenge, embodiments below include a scanner service that are configured to scan and recognize business objects across the multiple records of the legacy database. The scanner service may use a timestamp associated with each update to the records in the legacy database to check for updates to the legacy data. The scanner service may filter out updates that are not part of a business object as well as combine separate components that together comprise a business object. The scanner service may provide an update message with the filtered and combined results.

Specific embodiments herein relate to replacing a legacy Pick environment with a modern microservice architecture. While movement between a Pick environment and a modern microservice architecture is discussed herein, embodiments herein may also be applied to transitioning between other database types.

The phrases “coupled to,” “connected to,” and “in communication with” refer to any form of interaction between two or more components, including mechanical, electrical, magnetic, and electromagnetic interaction. Two components may be connected to each other, even though they are not in direct contact with each other, and even though there may be intermediary devices between the two components.

It will be readily understood that the components of the embodiments as generally described below and illustrated in the Figures herein could be arranged and designed in a wide variety of different configurations. For instance, the steps of a method do not necessarily need to be executed in any specific order, or even sequentially, nor do the steps need to be executed only once. Thus, the following more detailed description of various embodiments, as described below and represented in the Figures, is not intended to limit the scope of the disclosure but is merely representative of various embodiments. While the various aspects of the embodiments are presented in the drawings, the drawings are not necessarily drawn to scale unless specifically indicated.

Embodiments and implementations of systems and methods described herein may include various steps, which may be embodied in machine-executable instructions to be executed by a computer system. A computer system may include one or more general-purpose or special-purpose computers (or other electronic devices). The computer system may include hardware components that include specific logic for performing the steps or may include a combination of hardware, software, and/or firmware.

Embodiments may be provided as a computer program product including a computer-readable medium having stored thereon instructions that may be used to program a computer system or other electronic device to perform the processes described herein. The computer-readable medium may include, but is not limited to: hard drives, floppy diskettes, optical disks, CD-ROMs, DVD-ROMs, ROMs, RAMs, EPROMs, EEPROMs, magnetic or optical cards, solid-state memory devices, or other types of media/computer-readable media suitable for storing electronic instructions.

Computer systems and the computers in a computer system may be connected via a network. Suitable networks for configuration and/or use as described herein include one or more local area networks, wide area networks, metropolitan area networks, and/or Internet or Internet Protocol (IP) networks, such as the World Wide Web, a private Internet, a secure Internet, a value-added network, a virtual private network, an extranet, an intranet, or even stand-alone machines that communicate with other machines by physical transport of media. In particular, a suitable network may be formed from parts or entireties of two or more other networks, including networks using disparate hardware and network communication technologies.

One suitable network includes a server and several clients; other suitable networks may contain other combinations of servers, clients, and/or peer-to-peer nodes, and a given computer system may function both as a client and as a server. Each network includes at least two computers or computer systems, such as the server and/or clients. A computer system may include a workstation, laptop computer, mobile computer, server, mainframe, cluster, so-called “network computer” or “thin client,” tablet, smart phone, personal digital assistant or other hand-held computing device, “smart” consumer electronics device or appliance, medical device, or combination thereof.

Suitable networks may include communications or networking software, such as the software available from Novell®, Microsoft®, and other vendors, and may operate using Transfer Control Protocol (TCP)/IP, SPX, IPX, and other protocols over twisted pair, coaxial, or optical fiber cables; telephone lines; radio waves; satellites; microwave relays; modulated AC power lines; physical media transfer; and/or other data transmission “wires” known to those of skill in the art. The network may encompass smaller networks and/or be connectable to other networks through a gateway or similar mechanism.

Each computer system includes one or more processors and/or memory; computer systems may also include various input devices and/or output devices. The processor may include a general-purpose device, such as an Intel®, AMD®, or other “off-the-shelf” microprocessor. The processor may include a special-purpose processing device, such as an ASIC, SoC, SiP, FPGA, PAL, PLA, FPLA, PLD, or other customized or programmable device. The memory may include static RAM, dynamic RAM, flash memory, one or more flip-flops, ROM, CD-ROM, disk, tape, magnetic, optical, or other computer storage medium. The input device(s) may include a keyboard, mouse, touch screen, light pen, tablet, microphone, sensor, or other hardware with accompanying firmware and/or software. The output device(s) may include a monitor or other display, printer, speech or text synthesizer, switch, signal line, or other hardware with accompanying firmware and/or software.

The computer systems may be capable of using a floppy drive, a tape drive, an optical drive, a magneto-optical drive, or other means to read a storage medium. A suitable storage medium includes a magnetic, an optical, or other computer-readable storage device having a specific physical configuration. Suitable storage devices include floppy disks, hard disks, tape, CD-ROMs, DVDs, PROMs, RAM, flash memory, and other computer system storage devices. The physical configuration represents data and instructions that cause the computer system to operate in a specific and predefined manner as described herein.

Suitable software to assist in implementing the invention is readily provided by those of skill in the pertinent art(s) using the teachings presented here and programming languages and tools, such as Modern Fortran, Java, Pascal, C++, C, PHP, .Net, database languages, APIs, SDKs, assembly, firmware, microcode, and/or other languages and tools. Suitable signal formats may be embodied in analog or digital form, with or without error detection and/or correction bits, packet headers, network addresses in a specific format, and/or other supporting data readily provided by those of skill in the pertinent art(s).

Aspects of certain embodiments may be implemented as software modules or components. As used herein, a software module or component may include any type of computer instruction or computer executable code located within or on a computer-readable storage medium. A software module may, for instance, comprise one or more physical or logical blocks of computer instructions, which may be organized as a routine, a program, an object, a component, a data structure, etc. that performs one or more tasks or implement particular abstract data types. A particular software module may comprise disparate instructions stored in different locations of a computer-readable storage medium, which together implement the described functionality of the module. Indeed, a module may comprise a single instruction or many instructions, and may be distributed over several different code segments, among different programs, and across several computer-readable storage media.

Some embodiments may be practiced in a distributed computing environment where tasks are performed by a remote processing device linked through a communications network. In a distributed computing environment, software modules may be located in local and/or remote computer-readable storage media. In addition, data being tied or rendered together in a database record may be resident in the same computer-readable storage medium, or across several computer-readable storage media, and may be linked together in fields of a record in a database across a network. According to one embodiment, a database management system (DBMS) allows users to interact with one or more databases and provides access to the data contained in the databases.

FIG. 1 illustrates a block diagram of a data system 100 transitioning from a dealer management system 110 to a microservice system 112. As shown, the data system 100 may operate two databases in parallel during a transition from a legacy database (e.g., dealer management system 110) to a modern database (e.g., microservice system 112).

Running the two databases in parallels may allow for a gradual rollout of the new architecture in a way that permits data validation and allows older applications to take advantage of the new environment. For example, an application running on a computing device 108 may have been developed for the legacy dealer management system 110. To upgrade to the microservice system 112 it may be desirous to have the application access both the microservice system 112 and the dealer management system 110 in parallel and track the changes in the dealer management system 110 in comparison to the microservice system 112 to validate that all of the changes to data in the dealer management system 110 are being captured by the microservice system 112.

For example, a business may desire to replace a legacy Pick environment (e.g., dealer management system 110) with a modern microservice architecture. A Pick environment includes an operating system for databases that was developed decades ago. The Pick environment has an architecture with a centralized dealer management system 110 with applications and a legacy Pick database 102. A dealer management system 110 may refer to a stand-alone computer system that hosts the legacy data and code. Each client (i.e., a user of the data system 100) may have at least one dealer management system 110 to host the client's applications and data. Occasionally a client may have more than one dealer management system 110.

The legacy software and database for the dealer management system 110 may have been developed over a long period of time. As a consequence, there may be a very large amount of messy code, messy database design, and complexity. For example, information corresponding to a specific object (e.g., customer, vendor, financial institution) controlled by the application of the computing device 108 may be spread over several data files. To further complicate matters, the data files may not be homogenous with respect to one object. For example, information corresponding to a customer may be in the same data file as information corresponding to a vendor. This unorganized and complicated set of data files may make it difficult to track changes to each object.

In contrast to the organization of the dealer management system 110, the new microservice system 112 may have a data architecture that structures an application as a collection of services 114. For example, the application controllable objects that are spread across multiple data files in the dealer management data system 100 may be ordered according to independent services 114. This change in data architecture and the complexity of the dealer management system 110 makes data validation difficult and inefficient.

To reduce the complexity and improve efficiency of data validation, an update scanner 104 may track, filter, and compile updates to information corresponding to the objects as discussed in more detail below. The update scanner 104 may send a message to a microservice database manager 106 indicating updates to records associated with the objects. Each message may contain all updates for an object to reduce the number of messages sent.

FIG. 2 illustrates a signal flow diagram for scanning a dealer management system 110 for updates according to one embodiment. In the illustrated embodiment, the dealer management system 110 belongs to a car dealership. However, a similar system may be set up for other types of clients. The dealer management system 110 comprises an update scanner 104 and a legacy Pick database 102. The update scanner 104 monitors the legacy Pick database 102 for changes and provides an update message 212 comprising a compilation of any detected changes.

The legacy Pick database 102 may comprise a plurality of data files (e.g., a name-file 202, service-names 204, and customer comments 206). Each data file may comprise a series of items or records that make up data elements of the data file. As the legacy Pick database 102 may have been developed and updated for several decades, there may be a very large amount of messy code, messy database design, and complexity that makes it difficult to completely replicate the functions of the legacy Pick database 102 on a new database system.

Accordingly, data validation may be desirous. Data validation may include determining that the updates occurring on the legacy Pick database 102 are also captured on the new database system that is running in parallel. Part of determining that the updates have occurred on both systems includes monitoring changes on the legacy Pick database 102. However, the data structure of the legacy Pick database 102 may make it difficult to track the updates to a new data structure.

For example, the new data structure may be developed around a plurality of objects. Objects, also referred to herein as business objects, may be a collection of closely related data elements, items, and/or records that represent information that a client business works with. For example, business objects may include customers, vehicles, and vehicle purchase contracts. Items related to one object may be incorporated into multiple data files on the legacy Pick database 102.

Additionally, each data file in the legacy Pick database 102 may include items related to multiple objects. Items are stored in the data files. A Pick item may correspond roughly to a record in a modern database. In other words, a Pick item may be described as a document, rather than a record. An example of a non-homogenous file may include the name-file 202. The name-file 202 may contain most of the customer business object information. However, the name-file 202 may also contains information about other business objects, such as employees, vendors, financial institutions, and more. In some embodiments, a customer item in the name-file 202 may also even contain accounts receivable amounts and aging information.

As shown, the update scanner 104 may comprise an update decipherer 210 and a sync tool 208. The update decipherer 210 may be a daemon or service that runs on the legacy system (e.g., dealer management system 110). The update decipherer 210 is configured to recognize items in the data files that comprise different business objects. The sync tool 208 may be a service that also runs on the legacy system. It may not be able to recognize business objects like the update decipherer 210, but it may be able to poll the data files and return keys to the latest updates for files. The update decipherer 210 may be able to search for Pick files, items within the Pick files, and the timestamps stored with items.

To scan for updates to the legacy Pick database 102, the update decipherer 210 may periodically request 214 the latest updates to Pick data files. The update decipherer 210 sends the request 214 to the sync tool 208. In some embodiments, the request 214 may include a uniform resource identifier (URI). The URI may identify one or more data files to be checked for updates and an indication of a desired period of time during which the updates occurred. For example, the update decipherer 210 may send a URI, such as http://localhost:10229/dbsync/v1/D100093794/NAME-FILE?sel=1565724886.475, to the sync tool 208. This example URI requests updates that have occurred in the name-file 202 since 1565724886.475. The update decipherer 210 may send additional requests for other files that contain a business object (e.g., customer information) that the update decipherer 210 is gathering updates for.

The sync tool 208 receives the request and may extract 216 the updated item keys from the data files in the specified time range. The item keys may comprise an item identifier and a timestamp of a last update. The sync tool 208 may return 218 keys corresponding to updates for the data files requested by the update decipherer 210. An example below shows a sample return document that the sync tool 208 may send to the update decipherer 210. The sample return document indicates that items “4*9014” and “4*11341” have been updated in the requested range. In some embodiments, microsecond precise timestamp can be included in the return document.

<?xml version=″1.0″ encoding=″ISO-8859-1″?>
<response>
<pickdata>
<requestparams>
<accountname>TEST-A</accountname>
<timerangebegin>1603192353.0</timerangebegin>
<timerangeend>unspecified</timerangeend>
<file>NAME-FILE</file>
<dictrequested>false</dictrequested>
</requestparams>
<item>
<id>4*9014</id>
<ts>1603193254.561832</ts>
</item>
<item>
<id>4*11341</id>
<ts>1603194551.481608</ts>
</item>
</pickdata>
</response>

The update decipherer 210 may assemble the item keys associated with a business object into an update message 212. To assemble the update message 212, the update decipherer 210 may combine information from multiple data files such as the name-file 202, service-names 204, and customer comments 206. The update decipherer 210 may ignore content from the item keys returned by the sync tool 208 that do not relate to the business object that the update decipherer 210 is compiling the update message 212 for. The update decipherer 210 may generate an update message 212 for customer business objects, vehicle business objects, and vehicle purchase contract business objects. In some embodiments, each update message 212 may include all updates to a single business object during the identified time period. The update decipherer 210 may convert the data that it has compiled into JSON messages for the update message 212. The messages may include one message per customer update. That is, for each customer business object, the update decipherer 210 may send one message.

The update decipherer 210 may send 220 the update message 212 to the modern database system for data verification. In some embodiments, the update message 212 may use Kafka messaging to send information from the legacy system to the new microservice system. In some embodiments, the message may comprise the item keys and update time stamp. For example, the message may look like the following example.

{
″domain″ : ″Customer″,
″enterprise_id″ : ″E207187″,
″keys″ : [
{
″depts″ : [ ″D100093794″ ],
″id″ : ″9014″,
″timestamp″ : ″1603193254.561832″,
″type″ : ″4″
}
],
″store_id″ : ″S100023739″
}

FIG. 3 illustrates a method 300 for scanning for updates in a legacy database system in accordance with one embodiment. The method 300 may be performed by an update scanning system such as the update scanner 104 in FIG. 1. The legacy database may be a Pick environment and the modern database modern microservice architecture.

As shown, a system using the method 300 may request 302 update information for multiple files on the legacy database for a specified time range. The method 300 may further request 214 item keys for items that were updated within the multiple files during the specified time range. The item keys may comprise an item identifier and a timestamp of a last update of the item. The items may be data elements within data files of the legacy database.

The system using the method 300 may receive 304 and process the item keys for items that were updated within the multiple files during the specified time range. To process the item keys, the system may filter 306 item keys based on which business object each item corresponds to. For example, the system may separate items related to customer business objects, employee business objects, vendor business objects, and financial institution business objects. In some embodiments, the data files may not be homogenous with respect to business object content. Thus, the system may need to search multiple data files to find item keys related to each of the business objects.

The system using the method 300 may combine 308 item keys from across the multiple files that correspond with a same business object. The system may assemble or compile these keys into a JSON message to generate 310 an update message. The system may send 312 the update message to the modern database. Additional update messages may be generated for additional business objects, and each update message may comprise all of the item keys associated with a corresponding business object during the specified time range. In some embodiments, the update message comprises a single notification for all updates associated with a same customer account.

FIG. 4 is a block diagram of an update scanner 400 according to one embodiment. The update scanner 400 may perform the methods and use the techniques described with reference to the other Figures in the specification. The update scanner 400 can include a memory 403, one or more processors 404, a network interface 406, an input/output interface 408, and a system bus 409.

The one or more processors 404 may include one or more general-purpose devices, such as an Intel®, AMD®, or other standard microprocessor. The one or more processors 404 may include a special-purpose processing device, such as ASIC, SoC, SiP, FPGA, PAL, PLA, FPLA, PLD, or other customized or programmable device. The one or more processors 404 can perform distributed (e.g., parallel) processing to execute or otherwise implement functionalities of the presently disclosed embodiments. The one or more processors 404 may run a standard operating system and perform standard operating system functions. It is recognized that any standard operating systems may be used, such as, for example, Microsoft® Windows®, Apple® MacOS®, Disk Operating System (DOS), UNIX, IRJX, Solaris, SunOS, FreeBSD, Linux®, ffiM® OS/2® operating systems, and so forth.

The memory 403 may include static RAM, dynamic RAM, flash memory, one or more flip-flops, ROM, CD-ROM, DVD, disk, tape, or magnetic, optical, or other computer storage medium. The memory 403 may include a plurality of program modules 410 and program data 420. The memory 403 may be local to the update scanner 400, as shown, or may be distributed and/or remote relative to the update scanner 400.

Data generated or used by the update scanner 400, such as by the program modules 410 or other modules, may be stored on the memory 403, for example, as stored program data 420. The data 420 may be organized as one or more databases. The data 420 may include item keys 422. The item keys 422 may comprise an item identifier and a timestamp of a last update if the item. The items may be data elements within data files of the legacy database.

The program modules 410 may run multiple operations concurrently or in parallel by or on the one or more processors 404. In some embodiments, portions of the disclosed modules, components, and/or facilities are embodied as executable instructions embodied in hardware or firmware, or stored on a non-transitory, machine-readable storage medium. The executable instructions may comprise computer program code that, when executed by a processor and/or computing device, cause a computing system to implement certain processing steps, procedures, and/or operations, as disclosed herein. The modules, components, and/or facilities disclosed herein may be implemented and/or embodied as a driver, a library, an interface, an API, FPGA configuration data, firmware (e.g., stored on an EEPROM), and/or the like. In some embodiments, portions of the modules, components, and/or facilities disclosed herein are embodied as machine components, such as general and/or application-specific devices, including, but not limited to: circuits, integrated circuits, processing components, interface components, hardware controller(s), storage controller(s), programmable hardware, FPGAs, ASICs, and/or the like. Accordingly, the modules disclosed herein may be referred to as controllers, layers, services, engines, facilities, drivers, circuits, subsystems, and/or the like.

The modules 410 may comprise a requesting tool 412, a filter 414, an assembler 416, and a message generator 418. The requesting tool 412 may request update information for multiple files on the legacy database for a specified time range. The filter 414 may filter the item keys 422 based on which business object each item corresponds to. The assembler may combine the item keys 422 related to a same business object. The item keys 422 may be from across the multiple files. The message generator 418 may generate an update message that may be sent to the modern database.

The input/output interface 408 may facilitate user interaction with one or more input devices and/or one or more output devices. The input device(s) may include a keyboard, mouse, touchscreen, light pen, tablet, microphone, sensor, or other hardware with accompanying firmware and/or software. The output device(s) may include a monitor or other display, printer, speech or text synthesizer, switch, signal line, or other hardware with accompanying firmware and/or software. For example, in one embodiment, the input/output interface 408 comprises a display to provide a graphical user interface (GUI) illustrating the potential ablation perimeters. The input/output interface 408 can receive user input data. In some embodiments, the input/output interface 408 is a touchscreen, and the size input is received via the touchscreen. In some embodiments, the input/output interface 408 can superimpose the target ablation perimeters on an image of the tissue.

The network interface 406 may facilitate communication with other computing devices and/or networks and/or other computing and/or communications networks. The network interface 406 may be equipped with conventional network connectivity, such as, for example, Ethernet (IEEE 1102.3), Token Ring (IEEE 1102.5), Fiber Distributed Datalink Interface (FDDI), or Asynchronous Transfer Mode (ATM). Further, the network interface 406 may be configured to support a variety of network protocols such as, for example, IP, TCP, Network File System over UDP/TCP, Server Message Block (SMB), Microsoft® Common Internet File System (CIFS), Hypertext Transfer Protocols (HTTP), Direct Access File System (DAFS), File Transfer Protocol (FTP), Real-Time Publish Subscribe (RTPS), Open Systems Interconnection (OSI) protocols, Simple Mail Transfer Protocol (SMTP), Secure Shell (SSH), Secure Socket Layer (SSL), and so forth.

The system bus 409 may facilitate communication and/or interaction between the other components of the update scanner 400, including the one or more processors 404, the memory 403, the input/output interface 408, and the network interface 406.

Any methods disclosed herein comprise one or more steps or actions for performing the described method. The method steps and/or actions may be interchanged with one another. In other words, unless a specific order of steps or actions is required for proper operation of the embodiment, the order and/or use of specific steps and/or actions may be modified.

While specific embodiments of stents have been illustrated and described, it is to be understood that the disclosure provided is not limited to the precise configuration and components disclosed. Various modifications, changes, and variations apparent to those of skill in the art having the benefit of this disclosure may be made in the arrangement, operation, and details of the methods and systems disclosed, with the aid of the present disclosure.

Without further elaboration, it is believed that one skilled in the art can use the preceding description to utilize the present disclosure to its fullest extent. The examples and embodiments disclosed herein are to be construed as merely illustrative and exemplary and not a limitation of the scope of the present disclosure in any way. It will be apparent to those having skill in the art and the benefit of this disclosure that changes may be made to the details of the above-described embodiments without departing from the underlying principles of the disclosure herein.

Claims

1. A method for tracking updates to a legacy database, the method comprising: operating a legacy database and a modern database in parallel;requesting update information for multiple files on the legacy database for a specified time range;receiving item keys for items that were updated within the multiple files during the specified time range;filtering each of the item keys based at least on their associated business item and generating an update message by combining item keys from across the multiple files that correspond with a same business object and ignoring item keys not associated with the same business object;sending the update message to the modern database; andbased on receipt of the update message, performing data validation at the modern database, wherein data validation comprises determining the updates to the legacy database are captured on the modern database operating in parallel.

2. The method of claim 1, wherein the legacy database is a Pick environment and the modern database is a modern microservice architecture.

3. The method of claim 1, wherein additional update messages are generated for additional business objects, and wherein each update message comprises all of the item keys associated with a corresponding business object during the specified time range.

4. The method of claim 1, wherein the item keys comprise an item identifier and a timestamp of a last update.

5. The method of claim 1, wherein the business objects comprise customer business objects, employee business objects, vendor business objects, and financial institution business objects.

6. The method of claim 1, wherein the files are not homogenous with respect to business object content.

7. The method of claim 1, wherein the update message comprises a single notification for all updates associated with a same customer account.

8. A computing apparatus comprising: a processor; anda memory storing instructions that, when executed by the processor, configure the apparatus to: request update information for multiple files on a legacy database for a specified time range, wherein the legacy database is operating in parallel with a modern database in parallel;receive item keys for items that were updated within the multiple files during the specified time range;filter each of the item keys based at least on their associated business item and generate an update message by combining item keys from across the multiple files that correspond with a same business object and ignoring item keys associated with the same business object;send the update message to the modern database; andbased on the update message, perform data validation at the modern database to determine the updated item keys for the multiple files on the legacy database are captured on the modern database operating in parallel.

9. The computing apparatus of claim 8, wherein the legacy database is a Pick environment and the modern database is a modern microservice architecture.

10. The computing apparatus of claim 8, wherein additional update messages are generated for additional business objects, and wherein each update message comprises all of the item keys associated with a corresponding business object during the specified time range.

11. The computing apparatus of claim 8, wherein the item keys comprise an item identifier and a timestamp of a last update.

12. The computing apparatus of claim 8, wherein the business objects comprise customer business objects, employee business objects, vendor business objects, and financial institution business objects.

13. The computing apparatus of claim 8, wherein the files are not homogenous with respect to business object content.

14. The computing apparatus of claim 8, wherein the update message comprises a single notification for all updates associated with a same customer account.

15. A non-transitory computer-readable storage medium, the computer-readable storage medium including instructions that when executed by a computer, cause the computer to: request update information for multiple files on a legacy database for a specified time range, wherein the legacy database is operating in parallel with a modern database in parallel;receive item keys for items that were updated within the multiple files during the specified time range;filter each of the item keys based at least on their associated business item and generate an update message by combining item keys from across the multiple files that correspond with a same business object and ignoring item keys associated with the same business object;send the update message to the modern database; andbased on receipt of the update message, perform data validation at the modern database comprising determining updated item keys for the multiple files on the legacy database are captured on the modern database operating in parallel.

16. The computer-readable storage medium of claim 15, wherein the legacy database is a Pick environment and the modern database is a modern microservice architecture.

17. The computer-readable storage medium of claim 15, wherein additional update messages are generated for additional business objects, and wherein each update message comprises all of the item keys associated with a corresponding business object during the specified time range.

18. The computer-readable storage medium of claim 15, wherein the item keys comprise an item identifier and a timestamp of a last update.

19. The computer-readable storage medium of claim 15, wherein the files are not homogenous with respect to business object content.

20. The computer-readable storage medium of claim 15, wherein the update message comprises a single notification for all updates associated with a same customer account.