Patent Description:
Managed service providers (MSPs) are businesses that offer multiple, managed, information technology (IT) services to other businesses. MSPs today largely deliver their services remotely over a network. One of the challenges that MSPs come across is switching between software provided by different vendors. For example, an MSP may use an anti-virus software provided by a first vendor. If a different anti-virus software is introduced into the market by a second vendor, and the different anti-virus software works more efficiently or is cheaper than the anti-virus software being currently used, the MSP may be interested in making a switch. However, this requires a long migration involving customization for the needs of a client, customization for the hardware running the software, and customization to retain features of stored and processed data. Because migration is labor-intensive, unreliable, adds to the total cost of ownership (TCO) of the new software, and causes a decrease in the quality of service (during the change), MSPs are often unwilling to upgrade their infrastructure. Examples of systems/methods for seamless software migration according to the state of the art are disclosed in <CIT> and <CIT>. In particular, <CIT> relates to an update website prioritizing updates available for an application (e.g., a word-processing program or a fault-tolerance program) running on a user computer system. Prioritization is in part a function of usage data gathered on the user computer system by a usage-tracking module of the application. The usage data is transferred to the update site and parameters relevant to prioritization are evaluated. The parameter values are then used for prioritization. The usage data can also be compiled with data from other users to guide further development of the application. Instead <CIT> relates to an invention comprising systems and methods, and computer readable media comprising the methods, for updating software applications. The systems and methods of the present invention provide automation and flexibility to the updating process. Processor usage and network usage are monitored and software updates are initiated and/or continued during periods where processor and/or network usage are low. The update process may be halted when the processor and/or network connection are called upon for other uses. Processor and/or network usage may also be throttled, for example limiting the bandwidth available for the download to maintain sufficient processor share and/or bandwidth for other tasks. Adverse impact on a computer user is minimized.

In order to streamline the upgrading process, disclosed herein are methods and systems for seamlessly migrating from an existing software to a new software.

According to the invention, a method comprises receiving a command to migrate from the existing software to the new software on at least one computing device, wherein the existing software and the new software share a plurality of features. Responsive to receiving the command, the method comprises retrieving usage activity information of the existing software from the at least one computing device and identifying settings from the existing software to migrate. The method further comprises converting, based on an internal database with metadata information about the new software, the settings in the existing software to corresponding settings in the new software. The method further comprises determining, based on the usage activity information, a migration plan indicative of a sequence of tasks for installing the new software and removing the existing software such that a quality of service associated with accessing the plurality of features on the at least one computing device does not decrease to less than a threshold quality of service. The method further comprises executing the sequence of tasks by installing the new software, implementing the corresponding settings, and removing the existing software.

In some examples, the method may comprise presenting the migration plan to an administrator of the at least one computing device, wherein executing the sequence of tasks is in response to receiving an approval of the migration plan from the administrator.

In some examples, the existing software and the new software are anti-virus software, and identifying the settings from the existing software to migrate further comprises identifying at least one of: (<NUM>) an anti-virus scanning schedule, (<NUM>) actions to perform for each type of virus and malware, (<NUM>) exception directories that do not need to be scanned, (<NUM>) authorized users.

According to the present invention, executing the sequence of tasks comprises identifying a feature of the existing software, wherein the feature is in the plurality of features, installing files of the new software associated with the feature, applying a setting of the corresponding settings to the installed files, such that the feature is accessible on the new software, forwarding requests to access the feature received at the at least one computing device to the new software, and removing files of the existing software associated with the feature.

In some examples, determining the migration plan further comprises ranking each respective feature in the plurality of features based on a likelihood of the respective feature being accessed during migration, and scheduling tasks of the sequence of tasks in accordance with the ranking, wherein features with higher likelihoods are scheduled for installation before features with lower likelihoods.

In some examples, determining the migration plan further comprises ranking each respective feature in the plurality of features based on a likelihood of the respective feature being accessed during migration, and scheduling tasks of the sequence of tasks in accordance with the ranking, wherein features with lower likelihoods are scheduled for installation before features with higher likelihoods.

