Migration versus upgrade - pros, cons, and risks

The first major decision you have to make it whether you want to upgrade the existing BMC ProactiveNet Server(s) or whether you want to migrate the monitored environment to BMC ProactiveNet 9.6 instead.

An upgrade involves the following:

Running the BMC ProactiveNet 9.6 installer on existing BMC ProactiveNet Servers
Installing and configuring new BMC ProactiveNet Integration Service 9.6 nodes
Pointing the BMC PATROL Agents to the new BMC ProactiveNet 9.6 environment when the agents are upgraded.

A migration involves the following:

Installing and configuring new 9.6 BMC ProactiveNet Servers and Integration Service nodes
Configuring the PATROL Agents to connect to the new BMC ProactiveNet 9.6 environment when you upgrade the agents.

Pros and cons of migration

The following are pros and cons of the migration method.

Pros	Cons
Potentially incorrect or otherwise undesired configuration is not carried forward in the new BMC ProactiveNet 9.6 system from the old system. There are no historical or on-going issues with data gaps in the new BMC ProactiveNet 9.6 system. A migration eliminates any user confusion related to functionality and data differences between data collected from older agents versus the new 9.5 PATROL Agents all being displayed in the same UI. It is simpler to keep like functionality segregated between systems; that is, BMC ProactiveNet Server 9.6 with Integration Services 9.6 and PATROL Agents 9.5, while keeping the earlier servers with earlier Integration Services and earlier PATROL Agents. Provides a platform for a complete and clean rework of monitoring configuration without the worry of older data collection configuration challenges having to be handled going forward. You can avoid “intermediate” upgrades. If the existing BMC ProactiveNet Server(s) are of a version that is not supported for a direct upgrade to version 9.6, you have to upgrade them first to an upgradable version. This mainly applies to version 8.5; however, you also need to consider service packs for versions 8.6, 9.0, and 9.5. There is little or no downtime associated with a migration.	You have to run parallel environments for a period of time until the migration is complete. Historical data is not maintained in the new system. However, it is available in the old system until the old system is decommissioned. There is work involved in defining configuration settings including user preferences, graph views, and so on in the new BMC ProactiveNet Server(s). An upgrade will preserve those settings. The migration method involves installing new BMC ProactiveNet Server(s), not upgrading the old BMC ProactiveNet Server(s). The ability to use earlier Integration Service nodes (versions 9.0 and 8.6 with the appropriate levels of service packs) is not supported out-of-the-box with a fresh, new installation of the BMC ProactiveNet Server. The earlier Integration Services are supported out-of-the-box only when the BMC ProactiveNet Server is upgraded. (With custom configuration after installation, older Integration Services can be supported in a BMC ProactiveNet 9.6 environment. However, BMC does not recommend this in a migration unless you are forced to use older PATROL Agents that require older Integration Services for an extended period of time.) You must have the additional hardware and resources required for BMC ProactiveNet 9.6 to support a migration.

Pros

Cons

Potentially incorrect or otherwise undesired configuration is not carried forward in the new BMC ProactiveNet 9.6 system from the old system.
There are no historical or on-going issues with data gaps in the new BMC ProactiveNet 9.6 system.
A migration eliminates any user confusion related to functionality and data differences between data collected from older agents versus the new 9.5 PATROL Agents all being displayed in the same UI. It is simpler to keep like functionality segregated between systems; that is, BMC ProactiveNet Server 9.6 with Integration Services 9.6 and PATROL Agents 9.5, while keeping the earlier servers with earlier Integration Services and earlier PATROL Agents.
Provides a platform for a complete and clean rework of monitoring configuration without the worry of older data collection configuration challenges having to be handled going forward.
You can avoid “intermediate” upgrades. If the existing BMC ProactiveNet Server(s) are of a version that is not supported for a direct upgrade to version 9.6, you have to upgrade them first to an upgradable version. This mainly applies to version 8.5; however, you also need to consider service packs for versions 8.6, 9.0, and 9.5.
There is little or no downtime associated with a migration.

You have to run parallel environments for a period of time until the migration is complete.
Historical data is not maintained in the new system. However, it is available in the old system until the old system is decommissioned.
There is work involved in defining configuration settings including user preferences, graph views, and so on in the new BMC ProactiveNet Server(s). An upgrade will preserve those settings.
The migration method involves installing new BMC ProactiveNet Server(s), not upgrading the old BMC ProactiveNet Server(s). The ability to use earlier Integration Service nodes (versions 9.0 and 8.6 with the appropriate levels of service packs) is not supported out-of-the-box with a fresh, new installation of the BMC ProactiveNet Server. The earlier Integration Services are supported out-of-the-box only when the BMC ProactiveNet Server is upgraded. (With custom configuration after installation, older Integration Services can be supported in a BMC ProactiveNet 9.6 environment. However, BMC does not recommend this in a migration unless you are forced to use older PATROL Agents that require older Integration Services for an extended period of time.)
You must have the additional hardware and resources required for BMC ProactiveNet 9.6 to support a migration.

