The BMC Topology Discovery and Foundation Discovery products (later renamed to BMC Atrium Discovery and Dependency Mapping, or BMC Atrium Discovery) were recently replaced by the Tideway Foundation product that BMC acquired in October 2009. Immediately upon acquisition, BMC started shipping the Tideway product as BMC Atrium Discovery version 8.0. Going forward, BMC recommends that all existing users migrate to version 9.0 from their installations of earlier versions of the product.
For users of Tideway Foundation
If you are using a version of Tideway Foundation prior to version 8.0, you do not need to migrate your installation. You simply need to upgrade to the latest version of BMC Atrium Discovery. See Upgrading to version 9.0 for more information. Migration is only required from the BMC Discovery products released before the BMC Software acquisition of Tideway.
Clearly, versions 8 and later contain a different product architecture from versions 7.5 (and its predecessors). Data discovered by these products and synchronized to BMC Atrium CMDB is going to be very different as a result. Two illustrative examples include:
Based on these examples, reconciling these CIs in the CMDB with each other is essentially impossible: they have different structures, different sources, and often different contents. When migrating to version 9.0, a migration approach is needed to ensure that items are not duplicated in BMC Atrium CMDB and that any tools relying on the data in the CMDB can continue to function correctly.
For more detail on the differences between the two versions, and how the characteristics of each discovery methodology might impact your migration strategy, see Fundamental differences in discovering configuration data.
Your discovery configuration for BMC Atrium version 7.5 likely contains valuable information that you want to carry over to your version 9.0 implementation. The configured credentials, discovery jobs, and UAD signatures took time to build and should be taken advantage of in the new version. The following pages describe how to migrate these items to the latest version of BMC Atrium Discovery:
The supported migration path for BMC Atrium Discovery is from version 7.5.01.03 to version 9.0. If you plan to migrate data from earlier versions of BMC Atrium Discovery (or BMC Topology Discovery and BMC Foundation Discovery), you must first upgrade to version 7.5.01.03. For users migrating their mainframe data using BMC Discovery for z/OS version 1.5, you must first upgrade to version 1.6.
While many of the CMDB classes populated by these two product versions are not reconcilable, the
BMC_IPEndPoint classes will, in almost all cases, reconcile correctly. This enables a migration approach for BMC Atrium CMDB that retains all the history of computer system CIs, although any essential data attached to CIs that make up a computer systems will need to be handled specially.
The broad approach is that all CIs in BMC Atrium CMDB that will not be reconciled correctly (that is, the items that make up a computer system: software servers, CPU CIs, and so forth) and that are not involved in IT Service Management (ITSM) items such as incidents and changes, will be deleted. BMC Atrium CMDB will be repopulated by the BMC Atrium Discovery 9.0 migration utility, and these new items will continue to be used by BMC Atrium CMDB consumers to handle ITSM applications. See Migrating data to populate the CMDB for ITSM for more information.
BMC Atrium Discovery 9.0 exports impact relationships between all Service Impact Manager (SIM)-enabled classes in the same way that version 7.5 does. Any impact relationships that you manually create between CIs populated by version 7.5 must be rebuilt between the corresponding version 9.0 CIs. See Migrating impact models for more information.
Similar to the ITSM use case, all CIs in BMC Atrium CMDB that are not involved in creating service models will be deleted. BMC Atrium CMDB will be repopulated by the BMC Atrium Discovery 9.0 migration utility, and these new items will continue to be used by BMC Atrium CMDB consumers to build service models.
It is important to understand that users are going to see significant changes to the data that they work with. Some data will appear differently, and some items will show up in different CMDB classes.
BMC recommends that you first migrate your development CMDB environment, both to validate the migration approach in your organization, and to familiarize yourself with the changes that happen to the data in your CMDB. It is important that you educate your users about the changes that they should expect in order to keep them productive immediately after the migration. The migration solutions detailed in the following sections follow this methodology: check the impact on your environment, test, migrate the data, and then validate.
After you have determined that you are ready to migrate the data, perform the migration promptly to avoid possible implications of introducing additional data into the CMDB. This will change your original test results, and the resultant inconsistency in the data might cause confusion.