In some examples, identifying the settings of the existing software further comprises identifying at least one setting manually adjusted by a user of the existing software of the at least one computing device.

In some examples, identifying the settings of the existing software further comprises identifying at least one setting for migration in response to determining that the at least one setting has been unchanged by a user of the existing software for more than a threshold period of time.

In some examples, identifying the settings of the existing software further comprises not selecting at least one setting for migration in response to determining that the at least one setting does not optimize the quality of service when accessing at least one feature of the plurality of features on the new software.

In some examples, the existing software and the new software are anti-virus software, and the quality of service is measured based on any combination of: (<NUM>) a time required to perform a scan of the at least one computing device, (<NUM>) an amount of objects scanned on the at least one computing device, (<NUM>) a number of malicious objects found, (<NUM>) an amount of directories that are infected despite an active firewall, and (<NUM>) an amount of time to download new virus definitions.

According to the present invention, it should be noted that the methods described above may be implemented in a system comprising a hardware processor. Alternatively, the methods may be implemented using computer executable instructions of a non-transitory computer readable medium.

The above simplified summary of example embodiments serves to provide a basic understanding of the present disclosure. This summary is not an extensive overview of all contemplated embodiments, and is intended to neither identify key or critical elements of all embodiments nor delineate the scope of any or all embodiments of the present disclosure. Its sole purpose is to present one or more embodiments in a simplified form as a prelude to the more detailed description of the disclosure that follows. To the accomplishment of the foregoing, the one or more embodiments of the present disclosure include the features described and exemplarily pointed out in the claims.

The accompanying drawings, which are incorporated into and constitute a part of this specification, illustrate one or more example embodiments of the present disclosure and, together with the detailed description, serve to explain their principles and implementations.

Exemplary embodiments of the invention are described herein in the context of a system and method for seamlessly migrating from an existing software to a new software. Those of ordinary skill in the art will realize that the following description is illustrative only and is not intended to be in any way limiting. Other embodiments will readily suggest themselves to those skilled in the art having the benefit of this disclosure. Reference will now be made in detail to implementations of the example embodiments as illustrated in the accompanying drawings. The same reference indicators will be used to the extent possible throughout the drawings and the following description to refer to the same or like items.

<FIG> is a block diagram illustrating system <NUM> for seamlessly migrating from an existing software to a new software. In system <NUM>, MSP <NUM> represents a service provider for a plurality of computing devices (e.g., 108a, 108b, 108n, etc.). In the present disclosure, information exchanged between migration server <NUM> and MSP <NUM> may be understood as information exchanged between server <NUM> and a device used by a member of MSP <NUM> (e.g., an administrator).

Migration server <NUM> comprises migration module <NUM> that is configured to orchestrate a seamless migration of software over the plurality of computing devices. Each computing device <NUM> comprises migration agent <NUM>, which may be a client application that communicates with migration module <NUM> on migration server <NUM>. In some examples, migration agent <NUM> is a thin client and migration module <NUM> is a thick client. Communication between MSP <NUM>, migration server <NUM>, and the plurality of computing devices <NUM> may be conducted over the same network. The network may be a local area network (LAN) or a wide area network (WAN) such as the Internet. In some examples, each of the computing devices are independent and are not associated with MSP <NUM>. Accordingly, the software to be installed on a particular computing device (e.g., 108a) is unrelated to MSP <NUM> or any of the other depicted computing devices (e.g., 108b, 108n, etc.).

In an example, migration module <NUM> may receive a command to migrate from an existing software to new software on at least one computing device. In some examples, the command may originate from MSP <NUM>, while in other examples, the command may originate from one of the computing devices <NUM>. It should be noted that each device is labelled in <FIG> with a number, followed by a character (e.g., 'a,' 'b,' 'n', etc.). Only one character is shown for simplicity. The characters are used to identify and group components of a particular computing device. For example, all labels ending in 'a' such as migration agent 114a, settings 112a, software 110a, etc., represent components and software on computing device 108a. In some examples, the command received by migration module <NUM> may further indicate which computing devices to update with new software <NUM>. For example, MSP <NUM> may only want a select few computing devices to be updated with new software <NUM>.