Migration risks

The following are risks identified with migrating instead of upgrading:

The requirement to run parallel systems may result in confusion due to users having to view trends in multiple systems.
A migration may extend the time required to get to BMC ProactiveNet version 9.6. A complete migration requires complete configuration of the 9.6 environment including policies in BMC ProactiveNet Central Monitoring Administration, and upgrading PATROL Agents before they can be integrated in the new environment. This can extend the time required to complete the project so that all agents report into the new 9.6 environment.

Note

This risk exists for all scenarios when you consider “full BMC ProactiveNet 9.6 functionality”. However, with an upgrade, existing older PATROL Agents report into BMC ProactiveNet 9.6 immediately after the upgrade, even though “full BMC ProactiveNet 9.6 functionality” is not in place for them.

Pros and cons of upgrade

The following are pros and cons of the upgrade method.

Pros	Cons
You do not have to run parallel environments as you do with a migration. Assuming proper sizing, the server(s) already provisioned for the older environment can be leveraged for 9.6. You do not have to reconfigure all the settings. NOTE: You must review all the settings. Some settings such as heap will have to be reset. Policies need to be re-created, edited, or created for the first time. After the BMC ProactiveNet Servers are upgraded, the older Integration Service nodes, adapters, and older PATROL Agents continue to function as they did in the older BMC ProactiveNet Server. Historical data is maintained in the new system because the old system becomes the new system. You can initially upgrade only the server and install new Integration Service nodes, followed by upgrading the agents over time. The BMC ProactiveNet Server 9.6 interoperates with the older Integration Services and older data flow model. You can move PATROL Agents in logical groups to a new 9.6 Integration Service node as they are upgraded to PATROL Agents version 9.5 while handling data for all versions in the new BMC ProactiveNet Servers. Additional hardware and resources are generally not required to support an upgrade. However, you must review BMC ProactiveNet scalability as you plan the upgrade, and allocate enough drive space for the upgrade to run.	Incorrect or otherwise undesired configuration will be carried forward to the new 9.6 system from the old system. You may potentially experience on-going issues with data gaps in the new 9.6 system until all the PATROL Agents are upgraded and communicate through the 9.6 Integration Services. If you are starting with BMC ProactiveNet 8.5, you must first upgrade to either BMC ProactiveNet 9.0 SP1 or at least to BMC ProactiveNet 8.6 SP3 prior to upgrading to 9.6. Ensure that the latest Service Pack has been applied to the current BMC ProactiveNet Server(s) prior to the upgrade. Users may experience differences in functionality and content in the same UI because variations may exist depending on the agent versions from which the data is sourced. The following are some examples (not a complete list): Annotated data will be available only for attributes collected by the 9.5 agents. Annotated data for the same attributes will not be available where collected by older agents. There will be differences in the granularity of trended data for attributes. Data from older agents will be less granular, generally one data point every five minutes. Data from the 9.5 agents can be granular to one minute. Some attributes continuing to be collected by older agents may have data gaps while the same attributes collected by the 9.5 agents may not have data gaps. Certain new functionality in BMC ProactiveNet 9.6, such as the ability to refresh parameters from the BMC ProactiveNet Operations Console, will not be available for data collected by older agents. Data differences is be retained for historical data after the agents are upgraded. These differences exist in the same Operations Console and it will not be readily apparent to users why the differences occur. This may result in confusion and excessive support calls unless the users are well trained to be aware of the differences.

Pros

Cons

You do not have to run parallel environments as you do with a migration. Assuming proper sizing, the server(s) already provisioned for the older environment can be leveraged for 9.6.
You do not have to reconfigure all the settings.
NOTE: You must review all the settings. Some settings such as heap will have to be reset. Policies need to be re-created, edited, or created for the first time.
After the BMC ProactiveNet Servers are upgraded, the older Integration Service nodes, adapters, and older PATROL Agents continue to function as they did in the older BMC ProactiveNet Server.
Historical data is maintained in the new system because the old system becomes the new system.
You can initially upgrade only the server and install new Integration Service nodes, followed by upgrading the agents over time. The BMC ProactiveNet Server 9.6 interoperates with the older Integration Services and older data flow model.
You can move PATROL Agents in logical groups to a new 9.6 Integration Service node as they are upgraded to PATROL Agents version 9.5 while handling data for all versions in the new BMC ProactiveNet Servers.
Additional hardware and resources are generally not required to support an upgrade. However, you must review BMC ProactiveNet scalability as you plan the upgrade, and allocate enough drive space for the upgrade to run.

