Your monitoring tools need to work properly, and to accomplish that, they must be upgraded periodically.
With your mountain of issues, horse-choking responsibilities, and meetings out the wazoo, it’s easy to miss upgrade deadlines. But, you still need to know that the right information about the status of your environment is reaching the right person at the right time, every time. Those upgrades keep your service performance consistent and operating smoothly.
If you’re using BMC’s ProactiveNet Performance Management (BPPM) software, you know that regular upgrades are necessary to keep this flagship product working effectively. Each version since 7.7 in 2005 has needed a significant upgrade to reach the latest generally available (GA) version which is currently 9.0.
One thing you may not know is that any version before 8.5 can’t be upgraded directly to 9.0. An enterprise using an earlier version must first upgrade to the 8.5 version, and only from that point can it be upgraded to 9.0. Also, the support BMC provides for BPPM is rapidly limited, then expired; staying up to date is the only way to have access to support.
At this writing, version 8.5 will be unsupported after October 31, 2013. Those organizations still using version 8.5 need to arrange for upgrades before that time.
Moreover, version 8.6 can be upgraded to 9.0, but 8.6 will be changed to limited support this summer on July 31, 2013 … and will be completely unsupported after July 31, 2014.
So what are the options for an enterprise using a version nearing the end of its support?
Basically, there are two.
The first, and less expensive, is to initiate an “over the top” upgrade to 8.5, then another to 9.0. The down side of this approach is the monitoring time lost during the upgrade. Since monitoring is usually needed 24/7, it can be detrimental to go offline for the time needed to do the upgrade.
Each upgrade will result in lapsed monitoring time, for a number of hours.
Because of unknown factors such as the size of the database, the number of devices, rules and reports, as well as the number of thresholds that will be used, it’s difficult to predict the length of time monitoring will be disabled during an upgrade.
There are more issues, too. For instance, upgrading a BPPM Agent/ Integration Service (IS) before the server is upgraded makes the connection between the two obsolete. BPPM components aren’t backward compatible. By the same token, once the server is upgraded, BPPM Agents also have to be upgraded before the system will work. In a large environment, bringing all these components up to speed is even more difficult as well as time consuming.
Then add this to the mix: the extent of customizations can have a huge impact on the upgrading process. Some of the customized files will likely be lost and have to be restored. Best practices may require updates to other related native files, too. Customizations to the knowledge base must be accompanied by careful review and documentation prior to an upgrade.
All of these issues are about updates of BPPM alone. However, in most environments, BPPM is integrated with multiple other applications, such as Patrol, Transaction Management Application Response Time (TM ART), Configuration Management Database (CMDB), Blade, and Remedy. All of the tools in the given environment must operate smoothly together. There are strict version dependencies between each of these products that must align. In some cases, customers may be prevented from upgrading BPPM until CMDB and ITSM have been upgraded to a supported version.
So … the big question: What is the alternative? If upgrading leads to all these complications, how is the enterprise to avoid them?
The answer? A calculated migration.
A migration includes new hardware, installing the latest BPPM version, testing, then integrating, then slowly migrating system functionality to the new system.
1.) A significant benefit in this approach is the new hardware. The use of new hardware and possibly a new operating system or enhanced gold images create a far better platform for BPPM in the longterm.
There have been a number of enhancements added to BPPM between 8.5 and 8.6, not the least of which was the support for an external Oracle database. Changing from the native Sybase database is not possible during an upgrade, and once the upgrade is complete it isn’t an option to upgrade to Oracle later.
The only way to move to Oracle, if that’s a good decision for your organization, is to perform a complete install on BPPM.
2.) The other benefit of a migration over an upgrade is the monitoring outage discussed before. Monitoring outage with an upgrade can be several hours or more, but with the migration, the outage is usually not more than a few minutes.
During those few minutes it is true that it’s necessary to manage both systems at once, but that’s usually over a short time and your new system is up and running smoothly.
So here’s a list of the pros and cons of each approach:
You can see that the list of pros in the migration strategy outweighs the list in the upgrade approach. However, no two environments are identical so decisions need to be made based on the best approach for you, in your environment.