In some examples, in response to receiving the command, migration module <NUM> may determine whether new software <NUM> can be installed on an identified computing device. For example, some computing devices may be incompatible with new software <NUM> due to outdated operating systems and/or hardware. In response to determining that an identified computing device is incompatible with new software <NUM>, migration module <NUM> may transmit an error message reporting the incompatibility issue to MSP <NUM>.

Software <NUM> and new software <NUM> may be similar computer programs that share a plurality of features. For example, software <NUM> may be an anti-virus program and new software <NUM> may be a different anti-virus program. Features such as periodic scanning, virus definitions, and removal/quarantine methods may be shared amongst many other features. MSP <NUM> or any of the computing devices may choose to replace software <NUM> with new software <NUM>. The present disclosure describes systems and methods for replacing software <NUM> with new software <NUM> while retaining as many desired settings <NUM> from software <NUM> as possible and ensuring that the quality of service (QoS) does not decrease during the replacement. This specific software replacement/updating is referred to as seamless migration.

Each of software <NUM> is configured with settings <NUM> that are identified for migration (i.e., applying to new software <NUM>). It should be noted that because software 110a is used differently than software 110b (e.g., because the respective computing devices may have different users or different types of devices), different settings are applied to new software <NUM> depending on which device new software <NUM> is applied.

Responsive to receiving the command, migration module <NUM> retrieves usage activity information of software <NUM> from computing device <NUM> and identifies settings <NUM> from software <NUM> to migrate. This is further discussed in <FIG> and <FIG>.

<FIG> is a block diagram illustrating system <NUM> for extracting and converting settings from an existing software to a new software. In the example in which software <NUM> and new software <NUM> are both anti-virus applications, the settings to migrate from the existing software to the new software may include, but are not limited to, (<NUM>) an anti-virus scanning schedule, (<NUM>) actions to perform for each type of virus and malware, (<NUM>) exception directories that do not need to be scanned, and (<NUM>) authorized users. As shown in <FIG>, settings <NUM> are extracted by the migration agents on each computing device and provided to migration module <NUM>. For simplicity, the following example focuses solely on settings 112a, which originates from computing device 108a. Settings 112a are identified by migration agent 114a as the settings that are to be imported (if possible). Settings 112a comprises a plurality of individual settings/configurations as listed in <FIG> (e.g., setting 112a-<NUM>, 112a-<NUM>, 112a-<NUM>, etc.).

Because not all settings of software <NUM> may be compatible with new software <NUM> and not all settings in software <NUM> are particularly desired by the user, migration module <NUM> filters out settings that should be imported. For example, migration module <NUM> may analyze the command/configuration logs of software 110a to identify at least one setting manually adjusted by a user of the existing software 110a of computing device 108a. If a user makes a manual selection of a setting, there is a greater likelihood that the user will want to see this setting in the new software <NUM>. For example, if the user switched the periodicity of anti-virus scans from daily to weekly, it is possible that the user does not want frequent scans. This provides migration module <NUM> with two pieces of information: what the user prefers and what the user does not prefer. In this case, when installing new software <NUM>, migration module <NUM> will not set the periodicity to "daily" for new software <NUM>. Likewise, because the user manually selected the weekly option, migration module <NUM> will set the scan periodicity to "weekly" based on the previous user selection.

In some examples, migration module <NUM> may identify at least one setting for migration in response to determining that the at least one setting of software <NUM> has been changed within a threshold period of time (e.g., within the last month). Another indication that a user prefers a particular setting is if the setting has been recently changed. This change does not necessarily have to be directly from the user. However, because the change was performed recently, it is likely that the change is a part of an update that improves performance.

In some examples, migration module <NUM> may identify at least one setting for migration in response to determining that the at least one setting has been unchanged by a user of the existing software for more than a threshold period of time (e.g., one year). For example, if a setting has been changed by a user and has then remained unchanged for a long period of time, there is a chance that the user has grown accustomed to it and prefers its outcome (e.g., changing when a scan can start to a preferred timing and keeping that change for a long period of time because it turns out to be convenient for the user).