Incorrect or otherwise undesired configuration will be carried forward to the new 9.6 system from the old system.
You may potentially experience on-going issues with data gaps in the new 9.6 system until all the PATROL Agents are upgraded and communicate through the 9.6 Integration Services.
If you are starting with BMC ProactiveNet 8.5, you must first upgrade to either BMC ProactiveNet 9.0 SP1 or at least to BMC ProactiveNet 8.6 SP3 prior to upgrading to 9.6.
Ensure that the latest Service Pack has been applied to the current BMC ProactiveNet Server(s) prior to the upgrade.
Users may experience differences in functionality and content in the same UI because variations may exist depending on the agent versions from which the data is sourced. The following are some examples (not a complete list):
- Annotated data will be available only for attributes collected by the 9.5 agents. Annotated data for the same attributes will not be available where collected by older agents.
- There will be differences in the granularity of trended data for attributes. Data from older agents will be less granular, generally one data point every five minutes. Data from the 9.5 agents can be granular to one minute.
- Some attributes continuing to be collected by older agents may have data gaps while the same attributes collected by the 9.5 agents may not have data gaps.
- Certain new functionality in BMC ProactiveNet 9.6, such as the ability to refresh parameters from the BMC ProactiveNet Operations Console, will not be available for data collected by older agents.

Data differences is be retained for historical data after the agents are upgraded. These differences exist in the same Operations Console and it will not be readily apparent to users why the differences occur. This may result in confusion and excessive support calls unless the users are well trained to be aware of the differences.

Upgrade risks

The following are risks related to upgrades from all versions except where otherwise specified:

Poor perception of the new solution. The significant change between older versions and BMC ProactiveNet 9.6 results in a variation of the functionality, capability, and behavior which is likely to cause confusion for users. Users may also perceive issues in BMC ProactiveNet 9.6 that are actually related to data collected before the upgrade and/or before upgrading agents.
Improper decisions. Visualization may be confusing to users considering old versions of KMs compared to 9.6 KM versions being displayed, as upgraded and new BMC ProactiveNet 9.6 policy-controlled agents join the BMC ProactiveNet 9.6. This may result in improper decisions.
There may be altered event behavior associated with event management cell Knowledge Base configuration differences that were not accounted for.
Down time associated with upgrading the BMC ProactiveNet Server(s), especially if upgrading from version 8.5, due to multiple iterations in the upgrade process.

Note

In all scenarios, BMC recommends that you install new 9.6 Integration Services. This means you have to allocate hardware resources for the new Integration Services. Whether you upgrade or migrate makes no difference.

Migration versus upgrade decision chart

The following chart is intended to help provide a general framework around deciding whether to migrate or upgrade. Not all factors that drive this decision can be anticipated; therefore, a particular environment and its specific requirements may necessitate some deviation in the decision process. Answer each question below with either Yes or No. Do not answer with both Yes and No. In general, the Upgrade or Migrate column with the most Yes answers is the best choice, assuming there are no “show stopper” items that are not answered in the respective column.

Requirement	Upgrade	Migrate
Are hardware resources available for a separate, new BMC ProactiveNet Server?	No	Yes
Do you have to maintain the old and new data in one system and one UI?	Yes	No
Are you changing the database platform (Sybase to Oracle or Oracle to Sybase)?	No	Yes
Is it acceptable to carry old data and configuration forward in the new system?	Yes	No
Will users be able to manage differences in functionality in a single UI depending on the source agent versions?	No	Yes
If an upgrade requires multiple iterations, is the environment allowed the related down time?	Yes	No
Will users be able to handle workflow and visualization in multiple separate parallel systems until the project is complete?	No	Yes
Is it a requirement to maintain current monitoring configuration including graphs, views, and so on without having to re-enter anything?	Yes	No
Is zero down time a major issue?	No	Yes
Are service models implemented in the current system and integrated with BMC IT Service Management and monitoring such that leveraging a separate system for Probable Cause Analysis is technically unacceptable?	Yes	No
Is it acceptable to manage separate parallel environments?	No	Yes
Is it a requirement to maintain historical data in the same system with new data?	Yes	No
Does the monitoring data collection and configuration need a complete rework in order to be valuable? (In other words, does the current environment provide little value?)	No	Yes
Is project timing a major issue making it difficult or impossible to complete a migration, keeping in mind that a lot of reconfiguration may be required?	Yes	No