Upgrading customizations
When you installed BMC Cloud Lifecycle Management, you might have customized one or several components in the solution to suit your business needs (for example, the Network Automation API). This section covers information about how to upgrade those customizations to version 4.x when you perform the upgrade.
Upgrade strategies for customizations
Evaluate the customizations in your environment. You have the following options:
- Replace your customizations
- Partially port your customizations
- Completely port your customizations
- No port is possible
- No port or replacement is necessary
- BMC strongly recommends that you try to use out-of-the-box functionality instead of creating customized functionality.
- Identify all your customizations before you start the upgrade, and then prepare your data accordingly.
- Thoroughly test the ported customization before you go live. Verify your customizations when you perform the upgrade.
| Customization category | How do you handle it? | Examples |
|---|---|---|
| Replacement | Replace your customizations with out-of-the-box BMC Cloud Lifecycle Management functionality. You should replace customizations that are no longer needed (for example, add secondary disk customization) with existing features. |
|
| Partial port | Partially port your customizations. These include customizations for which partial functionality exists out-of-the-box, or which BMC Cloud Lifecycle Management makes it easier to develop some part of the customization, for example, passing custom parameters for software installation. If you must port your customizations, keep your port minimal.. |
|
| Complete port | Identify the changes that are required to port to customization. Then completely port your customizations. These include customizations which are not available out-of-the-box at all and you must carry them forward, for example, creating snapshots. |
|
| No porting is possible | In some cases, no porting is possible. For custom server operator actions, a generic UI is provided out-of-the-box. As a result, no custom UI is possible in the 4.5.00 or later release, and no migration mechanism is provided for custom operator actions. | Custom operator actions |
| Porting or replacement not necessary | In some case, porting or replacement of functionality during the upgrade is simply not necessary. The customization works as expected after you finished the upgrade. A good example here are optional custom actions. When you create optional custom actions (for example, custom TRO) as part of the service blueprint, these are defined inside the service offering itself and will work as expected in both the old EUP and the new 4.5.00 or later EUP. | Optional custom actions |
Comments
Log in or register to comment.