Subsequent to identifying the settings to migrate from software 110a to new software <NUM>, migration module <NUM> may begin converting the identified settings to corresponding settings in new software <NUM>. Migration module <NUM> may rely on an internal data with metadata information about new software <NUM> and software 110a. <FIG> depicts, for example, migration database <NUM>. Migration database <NUM> comprises a list of settings and possible configurations for each software. Migration database <NUM> may include additional information, for each software, such as product ID, vendor name, product name, language type, product regex, vendor regex, etc. The entries comprising settings may be pre-mapped such that migration module <NUM> may quickly search for matching settings over two or more software applications.

For example, setting 112a-<NUM> of setting 112a may indicate a time period when anti-virus scans can take place. Migration module <NUM> may thus identify a similar time period setting in setting 204a-<NUM>. Accordingly, migration module <NUM> can match settings between software <NUM> and new software <NUM> for each computing device. Migration module <NUM> then generates settings <NUM>, which are comprised of a list of settings that matched with the settings of software <NUM> identified for migration. Migration module <NUM> transmits each setting <NUM> to migration agent <NUM> of the respective computing device.

<FIG> is a block diagram illustrating system <NUM> for generating a migration plan. Migration module <NUM> may receive usage activity information from each computing device. This information may include a log of actions taken on software <NUM>. The log may include, for example, "started manual scan of [DATE, TIME]," "abandoned scan at [DATE, TIME]," "automatically scanned new directory [NAME] at [DATE, TIME]," etc. Based on usage <NUM>, migration module <NUM> determines a migration plan indicative of a sequence of tasks for installing new software <NUM> and removing the existing software <NUM> such that a QoS associated with accessing the plurality of features on the at least one computing device does not decrease to less than a threshold QoS.

In some examples, to create the migration plan, migration module <NUM> may rank each respective feature in the plurality of features shared between the two software based on a likelihood of the respective feature being accessed during migration. Migration module <NUM> may then schedule tasks of the sequence of tasks in accordance with the ranking. In some examples, features with higher likelihoods are scheduled for installation before features with lower likelihoods. In other examples, features with lower likelihoods are scheduled for installation before features with higher likelihoods.

In some examples, migration module <NUM> may comprise QoS analyzer <NUM> and machine learning module <NUM>. QoS analyzer <NUM> may be used to assign QoS values to various times, as indicated in the usage activity information, that a particular feature has been accessed. QoS can be measured in different ways based on the time it takes to complete an action in the software. For example, if the software is an anti-virus software, QoS may be based on the time it takes to complete an anti-virus scan. A user may have begun an anti-virus scan at time t1 and the scan may have been completed in one hour. However, if the user did another scan of the same directories at t2 and the scan finished in five hours, the QoS of the latter scan is lower than the QoS of the former scan. The same applies if the software is, for example, a streaming application and a song download that normally takes <NUM> seconds instead takes <NUM> minute. For an anti-virus software, in some cases, QoS may be measured based on the number of malicious objects found, based on the amount of directories that are infected under the watch of an active firewall, based on the amount of time to download new virus definitions, etc. In general, for any type of software, QoS factors are dependent on the usage of the CPU, the network access speed, how prone the user is or makes himself/herself to malicious attacks (i.e., security/bugs), the software/hardware capabilities of a particular computing device, frequency of software crashes, frequency of hardware failures, etc..

In particular, migration module <NUM> attempts to avoid a degradation of QoS while the migration is occurring. Using ML module <NUM>, migration module <NUM> may identify a time to perform the migration. ML module <NUM> may receive the usage activity information of the user and the QoS values generated by QoS analyzer <NUM> to predict when the user activity will minimize such that a migration can be performed. For example, ML module <NUM> may determine that the user activity will reduce between <NUM>:00pm and <NUM>:00pm (e.g., CPU consumption on a computing device of the user will be less than <NUM>% when on average it is <NUM>%). It is possible that the user runs a scan of only a select number of directories during this time. If QoS is measured based on time to perform a scan, historically the completion time of the scan may be <NUM> hours. By installing new software <NUM>, the CPU usage may increase and slow down the scan to <NUM> hours. This represents a <NUM>% reduction in QoS (i.e., the new QoS value is <NUM>%). Migration module <NUM> may compare this value to a threshold QoS such as <NUM>%, and in response to determining that the QoS value will be greater than the threshold QoS, migration module <NUM> may schedule the migration during that time.

