Description:FIELD OF THE INVENTION
[0001] The present invention relates to cloud computing platforms for application discovery and migration planning.
BACKGROUND FOR THE INVENTION:
[0002] A cloud platform comprises a hardware-software integrated system wherein hardware components such as processors, memory units, storage devices, and network-enabled computing infrastructure operate in conjunction with software components such as data extraction engines, transformation modules, analysis algorithms, orchestration layers, and workflow management systems. The hardware components provide computational resources and storage capabilities, while the software components execute programmatic instructions to perform data collection, processing, analysis, and visualization operations. The interaction between hardware and software elements enables the cloud platform to manage virtualized computing environments, process application data, and facilitate workload migration operations.
[0003] Application discovery for cloud migration requires accurate dependency identification between applications and services through connection pattern detection, data flow path mapping, and communication relationship documentation. Traditional point-in-time discovery mechanisms capture dependency snapshots during brief scanning windows, failing to detect intermittent connections from scheduled operations, batch processes, or time-specific workflows occurring outside scanning periods. Incomplete dependency mapping causes migration planning errors, application move failures, broken service connections, and operational disruptions.
[0004] Comprehensive dependency coverage necessitates multiple scanning iterations across different time-periods, generating substantial computational overhead through processor cycles, memory bandwidth, network capacity, and storage operations consumption. Repeated discovery operations create data management complexity requiring deduplication, reconciliation, and temporal correlation of overlapping dependency records while maintaining dataset consistency. Extended monitoring periods increase dependency coverage but consume target system resources longer, while brief monitoring windows minimize resource impact but risk missing intermittent dependencies. Multi-tenant cloud environments require isolation mechanisms preventing data leakage between tenants while maintaining shared infrastructure efficiency and scaling resource allocation based on concurrent discovery operations across tenant instances .
[0005] US2023185687A1 provides an agentless system and method for discovering and inspecting applications and services in computing environments. However, the system does not disclose near real-time streaming with progressive dependency graph population.
[0006] US2020057665A1 provides methods and systems for identifying application components in distributed computing facilities.However, the system lacks time-windowed collection with automatic expiration after a specified period.
[0007] US2018316568A1 provides systems and methods for networked microservice modeling in distributed cloud environments. However, the system lacks time-windowed collection with specified duration and automatic agent termination.
[0008] US2017195183A1 provides a distributed computing dependency management system. The system facilitates automatic discovery and analysis of dependencies and dependents of dependency service tenants.
[0009] Therefore, there is a need for a system (cloud platform) or such provisions which overcome the problems of the prior art.
OBJECTS OF THE INVENTION:
[0010] An object of the present invention is to provide a cloud platform that enables continuous dependency capture over an extended time-period for detecting intermittent and time-dependent application connections missed by instantaneous scanning operations.
[0011] One more object of the present invention is to provide a system that reduces computational overhead by avoiding repeated discovery executions through sustained monitoring operations that progressively accumulate dependency information during a single extended collection cycle.
[0012] One more object of the present invention is to provide a mechanism for real-time streaming and progressive merging of dependency data with existing configuration records as information is collected, enabling incremental population of dependency details during the monitoring period.
[0013] One more object of the present invention is to provide a multi-tenant Software-as-a-Service platform architecture that maintains logical isolation of tenant-specific dependency data while enabling shared infrastructure utilization and dynamic resource scaling based on concurrent discovery operations.
SUMMARY OF THE INVENTION:
[0014] Application discovery for cloud migration requires accurate dependency identification between applications and services within computing environments, but traditional instantaneous scanning mechanisms only capture dependency snapshots at single time points based on active connections observed during brief scanning windows. The present invention provides a cloud platform for continuous dependency capture in application discovery that addresses limitations of conventional point-in-time scanning approaches. The invention enables detection of intermittent and time-dependent application connections through sustained monitoring operations spanning extended time-periods. The invention reduces computational overhead by eliminating repeated discovery executions and instead accumulates dependency information progressively during single extended collection cycles. The invention provides real-time streaming and progressive merging of dependency data with existing configuration records, enabling incremental population of dependency details during monitoring periods. The invention supports multi-tenant Software-as-a-Service deployment that maintains logical isolation of tenant-specific dependency data while enabling shared infrastructure utilization and dynamic resource scaling.
[0015] A discovery orchestrator manages dependency discovery operations by dynamically deploying lightweight collection modules (LCM) on target application virtual machines to execute for predefined time-periods. The LCM periodically collects upstream dependency data representing outbound connections and downstream dependency data representing inbound connections at regular intervals throughout predefined time-periods. Collection agents stream collected dependency data to discovery servers in real-time through persistent network connections and terminate execution by removing executable codes from target virtual machines upon expiration of predefined time-periods. Discovery servers receive streamed dependency data, progressively merge incoming dependency data with existing configuration item records as data arrives, and generate time-aware dependency mappings based on progressively merged dependency data.
[0016] The LCM operates with minimal resource consumption to avoid impacting application performance on target virtual machines. Extended monitoring over predefined time-periods enables capture of dependencies that occur sporadically or during specific time windows such as overnight backup operations, weekly reporting cycles, monthly financial close processes, and seasonal business activities. Real-time streaming eliminates local storage requirements on target virtual machines and enables immediate processing and visualization of dependency information. Progressive merging constructs dependency relationships incrementally throughout discovery processes, allowing users to access partial results and begin migration planning before discovery completion. Time-aware dependency mappings include temporal context indicating when dependencies were observed, providing richer intelligence than static connection lists.
[0017] The invention achieves comprehensive dependency coverage by maintaining continuous monitoring throughout business cycles, batch processing schedules, and maintenance windows rather than limiting observation to brief scanning periods. Extended execution of collection agents over sufficient durations eliminates need for repeated discovery runs against same target virtual machines, reducing system load through decreased agent deployments, reduced network traffic, and elimination of redundant data collection. Progressive accumulation within unified datasets avoids data management complexity associated with reconciling multiple separate collections from repeated executions. Adaptive duration mechanisms optimize monitoring periods by extending observation when new dependencies continue appearing and terminating when dependency data reaches steady states indicating comprehensive capture.
[0018] Dependency visualization modules provide graphical representations through progressively updated virtual machine-level and application-level dependency graphs that refresh as new dependency information becomes available. Progressive population enables real-time dependency analysis during discovery operations rather than waiting for complete data collection. Software-as-a-Service deployment supports multiple customer organizations through multi-tenant architectures with tenant isolation layers segregating tenant-specific dependency data across tenant instances hosted on shared infrastructure. Subscription management modules authenticate tenant users and authorize access based on subscription tiers, while API gateways expose endpoints for programmatic access returning time-aware dependency mappings as API responses. Scalability engines dynamically provision compute resources and auto-scale shared infrastructure based on concurrent discovery processes across tenant instances.
[0019] The invention includes a cloud platform with integrated discovery orchestrators and discovery servers. A non-transitory computer-readable media store executable instructions for continuous dependency capture. A method embodiments define steps for configuration, deployment, data collection, streaming, termination, reception, progressive merging, and dependency mapping generation.
BRIEF DESCRIPTION OF DRAWINGS:
[0020] Figure 1 shows a schematic block diagram of the cloud platform in accordance with the present invention.
[0021] Figures 2, 3, 4, and 5 show schematic block diagrams illustrating various components of the cloud platform shown in figure 1;
[0022] Figure 6 shows a flowchart of a method for continuous dependency capture in application discovery in accordance with the present invention.
DETAILED DESCRIPTION OF DRAWINGS:
[0023] The present invention provides a cloud platform (200) (Figure 1) for continuous dependency capture in application discovery for cloud migration is configured in a network enabled computing device (205) having one or more memories (210a, 210b) and one or more processors (215a, 215b). The cloud platform (200) provides an integrated system for discovering and mapping application dependencies in virtualized environments over extended time-periods. The network enabled computing device (205) includes physical or virtual computing infrastructure capable of executing software components and storing data in the one or more memories (210a, 210b).
[0024] In one embodiment, the one or more memories (210a, 210b) include random access memory (RAM) modules configured to store executable program code and runtime data. In another embodiment, the one or more memories (210a, 210b) includes a combination of volatile memory such as DDR4 SDRAM (Trade name) and non-volatile memory such as solid-state drives. The one or more processors (215a, 215b) execute instructions stored in the one or more memories (210a, 210b) to perform computational operations for dependency discovery and mapping.
[0025] In one embodiment, the one or more processors (215a, 215b) include multi-core x86 architecture processors such as Intel® Xeon® (Trade name) processors. In another embodiment, the one or more processors (215a, 215b) include ARM-based processors configured for cloud computing workloads. According to an embodiment, the one or more processors (215a, 215b) include AMD EPYC™ (Trade name) processors configured with multiple processing cores for parallel execution of discovery operations.
[0026] A discovery orchestrator (220) is configured in the memory (210a, 210b) and executed by the processor (215a, 215b) to manage and coordinate dependency discovery operations. The discovery orchestrator (220) is configured to initiate a discovery process (225) by dynamically deploying a lightweight collection module (LCM) (230) on a target application virtual machine (VM) (235) to execute for a predefined time-period (240).
[0027] In one embodiment, the discovery orchestrator (220) comprises a Java-based orchestration service executed within a container runtime such as Docker® (Trade name). In another embodiment, the discovery orchestrator (220) includes a Python-based orchestration framework configured with scheduling capabilities for managing multiple concurrent discovery operations. The discovery process (225) includes operations such as including agent deployment, data collection coordination, and monitoring activities controlled by the discovery orchestrator (220).
[0028] The discovery orchestrator (220) dynamically deploys the LCM (230) by transmitting executable code to the target application virtual machine (VM) (235) through network communication channels. In one embodiment, the discovery orchestrator (220) utilizes secure shell (SSH) protocol for deploying the LCM (230) to the target application virtual machine (VM) (235). In another embodiment, the discovery orchestrator (220) employs remote procedure call (RPC) mechanisms for agent deployment operations.
[0029] The LCM (230) includes executable software installed and executed on the target application virtual machine (VM) (235) for the predefined time-period (240). The target application virtual machine (VM) (235) includes a virtualized computing instance hosting one or more application workloads within a cloud computing environment. The LCM (230) operates with minimal resource consumption to avoid impacting the performance of applications running on the target application virtual machine (VM) (235).
[0030] In one embodiment, the LCM (230) includes a compiled binary executable of less than 50 megabytes in size configured to consume less than 5% of processor capacity of the target application virtual machine (VM) (235). In another embodiment, the LCM (230) comprises a script-based agent written in a scripting language such as Python or PowerShell configured for cross-platform compatibility. The predefined time-period (240) specifies the duration for which the LCM (230) remains active and collects dependency information from the target application virtual machine (VM) (235).
[0031] The LCM (230) is configured to periodically collect an upstream dependency data (245) representing an outbound connections (250) from the target application virtual machine (VM) (235) and a downstream dependency data (255) representing inbound connections (260) to the target application virtual machine (VM) (235). The upstream dependency data (245) includes information about network connections, service calls, and data requests initiated by applications on the target application virtual machine (VM) (235) to external systems. The outbound connections (250) include transmission control protocol (TCP) connections, user datagram protocol (UDP) connections, and application-level protocol connections originating from the target application virtual machine (VM) (235).
[0032] In one embodiment, the LCM (230) collects the upstream dependency data (245) by monitoring network socket operations using system-level application programming interfaces. In another embodiment, the LCM (230) utilizes packet capture mechanisms to inspect network traffic for identifying the outbound connections (250). According to an embodiment, the LCM (230) employs operating system hooks to intercept network calls and extract connection metadata for the upstream dependency data (245).
[0033] The downstream dependency data (255) comprises information about network connections, service requests, and data transmissions received by applications on the target application virtual machine (VM) (235) from external systems. The inbound connections (260) include TCP connections, UDP connections, and application-level protocol connections terminating at the target application virtual machine (VM) (235). In one embodiment, the LCM (230) monitors listening ports and incoming network traffic to capture the downstream dependency data (255). In another embodiment, the LCM (230) analyzes server logs and connection states to identify the inbound connections (260).
[0034] The LCM (230) performs periodic collection at regular intervals throughout the predefined time-period (240) to capture dependency patterns over time. In one embodiment, the periodic collection occurs at intervals of 30 seconds to capture frequent connection patterns. In another embodiment, the periodic collection occurs at intervals of 5 minutes to balance coverage with resource consumption. According to an embodiment, the collection interval dynamically adjusts based on observed connection frequency to optimize data capture efficiency.
[0035] In one embodiment, the LCM (230) implements an adaptive interval adjustment mechanism (290) comprising a frequency-analysis module that maintains a sliding window buffer of connection events and calculates moving averages of connection establishment rates over consecutive 5-minute observation periods. The adaptive interval adjustment mechanism (290) includes threshold comparison logic that increases the collection interval from 30 seconds to 2 minutes when connection frequency falls below a baseline threshold of 5 connections per observation window and decreases the interval to 15 seconds when frequency exceeds 20 connections per observation window. The adaptive interval adjustment mechanism (290) further includes an oscillation prevention module (292) that applies exponential smoothing algorithms with a decay factor of 0.3 to connection frequency calculations, wherein recent observations are weighted more heavily than historical data to prevent rapid interval switching.
[0036] The LCM (230) is configured to stream the collected upstream and downstream dependency data (245, 255) to a discovery server (265) in real-time. The streaming operation transmits dependency information from the LCM (230) to the discovery server (265) as the dependency data (245, 255) is collected, without waiting for the predefined time-period (240) to expire. The real-time streaming enables progressive analysis and visualization of dependency information during the discovery process (225).
[0037] In one embodiment, the LCM (230) establishes a persistent websocket connection to the discovery server (265) for streaming the dependency data (245, 255). In another embodiment, the LCM (230) utilizes a message queue protocol such as Advanced Message Queuing Protocol AMQP™ (Trade name) for transmitting the collected dependency data (245, 255) to the discovery server (265). According to an embodiment, the LCM (230) employs representational state transfer (REST) application programming interface calls to send the dependency data (245, 255) to the discovery server (265) at regular intervals.
[0038] The LCM (230) is configured to terminate execution and remove one or more executable codes (270a, 270b) from the target application virtual machine (VM) (235) upon expiration of the predefined time-period (240). The termination operation stops all monitoring activities performed by the LCM (230) and returns the target application virtual machine (VM) (235) to its original state. The one or more executable codes (270a, 270b) comprise binary files, script files, configuration files, and temporary data files created by the LCM (230) during deployment and execution.
[0039] In one embodiment, the LCM (230) performs self-termination by monitoring elapsed time and comparing the elapsed time against the predefined time-period (240). In another embodiment, the discovery orchestrator (220) sends a termination signal to the LCM (230) to trigger the cleanup process. The removal of the one or more executable codes (270a, 270b) ensures that no residual agent components remain on the target application virtual machine (VM) (235) after discovery completion.
[0040] In one embodiment, the LCM (230) deletes the one or more executable codes (270a, 270b) by executing system-level file deletion commands. In another embodiment, the LCM (230) invokes uninstallation scripts that remove all agent-related files and directories from the target application virtual machine (VM) (235). According to an embodiment, the cleanup process includes reverting any configuration changes made during agent installation to restore the original system state.
[0041] The discovery server (265) is configured in the memory (210a, 210b) and executed by the processor (215a, 215b) to receive, process, and store dependency information collected from one or more LCMs (230). The discovery server (265) comprises server software that manages incoming data streams, performs data integration operations, and generates dependency mapping outputs. The discovery server (265) operates continuously throughout multiple concurrent discovery processes (225) initiated across different target application virtual machines (235).
[0042] In one embodiment, the discovery server (265) comprises a web server application configured with custom servlets for processing dependency data streams. In another embodiment, the discovery server (265) comprises a microservices-based architecture deployed on a container orchestration platform such as Kubernetes (Trade name). According to an embodiment, the discovery server (265) utilizes a distributed computing framework for parallel processing of dependency data from multiple agents.
[0043] The discovery server (265) is configured to receive the streamed dependency data (245, 255) in real-time as transmitted by the LCM (230). The discovery server (265) maintains network listeners and data ingestion endpoints to accept incoming data streams from multiple LCMs (230) operating across different target application virtual machines (235). The real-time reception enables the discovery server (265) to process dependency information immediately upon arrival without waiting for batch uploads.
[0044] In one embodiment, the discovery server (265) utilizes network sockets listening on designated ports to receive the dependency data (245, 255) transmitted over TCP connections. In another embodiment, the discovery server (265) employs message broker systems to receive and queue the incoming dependency data (245, 255) for processing. According to an embodiment, the discovery server (265) implements load balancing across multiple server instances to handle high volumes of concurrent data streams from numerous LCMs (230).
[0045] The discovery server (265) is configured to progressively merge the incoming dependency data (245, 255) with one or more existing configuration item (CI) records (275a, 275b) as the dependency data (245, 255) is received. The progressive merging operation integrates newly collected dependency information with previously stored configuration data without waiting for the discovery process (225) to complete. The one or more existing configuration item (CI) records (275a, 275b) include data entries representing virtual machines, applications, services, and infrastructure components previously discovered or imported into the cloud platform (200).
[0046] In one embodiment, the discovery server (265) performs the progressive merging by matching incoming dependency data (245, 255) against the one or more existing configuration item (CI) records (275a, 275b) based on unique identifiers such as internet protocol (IP) addresses, hostnames, or service identifiers. In another embodiment, the discovery server (265) employs fuzzy matching algorithms to correlate the dependency data (245, 255) with the one or more existing configuration item (CI) records (275a, 275b) when exact matches are not available. According to an embodiment, the merging process updates attributes of the one or more existing configuration item (CI) records (275a, 275b) by appending new connection information to existing dependency lists stored in the records.
[0047] The progressive merging enables incremental construction of dependency relationships as data arrives from the LCM (230) over the predefined time-period (240). In one embodiment, the discovery server (265) utilizes a relational database management system such as PostgreSQL® (Trade name) to store and update the one or more existing configuration item (CI) records (275a, 275b) during the merging process. In another embodiment, the discovery server (265) employs a NoSQL database such as MongoDB® (Trade name) for flexible schema storage of the configuration item (CI) records (275a, 275b) and associated dependency information.
[0048] The discovery server (265) is configured to generate one or more time-aware dependency mappings (280a, 280b) based on a progressively merged dependency data (285). The one or more time-aware dependency mappings (280a, 280b) include data structures representing relationships between configuration items with temporal context indicating when dependencies were observed during the predefined time-period (240). The progressively merged dependency data (285) includes the integrated dataset resulting from combining the incoming dependency data (245, 255) with the one or more existing configuration item (CI) records (275a, 275b).
[0049] In one embodiment, the one or more time-aware dependency mappings (280a, 280b) include directed graph structures where nodes represent configuration items and edges represent dependencies annotated with timestamps of observation. In another embodiment, the one or more time-aware dependency mappings (280a, 280b) include tabular data structures storing source configuration item identifiers, destination configuration item identifiers, connection types, and temporal attributes. According to an embodiment, the discovery server (265) generates the time-aware dependency mappings (280a, 280b) by analyzing patterns in the progressively merged dependency data (285) to identify persistent connections, intermittent connections, and temporal connection characteristics.
[0050] The generation of the time-aware dependency mappings (280a, 280b) occur continuously as new dependency data (245, 255) is merged, enabling real-time visibility into evolving dependency relationships. In one embodiment, the discovery server (265) employs graph processing algorithms to construct and update the time-aware dependency mappings (280a, 280b) as the progressively merged dependency data (285) accumulates. In another embodiment, the discovery server (265) utilizes statistical analysis techniques to classify dependencies in the time-aware dependency mappings (280a, 280b) based on connection frequency, duration, and temporal patterns observed in the progressively merged dependency data (285).
[0051] The cloud platform (200) includes a dependency visualization module (300) (Figure 2) configured to provide graphical representations of dependency relationships discovered during the discovery process (225). The dependency visualization module (300) comprises software components that generate and render visual dependency graphs based on the time-aware dependency mappings (280a, 280b) produced by the discovery server (265). The dependency visualization module (300) enables users to view and analyze application dependencies through interactive graphical interfaces.
[0052] In one embodiment, the dependency visualization module (300) comprises a web-based visualization framework implemented using JavaScript libraries such as D3.js™ (Trade name). In another embodiment, the dependency visualization module (300) utilizes a graph visualization library such as Cytoscape.js™ (Trade name) for rendering complex dependency networks. According to an embodiment, the dependency visualization module (300) implements a rich client application using frameworks for building interactive user interfaces.
[0053] The dependency visualization module (300) is configured to progressively update a VM-level dependency graph (305) based on the time-aware dependency mappings (280a, 280b) during the predefined time-period (240). The VM-level dependency graph (305) includes a visual representation showing dependency relationships between individual virtual machines including the target application virtual machine (VM) (235) and other virtual machines communicating with the target application virtual machine (VM) (235). The progressive update mechanism refreshes the VM-level dependency graph (305) as new dependency information becomes available through the time-aware dependency mappings (280a, 280b).
[0054] In one embodiment, the VM-level dependency graph (305) displays virtual machines as nodes and network connections as directed edges indicating the direction of communication. In another embodiment, the VM-level dependency graph (305) incorporates visual attributes such as node colors, edge thicknesses, and annotations to represent connection characteristics including frequency, bandwidth, and protocol types. The progressive updating during the predefined time-period (240) allows users to observe the evolution of dependencies as the LCM (230) continues collecting data from the target application virtual machine (VM) (235).
[0055] In one embodiment, the dependency visualization module (300) updates the VM-level dependency graph (305) at intervals of 1 minute to reflect newly merged dependency data (285). In another embodiment, the dependency visualization module (300) implements event-driven updates where the VM-level dependency graph (305) refreshes immediately upon receiving notifications of new time-aware dependency mappings (280a, 280b) from the discovery server (265).
[0056] The dependency visualization module (300) is configured to progressively update an application-level dependency graph (320) based on the time-aware dependency mappings (280a, 280b) during a specified time-period (315). The application-level dependency graph (320) includes a visual representation showing dependency relationships between logical applications, services, or application tiers rather than individual virtual machines. The application-level dependency graph (320) aggregates VM-level dependencies by grouping related virtual machines into application components based on metadata, naming conventions, or user-defined mappings.
[0057] In one embodiment, the application-level dependency graph (320) displays applications as high-level nodes with dependencies between applications shown as edges connecting the nodes. In another embodiment, the application-level dependency graph (320) utilizes hierarchical visualization techniques where application nodes can be expanded to reveal constituent virtual machines and their individual dependencies. The specified time-period (315) may correspond to the predefined time-period (240) or may represent a different time window for analyzing dependency evolution.
[0058] In one embodiment, the dependency visualization module (300) generates the application-level dependency graph (320) by applying grouping rules that associate virtual machines with application identifiers based on tags or labels in the one or more existing configuration item (CI) records (275a, 275b). In another embodiment, the dependency visualization module (300) employs machine learning algorithms to automatically cluster related virtual machines into application groups based on communication patterns observed in the time-aware dependency mappings (280a, 280b). According to an embodiment, the progressive updates to the application-level dependency graph (320) occur synchronously with updates to the VM-level dependency graph (305) to maintain consistency between different visualization levels.
[0059] The cloud platform (200) streams the collected dependency data (245, 255) for enabling progressive population (325) (Figure 2) of dependency details (330) during the predefined time-period (240). The progressive population (325) comprises a mechanism for incrementally building and displaying dependency information as data is collected and processed, rather than waiting for the predefined time-period (240) to expire before presenting results. The dependency details (330) include specific information about discovered dependencies including source and destination identifiers, connection types, protocols, ports, and temporal characteristics.
[0060] In one embodiment, the progressive population (325) updates user interface elements displaying the dependency details (330) at regular intervals as new dependency data (245, 255) arrives at the discovery server (265). In another embodiment, the progressive population (325) utilizes push notification mechanisms such as server-sent events to deliver updated dependency details (330) to client applications in real-time. According to an embodiment, the cloud platform (200) implements the progressive population (325) using streaming data pipelines that continuously transform raw dependency data (245, 255) into formatted dependency details (330) suitable for presentation.
[0061] The streaming of the collected dependency data (245, 255) directly supports the progressive population (325) by ensuring continuous data flow from the LCM (230) through the discovery server (265) to presentation layers. In one embodiment, the dependency details (330) are organized in tabular formats listing individual connection records with associated timestamps indicating when each connection was observed. In another embodiment, the dependency details (330) include summary statistics such as connection counts, unique endpoint counts, and dependency coverage percentages that update progressively during the predefined time-period (240).
[0062] The predefined time-period (240) (Figure 3) can be defined by multiple alternative mechanisms to accommodate different discovery scenarios and operational requirements. The predefined time-period (240) determines how long the LCM (230) remains active on the target application virtual machine (VM) (235) collecting dependency information. The flexibility in defining the predefined time-period (240) enables optimization of discovery operations for various application characteristics, resource constraints, and coverage objectives.
[0063] In one embodiment, the predefined time-period (240) is defined by a fixed duration parameter (240a) specifying an absolute time interval selected from a group consisting of minutes, hours, days, and weeks. The fixed duration parameter (240a) establishes a predetermined length of time during which the LCM (230) executes regardless of other conditions or events. The fixed duration parameter (240a) provides predictable execution windows suitable for scheduling discovery operations around maintenance windows or business cycles.
[0064] In one embodiment, the fixed duration parameter (240a) specifies a duration of 7 days to capture weekly application patterns including business day operations and weekend activities. In another embodiment, the fixed duration parameter (240a) specifies a duration of 24 hours to observe daily application cycles including business hours, batch processing windows, and off-peak periods. According to an embodiment, the fixed duration parameter (240a) is configured to 2 hours for rapid discovery of frequently executed dependencies in high-transaction applications.
[0065] In one embodiment, the discovery orchestrator (220) determines the fixed duration parameter (240a) of 7 days by analyzing patterns in the upstream dependency data (245) and downstream dependency data (255) collected during previous discovery processes (225), wherein weekly business cycles including Monday-Friday operational dependencies and weekend maintenance operations require 168-hour observation periods to achieve comprehensive dependency coverage. The discovery server (265) validates 24-hour durations by progressively merging dependency data (285) and monitoring when the time-aware dependency mappings (280a, 280b) reach steady state, indicating that daily batch processing cycles and business hour patterns have been fully captured within the predefined time-period (240).
[0066] The LCM (230) utilizes 2-hour durations for high-transaction applications by monitoring connection establishment rates through the system-level network socket monitoring APIs referenced in paragraph 32, wherein rapid dependency changes in frequently executed applications achieve 80% coverage within 120-minute observation windows based on connection frequency-analysis performed by the discovery server (265).
[0067] In another embodiment, the predefined time-period (240) is defined by a scheduled time window (240b) defining a start time and an end time for the discovery process (225) based on business operating hours or peak traffic periods. The scheduled time window (240b) aligns discovery operations with specific calendar time ranges to focus collection on periods when relevant application activity occurs. The scheduled time window (240b) enables targeted dependency capture during known operational periods while avoiding resource consumption during inactive periods.
[0068] In one embodiment, the scheduled time window (240b) defines a start time of 8:00 AM and an end time of 6:00 PM on business days to capture dependencies during standard business operating hours. In another embodiment, the scheduled time window (240b) spans from 12:00 PM to 2:00 PM to focus on peak traffic periods when maximum user activity generates representative dependency patterns. According to an embodiment, the scheduled time window (240b) is configured to execute during month-end processing periods to capture financial close dependencies that occur only at specific calendar intervals.
[0069] In another embodiment, the predefined time-period (240) is defined by an event-driven trigger (240c) configured to terminate the LCM (230) upon detection of a predefined event selected from a group consisting of completion of a full application cycle, occurrence of a specified number of dependency captures, reaching a data volume threshold, and receiving an external termination signal. The event-driven trigger (240c) enables dynamic termination based on operational conditions rather than elapsed time. The event-driven trigger (240c) optimizes resource utilization by ending collection when sufficient data has been gathered or when specific milestones are reached.
[0070] In one embodiment, the event-driven trigger (240c) monitors for completion of a full application cycle by detecting when the application on the target application virtual machine (VM) (235) has executed all scheduled jobs and returned to an idle state. In another embodiment, the event-driven trigger (240c) counts the number of unique dependencies captured and terminates the LCM (230) when the specified number of dependency captures is reached. According to an embodiment, the event-driven trigger (240c) monitors accumulated data volume and terminates collection when the data volume threshold of 100 megabytes is exceeded to prevent excessive storage consumption.
[0071] In some embodiments, the event-driven trigger (240c) listens for external termination signals transmitted by administrators or monitoring systems when manual intervention is required to stop discovery operations. The external termination signal may be transmitted through application programming interface calls, command-line interfaces, or graphical user interfaces to provide immediate control over agent execution.
[0072] In another embodiment, the predefined time-period (240) is defined by an adaptive duration parameter (240d) that dynamically adjusts the time-period based on real-time analysis of dependency data stability. The adaptive duration parameter (240d) monitors characteristics of the incoming dependency data (245, 255) to determine when sufficient coverage has been achieved. The time-period is extended when new dependencies are being discovered and terminated when dependency data reaches a steady state indicating comprehensive capture.
[0073] In one embodiment, the adaptive duration parameter (240d) calculates a rate of new dependency discovery by measuring the number of unique dependencies captured per unit time. In another embodiment, the adaptive duration parameter (240d) employs statistical analysis to detect when the rate of new dependency discovery falls below a threshold percentage indicating that most dependencies have been captured. According to an embodiment, the adaptive duration parameter (240d) extends the predefined time-period (240) by additional intervals when new unique connections continue to appear in the upstream dependency data (245) or the downstream dependency data (255).
[0074] The steady state determination evaluates whether the set of discovered dependencies has stabilized over recent observation windows. In one embodiment, the adaptive duration parameter (240d) considers dependency data to have reached steady state when no new unique dependencies are observed over a consecutive period of 2 hours. In another embodiment, the adaptive duration parameter (240d) applies moving average calculations to dependency discovery rates to smooth fluctuations and identify true stabilization points.
[0075] For example, if the LCM (230) discovers 12 new unique connections in hours 1-4, 8 connections in hours 5-8, 15 connections in hours 9-12, 6 connections in hours 13-16, 10 connections in hours 17-20, and 4 connections in hours 21-24. The moving average equals (12+8+15+6+10+4)/6 = 9.17 new connections per 4-hour window. The discovery server (265) extends the predefined time-period (240) when this moving average remains above a threshold of 5 new connections per window, indicating continued dependency discovery activity.
[0076] In another embodiment, the predefined time-period (240) is defined by a coverage-based duration (240e) configured to continue execution until a predefined coverage threshold is achieved. The coverage-based duration (240e) establishes completion criteria based on the comprehensiveness of discovered dependencies rather than time or events. The coverage threshold is determined by at least one of percentage of known endpoints discovered, number of unique connections captured, and completeness of upstream and downstream dependency mapping.
[0077] In one embodiment, the coverage-based duration (240e) maintains a list of expected endpoints based on configuration data in the one or more existing configuration item (CI) records (275a, 275b) and calculates the percentage of known endpoints discovered by comparing captured dependencies against the expected list. In another embodiment, the coverage-based duration (240e) sets a target number of unique connections to capture and continues execution of the LCM (230) until the target number is reached. According to an embodiment, the coverage-based duration (240e) evaluates completeness by verifying that both upstream dependencies represented by outbound connections (250) and downstream dependencies represented by inbound connections (260) have been captured for all major application components.
[0078] The predefined coverage threshold may be configured as an absolute value or a percentage based on organizational requirements. In one embodiment, the coverage-based duration (240e) terminates the LCM (230) when 95% of expected endpoints have been discovered. In another embodiment, the coverage-based duration (240e) requires capture of at least 100 unique connections before allowing termination.
[0079] In another embodiment, the predefined time-period (240) is defined by a resource-constrained duration (240f) that limits execution based on computational resource utilization of the target application virtual machine (VM) (235). The resource-constrained duration (240f) monitors resource consumption metrics to ensure the LCM (230) does not adversely impact applications running on the target application virtual machine (VM) (235). The LCM (230) terminates when resource consumption exceeds a predefined threshold to protect application performance.
[0080] In one embodiment, the resource-constrained duration (240f) monitors processor utilization of the target application virtual machine (VM) (235) and terminates the LCM (230) when total processor utilization exceeds 90% for sustained periods. In another embodiment, the resource-constrained duration (240f) tracks memory consumption by the LCM (230) and triggers termination when the agent's memory footprint exceeds 500 megabytes. According to an embodiment, the resource-constrained duration (240f) evaluates network bandwidth utilization caused by streaming the dependency data (245, 255) to the discovery server (265) and terminates collection if bandwidth consumption impacts application traffic.
[0081] The predefined threshold for resource consumption is configurable based on the criticality and resource sensitivity of applications on the target application virtual machine (VM) (235). In one embodiment, the resource-constrained duration (240f) employs dynamic thresholds that adjust based on baseline resource utilization patterns observed before agent deployment. In another embodiment, the resource-constrained duration (240f) implements rate limiting on data collection and streaming operations to maintain resource consumption below the predefined threshold throughout the execution period.
[0082] In another embodiment, the predefined time-period (240) is defined by a user-configurable duration (240g) specified through a graphical user interface (GUI) or an application programming interface (API) allowing customization based on application-specific requirements. The user-configurable duration (240g) provides flexibility for operators to define execution periods tailored to unique application characteristics, organizational policies, or discovery objectives. The user-configurable duration (240g) accepts duration specifications in various formats and units to accommodate different operational preferences.
[0083] In one embodiment, the graphical user interface for specifying the user-configurable duration (240g) comprises web-based forms with input fields for entering duration values and selecting units such as minutes, hours, or days. In another embodiment, the application programming interface for the user-configurable duration (240g) accepts duration specifications as parameters in representational state transfer (REST) API requests formatted as ISO 8601 duration strings. According to an embodiment, the user-configurable duration (240g) supports both absolute duration specifications and scheduled time windows entered through calendar picker interfaces in the graphical user interface.
[0084] The user-configurable duration (240g) may include validation logic to ensure specified durations fall within acceptable ranges defined by system administrators. In one embodiment, the user-configurable duration (240g) restricts duration specifications to a minimum of 1 hour and a maximum of 30 days. In another embodiment, the user-configurable duration (240g) provides preset duration options such as "Quick Scan (2 hours)", "Standard Discovery (1 week)", and "Comprehensive Discovery (1 month)" to simplify configuration for common scenarios.
[0085] The cloud platform (200) avoids repeated discovery runs (335) (Figure 4) for reducing system load (340). The repeated discovery runs (335) refer to multiple executions of the discovery process (225) against the same the target application virtual machine (VM) (235) to capture dependencies occurring at different times. The system load (340) comprises computational overhead, network bandwidth consumption, and storage utilization incurred by discovery operations across the cloud platform (200).
[0086] By executing the LCM (230) for the predefined time-period (240) that spans sufficient duration to capture time-varying dependencies, the cloud platform (200) eliminates the need to repeatedly initiate new discovery processes (225). In one embodiment, the cloud platform (200) tracks which target application virtual machines (235) have undergone discovery and prevents scheduling of additional discovery runs (335) for those virtual machines during overlapping time-periods. In another embodiment, the cloud platform (200) extends the predefined time-period (240) to encompass multiple business cycles, thereby capturing varied dependency patterns within a single continuous execution rather than requiring multiple separate executions.
[0087] The reduction in system load (340) results from decreased agent deployment operations, reduced network traffic from multiple agent installations, and elimination of redundant data collection and processing. In one embodiment, avoiding repeated discovery runs (335) reduces processor utilization on the discovery orchestrator (220) by consolidating multiple deployment operations into a single extended execution. In another embodiment, the cloud platform (200) achieves storage efficiency by accumulating dependency data (245, 255) progressively within the same dataset rather than generating multiple separate datasets requiring subsequent merging operations.
[0088] The cloud platform (200) operates the LCM (230) for the predefined time-period (240) to capture one or more intermittent dependencies (345a, 345b) (Figure 4) and one or more time-dependent dependencies (350a, 350b) missed by a point-in-time discovery (355). The one or more intermittent dependencies (345a, 345b) comprise connections that occur sporadically or at irregular intervals rather than continuously throughout the observation period. The one or more-time-dependent dependencies (350a, 350b) include connections that activate only during specific time windows such as business hours, batch processing schedules, or maintenance windows.
[0089] The point-in-time discovery (355) represents conventional discovery approaches that capture dependency information during brief scanning windows of several minutes or hours. The point-in-time discovery (355) generates a snapshot of active connections present at the moment of scanning but fails to detect dependencies that occur outside the scanning window. By extending observation over the predefined time-period (240), the cloud platform (200) ensures capture of dependencies that would be missed by the point-in-time discovery (355) due to temporal characteristics.
[0090] In one embodiment, the one or more intermittent dependencies (345a, 345b) include backup operations that execute once daily during overnight hours, which would be missed by the point-in-time discovery (355) conducted during business hours. In another embodiment, the one or more-time-dependent dependencies (350a, 350b) include payroll processing connections that activate only during bi-weekly payroll cycles. According to an embodiment, the extended duration of the predefined time-period (240) spans at least one full week to ensure capture of the one or more intermittent dependencies (345a, 345b) and the one or more-time-dependent dependencies (350a, 350b) associated with weekly business cycles.
[0091] The LCM (230) continuously monitors and collects dependency information throughout the predefined time-period (240), ensuring that connections occurring at any point during the period are captured in the upstream dependency data (245) and the downstream dependency data (255). In one embodiment, the discovery server (265) marks captured dependencies in the time-aware dependency mappings (280a, 280b) with frequency indicators distinguishing the intermittent dependencies (345a, 345b) from continuously active connections. In another embodiment, the time-aware dependency mapping (280a, 280b) include temporal annotations indicating specific time ranges when the time-dependent dependencies (350a, 350b) were observed, enabling migration planning that accounts for time-specific connectivity requirements.
[0092] The cloud platform (200) is deployed as a Software-as-a-Service (SaaS) platform (400) (figure 5) comprising multiple integrated components for multi-tenant operation. The Software-as-a-Service (SaaS) platform (400) provides dependency discovery capabilities as a cloud-hosted service accessible to multiple customers through subscription-based access. The SaaS deployment model eliminates the need for customers to install and maintain discovery infrastructure locally, instead providing centralized hosted services operated by a service provider.
[0093] The Software-as-a-Service (SaaS) platform (400) includes a multi-tenant architecture (405) configured to host a plurality of tenant instances (410a, 410b) on a shared infrastructure (415) and logically isolate tenant-specific dependency data (420) using a tenant isolation layer (425). The multi-tenant architecture (405) enables efficient resource utilization by serving multiple customers from common hardware and software infrastructure while maintaining separation of customer data and operations. The tenant instances (410a, 410b) represent distinct customer organizations or business units utilizing the Software-as-a-Service (SaaS) platform (400).
[0094] The shared infrastructure (415) includes computing resources including processors, memory, storage, and network components that are pooled and allocated dynamically across the plurality of tenant instances (410a, 410b). In one embodiment, the shared infrastructure (415) includes virtualized server clusters running on hypervisor platforms. In another embodiment, the shared infrastructure (415) includes container-based infrastructure orchestrated by Kubernetes (Trade name) for elastic scaling and resource allocation.
[0095] The tenant-specific dependency data (420) includes dependency information, configuration records, and discovery results belonging to individual tenant instances from the tenant instances (410a, 410b). The tenant isolation layer (425) implements security mechanisms to prevent unauthorized access to the tenant-specific dependency data (420) across different tenant instances. In one embodiment, the tenant isolation layer (425) employs database-level isolation where each tenant stores the tenant-specific dependency data (420) in separate database schemas or separate database instances. In another embodiment, the tenant isolation layer (425) implements row-level security policies that filter query results based on tenant identifiers to ensure the tenant-specific dependency data (420) is accessible only to authorized users from the corresponding tenant instance.
[0096] The Software-as-a-Service (SaaS) platform (400) includes a subscription management module (430) configured to authenticate tenant users (435) and authorize access to the discovery orchestrator (220) and the discovery server (265) based on subscription tiers (440a, 440b). The subscription management module (430) comprises software components that manage user identity, access control, and service entitlements for the plurality of tenant instances (410a, 410b). The tenant users (435) comprise individuals associated with tenant instances who access the Software-as-a-Service (SaaS) platform (400) to initiate discovery operations and view dependency analysis results.
[0097] In one embodiment, the subscription management module (430) implements authentication mechanisms using security protocols such as OAuth 2.0 or Security Assertion Markup Language (SAML) to verify the identity of the tenant users (435). In another embodiment, the subscription management module (430) integrates with identity providers for centralized user authentication. According to an embodiment, the subscription management module (430) maintains user credential databases and session management systems to track authenticated sessions of the tenant users (435).
[0098] The subscription tiers (440a, 440b) define different service levels with varying capabilities, resource limits, and access permissions. In one embodiment, the subscription tiers (440a, 440b) include a basic tier with limited discovery operations per month and a premium tier with unlimited discovery operations and advanced features. In another embodiment, the subscription tiers (440a, 440b) differentiate based on the number of target application virtual machines (235) that can be discovered concurrently. The subscription management module (430) enforces authorization policies by checking the subscription tier associated with a tenant instance before allowing access to the discovery orchestrator (220) and the discovery server (265).
[0099] In one embodiment, the subscription management module (430) implements role-based access control where tenant users (435) are assigned roles such as administrator, operator, or viewer with corresponding permissions for initiating discovery processes (225), configuring discovery parameters, or viewing time-aware dependency mappings (280a, 280b). In another embodiment, the subscription management module (430) tracks usage metrics for each tenant instance and enforces quota limits defined by the subscription tiers (440a, 440b), such as limiting the number of concurrent LCMs (230) deployed across target application virtual machines (235).
[00100] The Software-as-a-Service (SaaS) platform (400) includes an API gateway (445) configured to expose API endpoints (450) for programmatic access to the discovery process (225) and return the time-aware dependency mappings (280a, 280b) as API responses (455). The API gateway (445) provides a standardized interface for external applications and scripts to interact with the Software-as-a-Service (SaaS) platform (400) without requiring graphical user interface access. The API endpoints (450) comprise uniform resource locator (URL) paths and associated HTTP methods for invoking specific operations such as initiating discovery, querying discovery status, and retrieving dependency data.
[00101] In one embodiment, the API gateway (445) implements representational state transfer (REST) architectural principles with API endpoints (450) accessible via HTTP or HTTPS protocols. In another embodiment, the API gateway (445) supports GraphQL query language for flexible data retrieval where clients specify exactly which fields of the time-aware dependency mappings (280a, 280b) to include in API responses (455). According to an embodiment, the API gateway (445) is implemented using an API management platform which provides traffic management, authentication, and monitoring capabilities.
[00102] The API responses (455) include data payloads returned by the API gateway (445) in response to client requests submitted to the API endpoints (450). In one embodiment, the API responses (455) are formatted as JavaScript Object Notation (JSON) documents containing the time-aware dependency mappings (280a, 280b) with structured representations of dependencies, configuration items, and temporal attributes. In another embodiment, the API responses (455) support multiple content formats including extensible markup language (XML) and comma-separated values (CSV) based on accept headers specified in client requests.
[00103] The API gateway (445) handles authentication and authorization for programmatic access by validating API keys or bearer tokens included in requests to the API endpoints (450). In one embodiment, the API gateway (445) issues API keys associated with tenant instances that must be included in request headers for access to the API endpoints (450). In another embodiment, the API gateway (445) implements OAuth 2.0 token-based authentication where tenant users (435) obtain access tokens through an authorization flow and present the tokens in API requests. According to an embodiment, the API gateway (445) enforces rate limiting on requests to the API endpoints (450) based on the subscription tiers (440a, 440b) to prevent abuse and ensure fair resource allocation across tenant instances.
[00104] The present invention provides a Software-as-a-Service (SaaS) platform (400) deployed on the cloud platform (200) provides dependency discovery as a centralized subscription-based service and includes a multi-tenant architecture (405) that hosts a plurality of tenant instances (410a, 410b) on a shared infrastructure (415). A tenant isolation layer (425) of the SaaS platform (400) isolates tenant-specific dependency data (420) using database-level isolation or row-level security. A subscription management module (430) of the SaaS platform (400) authenticates tenant users (435) using OAuth 2.0, SAML, or identity providers which enforces subscription tiers (440a, 440b). An API gateway (445) of of the SaaS platform (400) exposes API endpoints (450) using REST, HTTPS, or GraphQL and returns API responses (455) in JSON, XML, or CSV with authentication through API keys or OAuth 2.0 tokens.
[00105] A scalability engine (460) included in the SaaS platform (400) dynamically provisions compute resources (465) and auto scales the shared infrastructure (415) based on concurrent discovery processes (225) and resource utilization metrics such as processor load, memory consumption, and network throughput. The compute resources (465) support operation of the discovery orchestrator (220), the LCM (230), and the discovery server (265). The scalability engine (460) performs proactive scale-up during increasing discovery demand and performs graceful scale-down after completion of active discovery processes. This configuration enables secure, isolated, and efficient multi-tenant dependency discovery across the SaaS platform (400).
[00106] The present invention provides a non-transitory computer-readable medium (600) (figure 1) stores computer-executable instructions that, when executed by one or more processors (215a, 215b) of the network enabled computing device (205), cause the processors (215a, 215b) to perform operations for continuous dependency capture in application discovery for cloud migration.
[00107] The non-transitory computer-readable medium (600) includes a solid-state drive utilizing flash memory technology. The non transitory computer readable medium (600) stores the computer executable instructions that implement the operations of the cloud platform (200). The medium (600) includes flash based solid state storage, optical media such as CD ROM or DVD, or magnetic storage such as a hard disk drive. The instructions instantiate the discovery orchestrator (220), the LCM (230), and the discovery server (265) in the memory (210a, 210b) and configure network communication, time tracking for the predefined time-period (240), encryption, parsing, and runtime control logic.
[00108] The executable instructions cause the discovery orchestrator (220) to deploy the LCM (230) onto the target application virtual machine (235) and initiate the discovery process (225). The instructions executed by the LCM (230) perform periodic collection of the upstream dependency data (245) and downstream dependency data (255), stream the data to the discovery server (265), and remove the executable codes (270a, 270b) after completion. The instructions executed by the discovery server (265) receive and buffer the dependency data, progressively merge it with the configuration item records (275a, 275b), and generate the time aware dependency mappings (280a, 280b) using timestamp based processing.
[00109] In one embodiment, a method (1000) (Figure 6) is provided.
[00110] The method (1000) starts at step (1000a).
[00111] At step 1010, the discovery orchestrator (220) and the discovery server (265) are configured in the memory (210a) and executed by the processor (215a).
[00112] At step 1020, the discovery process (225) is initiated by dynamically deploying the LCM (230) on the target application virtual machine (VM) (235) to execute for the predefined time-period (240) by the discovery orchestrator (220). At step 1030, includes a step of the upstream dependency data (245) representing the outbound connections (250) are periodically collecting from the target application virtual machine (VM) (235) by the LCM (230).
[00113] At step 1040, includes a step the downstream dependency data (255) representing the inbound connections (260) are periodically collecting to the target application virtual machine (VM) (235) by the LCM (230). At step 1050 the collected upstream and downstream dependency data (245, 255) of streamed to the discovery server (265) in real-time by the LCM (230).
[00114] At step 1060, the one or more executable codes (270a, 270b) are terminated execution and removed from the target application virtual machine (VM) (235) upon expiration of the predefined time-period (240) by the LCM (230). At step 1070, the streamed dependency data (245, 255) is received in real-time by the discovery server (265).
[00115] At step 1080, the incoming dependency data (245, 255) progressively merged with the one or more existing configuration item (CI) records (275a, 275b) as the dependency data (245, 255) is received by the discovery server (265). At step 1090, the time-aware dependency mappings (280a, 280b) are generated based on the progressively merged dependency data (285) by the discovery server (265).
[00116] The method (1000) ends at step (1000b).
[00117] The cloud platform (200) enables long‑duration application discovery for cloud migration, rationalization, compliance, and disaster‑recovery planning by capturing persistent, intermittent, and time‑dependent dependencies across web, application, database, and integration tiers through the LCM (230) over the predefined time-period (240). The Software‑as‑a‑Service (SaaS) platform (400) delivers these capabilities across multiple tenant instances (410a, 410b) using the multi‑tenant architecture (405), the shared infrastructure (415), and the subscription management module (430) to isolate tenant‑specific dependency data (420). Users access the VM‑level dependency graph (305), the application‑level dependency graph (320), and the time‑aware dependency mappings (280a, 280b) to design target cloud architectures, validate DR configurations, and enforce security and compliance requirements through captured upstream dependency data (245) and downstream dependency data (255).
[00118] The non‑transitory computer‑readable medium (600) distributes the same discovery capabilities into regulated or air‑gapped environments, where the one or more processors (215a, 215b) execute the computer‑executable instructions locally for continuous dependency capture. The method (1000) integrates these operations into automated cloud‑migration workflows through the initiating step (1010), the streaming step (1040), the receiving step (1060), the progressively merging step (1070), and the generating step (1080) to maintain continuously updated dependency intelligence. The API gateway (445) exposes the API endpoints (450) enabling external systems to consume the time‑aware dependency mappings (280a, 280b) as the API responses (455) for orchestration, compliance reporting, and security monitoring.
[00119] The present invention has the technical advantage of providing continuous, low overhead dependency discovery through the LCM (230), which captures the upstream dependency data (245) and downstream dependency data (255) over the predefined time-period (240) while maintaining CPU and memory consumption below defined thresholds on the target application virtual machine (235). The discovery server (265) enhances dependency intelligence by progressively merging incoming data with the configuration item records (275a, 275b) and generating the time aware dependency mappings (280a, 280b) with temporal context.
[00120] The cloud platform (200) reduces repeated discovery runs (335) and system load (340) by sustaining long duration monitoring that captures intermittent dependencies (345a, 345b) and time dependent dependencies (350a, 350b) that point in time discovery (355) cannot detect. The dependency visualization module (300) further enables real time analysis by continuously updating the VM level dependency graph (305) and the application level dependency graph (320) during ongoing discovery.
[00121] The present invention also has the technical advantage of enabling scalable multi tenant service delivery, offline deployment, and repeatable procedural execution across diverse computing environments through multiple delivery embodiments. The Software as a Service (SaaS) platform (400) supports isolated multi tenant operation using the multi tenant architecture (405), the tenant isolation layer (425), the scalability engine (460), and the subscription management module (430), while the API gateway (445) exposes the API endpoints (450) that return the time aware dependency mappings (280a, 280b) as the API responses (455) for automation workflows.
[00122] The non transitory computer readable medium (600) provides deployment in regulated or air gapped environments by enabling the one or more processors (215a, 215b) to execute the discovery instructions locally with identical functional behavior. The method (1000) ensures standardized, repeatable operations across the initiating step (1010), collecting steps (1020, 1030), streaming step (1040), receiving step (1060), progressively merging step (1070), and generating step (1080), enabling integration into migration pipelines and infrastructure as code workflows.
[00123] All third-party trademarks, service marks, trade names, or product names appearing in this specification are the property of their respective owners. They are used solely for identification, descriptive, or illustrative purposes to demonstrate interoperability or compatibility with the systems, platforms, or services referenced herein. Such use does not imply any affiliation, endorsement, or relationship between the applicant and the respective trademark owners. All rights in the referenced trademarks are hereby acknowledged.
[00124] All copyrighted materials, technical specifications, software code, and intellectual property referenced herein remain the property of their respective copyright holders. Such materials are referenced solely for technical illustration or comparative analysis without implying any license grant, authorization, or relationship between the applicant and respective owners. No copyrighted content has been reproduced or incorporated into this specification.
[00125] This specification provides complete disclosure under Section 10(4) of the Patents Act, 1970, enabling a person skilled in the art to carry out the invention without undue experimentation, satisfying enablement and best mode requirements.
[00126] The invention demonstrates technical effect beyond abstract algorithms or computer programmes per se excluded under Section 3(k) of the Patents Act, 1970, providing tangible technical solutions through hardware-software integration and automated processing capabilities, overcoming exclusions under the Computer Related Inventions Guidelines, 2025. , Claims:CLAIMS
We Claim:
1) A cloud platform (200) for continuous dependency capture in application discovery for cloud migration, the cloud platform (200) configured in a network enabled computing device (205) having one or more memories (210a, 210b) and one or more processors (215a, 215b), the cloud platform (200) comprises:
a discovery orchestrator (220) configured in the memory (210a/ 210b) and executed by the processor (215a/ 215b) and the discovery orchestrator (220) is configured to initiate a discovery process (225) by dynamically deploying a lightweight collection module (LCM) (230) on a target application virtual machine (VM) (235) to execute for a predefined time-period (240), wherein the LCM (230) is configured to:
periodically collect upstream dependency data (245) representing outbound connections (250) from the target application VM (235) and downstream dependency data (255) representing inbound connections (260) to the target application VM (235);
stream the collected upstream and downstream dependency data (245, 255) to a discovery server (265) in real-time; and
terminate execution and remove one or more executable codes (270a, 270b) from the target application VM (235) upon expiration of the predefined time-period (240);
wherein the discovery server (265) is configured in the memory (210a, 210b) and executed by the processor (215a, 215b) and the discovery server (265) is configured to:
receive the streamed dependency data (245, 255) in real-time;
progressively merge the incoming dependency data (245, 255) with one or more existing configuration item (CI) records (275a, 275b) as the dependency data (245, 255) is received; and
generate one or more time-aware dependency mappings (280a, 280b) based on the progressively merged dependency data (285).
2) The cloud platform (200) as claimed in claim 1, wherein the cloud platform (200) comprises a dependency visualization module (300) (DVM) configured to progressively update a VM-level dependency graph (305) based on the time-aware dependency mappings (280a, 280b) during the predefined time-period (240); and progressively update an application-level dependency graph (320) based on the time-aware dependency mappings (280a, 280b) during the specified time-period (315).
3) The cloud platform (200) as claimed in claim 1, wherein the cloud platform (200) streams the collected dependency data (245, 255) for enabling progressive population (325) of dependency details (330) during the predefined time-period (240).
4) The cloud platform (200) as claimed in claim 1, wherein the cloud platform (200) operates the LCM (230) for the predefined time-period (240) to capture one or more intermittent dependencies (345a, 345b) and one or more time-dependent dependencies (350a, 350b) missed by a point-in-time discovery (355).
5) The cloud platform (200) as claimed in claim 1, wherein the cloud platform (200) is deployed as a Software-as-a-Service (SaaS) platform (400) comprising:
a multi-tenant architecture (405) configured to host a plurality of tenant instances (410a, 410b) on a shared infrastructure (415) and logically isolate tenant-specific dependency data (420) using a tenant isolation layer (425);
a subscription management module (430) configured to authenticate tenant users (435) and authorize access to the discovery orchestrator (220) and the discovery server (265) based on subscription tiers (440a, 440b);
an API gateway (445) configured to expose API endpoints (450) for programmatic access to the discovery process (225) and return the time-aware dependency mappings (280a, 280b) as API responses (455); and
a scalability engine (460) configured to dynamically provision computing resources (465) and auto-scale the shared infrastructure (415) based on concurrent discovery processes (225) initiated by the tenant instances (410a, 410b).
6) A non-transitory computer-readable medium (600) storing computer-executable instructions that, when executed by one or more processors (215a, 215b) of a network enabled computing device (205), cause the one or more processors (215a, 215b) to perform operations for continuous dependency capture in application discovery for cloud migration, the operations comprising:
initiating, by a discovery orchestrator (220), a discovery process (225) by dynamically deploying a LCM (230) on a target application virtual machine (VM) (235) to execute for a predefined time-period (240);
periodically collecting, by the LCM (230), upstream dependency data (245) representing outbound connections (250) from the target application VM (235) and downstream dependency data (255) representing inbound connections (260) to the target application VM (235);
streaming, by the LCM (230), the collected upstream and downstream dependency data (245, 255) to a discovery server (265) in real-time;
terminating execution and removing, by the LCM (230), one or more executable codes (270a, 270b) from the target application VM (235) upon expiration of the predefined time-period (240);
receiving, by the discovery server (265), the streamed dependency data (245, 255) in real-time;
progressively merging, by the discovery server (265), the incoming dependency data (245, 255) with one or more existing configuration item (CI) records (275a, 275b) as the dependency data (245, 255) is received; and
generating, by the discovery server (265), one or more time-aware dependency mappings (280a, 280b) based on the progressively merged dependency data (285).
7) A method (1000) for continuous dependency capture in application discovery for cloud migration, the method (1000) implemented by a cloud platform (200) configured in a network enabled computing device (205) having one or more memories (210a, 210b) and one or more processors (215a, 215b), the method (1000) comprising steps of:
configuring (1010) a discovery orchestrator (220) and the discovery server (265) in the memory (210a) and executed by the processor (215a);
initiating (1020) a discovery process (225) by dynamically deploying a lightweight collection module (LCM) (230) on a target application virtual machine (VM) (235) to execute for a predefined time-period (240) by the discovery orchestrator (220);
periodically collecting (1030) upstream dependency data (245) representing outbound connections (250) from the target application VM (235) by the LCM (230);
periodically collecting (1040) downstream dependency data (255) representing inbound connections (260) to the target application VM (235) by the LCM (230);
streaming (1050) the collected upstream and downstream dependency data (245, 255) to a discovery server (265) in real-time by the LCM (230);
terminating (1060) execution and removing one or more executable codes (270a, 270b) from the target application VM (235) upon expiration of the predefined time-period (240) by the LCM (230);
receiving (1070) the streamed dependency data (245, 255) in real-time by the discovery server (265);
progressively merging (1080) of the incoming dependency data (245, 255) with one or more existing configuration item (CI) records (275a, 275b) as the dependency data (245, 255) is received by the discovery server (265); and
generating (1090) one or more time-aware dependency mappings (280a, 280b) based on the progressively merged dependency data (285) by the discovery server (265).
Dated this 30th January 2026

BALIP AMIT ABASAHEB [IN/PA-5184]