As shown in the above example, the threshold QoS represents a value, such as a percentage, that relates to the QoS value. If the QoS value is measured in scan time, the threshold QoS value will also be a time value representing a maximum scan time. If the QoS value is measured in the number of objects scanned within a time period, the threshold QoS represents a minimum number of objects to scan within that time period.

Migration module <NUM> thus generates a unique migration plan <NUM> for each computing device (depending on the settings to be imported and usage activity information). For example, migration module <NUM> may transmit migration plan 308a to migration agent 114a and migration plan 308b to migration agent 114b.

It should be noted that when selecting settings to import to new software <NUM>, migration module <NUM> may not select at least one setting for migration in response to determining that the at least one setting does not optimize the QoS when accessing at least one feature of the plurality of features on the new software (based on developer recommendations and/or MSP instructions). For example, certain settings in new software <NUM> may naturally yield better application performance (e.g., faster scan times and updates). Because of this, there is no need to import the old settings. These settings can be based on new features not found in the existing software. For example, a new anti-virus software may use a different approach to scanning the computing device that enables faster scans and requires more frequent scans. Thus, if the user originally set the scan frequency to bi-weekly in the existing software, and a vendor/developer recommends weekly scans using the new software, the frequency setting will not be carried over.

In some examples, migration module <NUM> may present migration plan <NUM> to an administrator of the at least one computing device and/or MSP <NUM>. Before executing the migration plan or before sending the migration plan to migration agent <NUM>, migration module <NUM> may request approval of migration plan <NUM>.

<FIG> is a block diagram illustrating system <NUM> for executing the migration plan. In some examples, in response to receiving an approval of the migration plan from the administrator, migration module <NUM> may execute the sequence of tasks indicated in migration plan <NUM> by installing new software <NUM>, implementing the corresponding settings <NUM>, and removing the existing software <NUM>. As shown in <FIG>, each computing device has a respective new software <NUM>, settings <NUM>, and no software <NUM>.

In some examples, migration agent <NUM> may receive migration plan <NUM> and execute it locally. The sequence of tasks may indicate when and in what order to perform the tasks of migration plan <NUM>. Each task may represent a particular command. An example sequence is as follows:.

In some examples, installation and removal may occur in parallel. For example migration agent <NUM> may identify a feature of the existing software, wherein the feature is in the plurality of features. Migration agent <NUM> may install files of the new software associated with the feature and apply a setting of the corresponding settings to the installed file, such that the feature is accessible on the new software. For example, the feature may involve scan for a particular virus. Because the new feature is realized on the computing device through new software <NUM>, if the user attempts to access the feature on software <NUM>, migration agent <NUM> may forward requests to access the feature received at the at least one computing device to new software <NUM>. Subsequent to installing the new feature and applying the corresponding setting, migration agent <NUM> may remove files of the existing software <NUM> associated with the feature.

In some examples, a MSP <NUM> may send a command to migrate new software <NUM> to the plurality of computing devices <NUM>. Suppose that the computing device is operating using Windows OS. If a computing device is not password protected, to uninstall software <NUM>, migration agent <NUM> may open Registry Editor, navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\, find an uninstallation key, and start uninstallation (e.g., msiexec /X {product uninstall key}).

In the case that the computing device is password protected, to uninstall software <NUM>, migration module <NUM> may rely on rest API to "Get" list of all computing devices <NUM>' hostname, create an unprotected group, put all computing devices <NUM> to the group, and launch uninstallation without password on each computing device. In this examples, the REST API methods include "Get," "Put," "Post," and "Delete.

Seamless migration is applicable in any update setting because it enables users to continue to use applications and services during an update without terminating said applications and services. For example, a user may begin to use a feature of an existing software such as an anti-virus scan and complete using the feature in the new software. Suppose that a directory with a thousand files is to be scanned. Using the systems and methods of the present disclosure, the directory may be scanned using an existing anti-virus software. Midway through the scan, a new anti-virus software may be installed. The feature of scanning files for viruses may then be taken over by the new software midway and completed by the new software. Once the new software is fully installed, the existing software may be removed. Migration module <NUM> may determine that the feature of scanning files (i.e., the feature being currently used) requires a certain set of installation files to be executed (e.g., a communication module that communicates with a remote virus definition database, a user interface, a file parser, etc.) and installs those files immediately. Migration agent 114a may subsequently redirect all requests associated with that feature (i.e., a request to scan an object in the directory) to the new software.

In order to ensure that this installation and execution is "seamless," migration module <NUM> identifies at least one QoS factor to compare performance against. For example, the QoS factor may be a network bandwidth consumption of a computing device specifically allocated to migration. Suppose that the threshold QoS for network bandwidth consumption is <NUM> Mbps. Migration module <NUM> will attempt to install the new software while ensuring that the network bandwidth consumption does not exceed <NUM> Mbps. If the existing software is also running and is consuming bandwidth, the consumption by the existing software is also included in the QoS determination. For example, the existing software may be using <NUM> Mbps to upload file signatures for comparison against virus definitions. Thus, there remains <NUM> Mbps to download the new software installation files.

Furthermore, another QoS factor may be CPU consumption (either allocated specifically to migration services or for the computing device as a whole). For example, while the scanning feature is being used in the existing software and the new software is being downloaded and installed, CPU consumption may be <NUM>%. If the threshold CPU consumption is <NUM>%, migration module <NUM> may slow down installation or scanning to maintain CPU consumption under the threshold.

Another QoS factor may be storage usage. For example, the threshold storage usage for a computing device may be <NUM>% of total space. If installing the new software will cause the storage usage to be <NUM>% (i.e., will exceed the threshold), migration module <NUM> may identify features of the existing software that are shared with the new software. Subsequently, migration module <NUM> may piecewise install those features in the new software and, in parallel, remove the same features from the existing software to maintain the storage usage. In some examples, migration module <NUM> may consider multiple QoS factors at once to ensure that the migration occurs with no interruptions and stable usage.

<FIG> illustrates a flow diagram of method <NUM> for seamlessly migrating from an existing software to a new software. At <NUM>, migration module <NUM> receives a command (e.g., via migration agent 114a installed on computing device 108a) to migrate from an existing software (e.g., software 110a) to the new software (e.g., new software <NUM>) on at least one computing device (e.g., computing device 108a), wherein the existing software and the new software share a plurality of features (e.g., both software are anti-virus programs).

At <NUM>, migration module <NUM> retrieves usage activity information (e.g., usage 302a) of the existing software from the at least on computing device. At <NUM>, migration module <NUM> identifies settings (e.g., settings 112a) from the existing software to migrate. At <NUM>, migration module <NUM> converts, based on an internal database with metadata information about the new software (e.g., migration database <NUM>), the settings to corresponding settings in the new software (e.g., settings 204a).

At <NUM>, migration module <NUM> determines, based the usage activity information, a migration plan (e.g., migration plan 308a) indicative of a sequence of tasks for installing the new software and removing the existing software such that a quality of service associated with accessing the plurality of features on the at least one computing device does not decrease to less than a threshold quality of service. At <NUM>, migration module <NUM> executes the sequence of tasks by installing the new software, implementing the corresponding settings, and removing the existing software.

<FIG> is a block diagram illustrating a computer system <NUM> on which example embodiments of systems and methods for seamlessly migrating from an existing software to a new software may be implemented. The computer system <NUM> can be in the form of multiple computing devices, or in the form of a single computing device, for example, a desktop computer, a notebook computer, a laptop computer, a mobile computing device, a smart phone, a tablet computer, a server, a mainframe, an embedded device, and other forms of computing devices.

As shown, the computer system <NUM> includes a central processing unit (CPU) <NUM>, a system memory <NUM>, and a system bus <NUM> connecting the various system components, including the memory associated with the central processing unit <NUM>. The system bus <NUM> may comprise a bus memory or bus memory controller, a peripheral bus, and a local bus that is able to interact with any other bus architecture. Examples of the buses may include PCI, ISA, PCI-Express, HyperTransport™, InfiniBand™, Serial ATA, I<NUM>C, and other suitable interconnects. The central processing unit <NUM> (also referred to as a processor) can include a single or multiple sets of processors having single or multiple cores. The processor <NUM> may execute one or more computer-executable code implementing the techniques of the present disclosure. For example, any of commands/steps discussed in <FIG> may be performed by processor <NUM>. The system memory <NUM> may be any memory for storing data used herein and/or computer programs that are executable by the processor <NUM>. The system memory <NUM> may include volatile memory such as a random access memory (RAM) <NUM> and non-volatile memory such as a read only memory (ROM) <NUM>, flash memory, etc., or any combination thereof. The basic input/output system (BIOS) <NUM> may store the basic procedures for transfer of information between elements of the computer system <NUM>, such as those at the time of loading the operating system with the use of the ROM <NUM>.

Embodiments of the present disclosure may be a system, a method, and/or a computer program product. The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out embodiments of the present disclosure.

Computer readable program instructions for carrying out operations of the present disclosure may be assembly instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language, and conventional procedural programming languages. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a LAN or WAN, or the connection may be made to an external computer (for example, through the Internet). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform embodiments of the present disclosure.

In various examples, the systems and methods described in the present disclosure can be addressed in terms of modules. The term "module" as used herein refers to a real-world device, component, or arrangement of components implemented using hardware, such as by an application specific integrated circuit (ASIC) or FPGA, for example, or as a combination of hardware and software, such as by a microprocessor system and a set of instructions to implement the module's functionality, which (while being executed) transform the microprocessor system into a special-purpose device. A module may also be implemented as a combination of the two, with certain functions facilitated by hardware alone, and other functions facilitated by a combination of hardware and software. In certain implementations, at least a portion, and in some cases, all, of a module may be executed on the processor of a computer system. Accordingly, each module may be realized in a variety of suitable configurations, and should not be limited to any particular implementation exemplified herein.

Claim 1:
A method (<NUM>) for seamlessly migrating from an existing software (110a) to a new software (<NUM>), the method comprising:
receiving (<NUM>) a command to migrate from the existing software (110a) to the new software (<NUM>) on at least one computing device (108a), wherein the existing software (110a) and the new software (<NUM>) are different application that share a plurality of features, and wherein the existing software (110a) is developed by a first software vendor and the new software (<NUM>) is developed by a second software vendor;
responsive to receiving the command:
retrieving (<NUM>) usage activity information (302a) of the existing software (110a) from the at least one computing device (108a), wherein the usage activity information (302a) comprises times needed for completing actions in the existing software (110a);
identifying (<NUM>) settings (112a) from the existing software (110a) to migrate;
converting (<NUM>), based on an internal database with metadata information about the new software (<NUM>), the settings (112a) in the existing software(110a) to corresponding settings (204a) in the new software (<NUM>);
determining (<NUM>), based on the usage activity information (302a), a migration plan (308a) indicative of a sequence of tasks for installing the new software (<NUM>) and removing the existing software (110a) such that a quality of service associated with accessing the plurality of features on the at least one computing device (108a) does not decrease to less than a threshold quality of service, wherein the quality of service is measured based on a time needed to complete an action using the existing software (110a) and the new software (<NUM>) during execution of the migration plan (308a); and
executing (<NUM>) the sequence of tasks, wherein executing the sequence of tasks comprises:
identifying a feature of the existing software (110a), wherein the feature is in the plurality of features;
installing files of the new software (<NUM>) associated with the feature;
applying a setting of the corresponding settings to the installed files, such that the feature is accessible on the new software (<NUM>);
forwarding requests to access the feature received at the at least one computing device (108a) to the new software (<NUM>); and
removing files of the existing software (110a) associated with the feature.