Oracle BRM Upgrade

In the most competitive world and business today, a highly challenging task is to keep their company on par with the latest technology and feature changes happening in the industry. This challenging task spreads across to each & every vertical of the business, and especially to the IT Teams. It becomes the highest priority for them to keep their IT systems and products used as up to date.

Oracle rolls out a new version of Billing and Revenue Management (BRM) product on a periodic basis to modernize current overall architecture, to improve the stability of the product, to enhance the product features to create new revenue monetization streams, and to stay compliant with Oracle licenses in the years to come. Apart from the various versioned releases of the BRM product, Oracle does release patches on periodic intervals to overcome, fix the technical, functional, performance issues on the product versions.

This blog is a quick one-stop document to brief the key highlights & basic process of performing a BRM Upgrade in a live system with near-zero downtime. The basic process briefs a bare minimum activity to be followed for any BRM upgrade projects. Explains:

●        What does an Upgrade mean?

●        Why do we need to Upgrade a system?

●        How do we upgrade our system with near-zero downtime?

The BRM system upgrade is done not only to keep up the license terms and the product support from Oracle, rather it is updated to the latest versions, for the new features that support the business stakeholders. These new features and the technological updates introduced in the product helps the business teams to keep up with the widely used BRM system features. By upgrading the BRM system, the business teams can serve their customers better.

Any billing system upgrade is challenging and the BRM system upgrade is not an exception. Primarily, due to the features available in the product and also the provision available to customize the product. Based on distinct unique requirements in the businesses and in the industries, the business teams, customize the BRM product based on their requirements, which increases the complexity in upgrading the BRM system. The more the product is been customized, the more the complexity involved in upgrading it.

Though the BRM upgrade activities might vary from customer to customer and system to system, the most important task even before starting the BRM upgrade project is to choose the exact target version and the patch of the BRM system. The target BRM version and patches could vary based on the exact requirement of the business and the roadmap of the business. Below is the pictorial representation of the list of basic activities involved in the BRM upgrade project. 

●        Oracle SR & Patch Analysis:  – Oracle Support Requests (SR) raised for the current BRM system needs to be analyzed while performing the system upgrade. This becomes the most important activity in the upgrade, as some of the SR solutions would have been covered in the version release or in the specific patch of the BRM release.

●        Feature Analysis & Comparison: We need to perform the features mapping of the existing BRM system, and the target version and the patch set picked for the upgrade. The features of the existing BRM system might have been carry forwarded in the latest versions & patches too. Similarly, the customizations done in the existing BRM system may be available as a standard feature in the latest versions & patches. In case of any feature deviations from Oracle, we shall raise the Support Request to get a proper resolution. In case if the customizations are not covered in any of the released versions or patches, the same customizations have to be carry forwarded for the business continuity plans.

●        Code Merge: The baseline code of the latest target version needs to be taken from any fresh installation of the target version/patch. Merge the customized policy opcodes & custom facility module codes to the baseline code to create the target deployment package.

●        Proof of Concept: Once the deployment package is ready, deploy that in the latest version/patch of the BRM system and try to bring up the system. If the system is up and running then, we shall confirm our deployment package. Otherwise, we need to fix the deployment package until the system becomes stable and running.

●        Scripting: Build the script to automate the deployment into the pre-production and production environments. This will leverage avoiding the actual execution of the upgrade scripts and resolving the issues in every environment.

●        Testing: Once the BRM system is ready with the latest build plan for the functional, performance, regression, and End-to-End testing activities. Fix any issues faced in these testing activities planned. The fixes could be a direct code fix from our teams, or it could be from the actual product team of Oracle, depending on the criticality of the issue.

●        Production Go-Live: After all the successful testing activities, the actual Production Go-Live can be planned. While planning for the actual Go-Live, to achieve near-zero downtime, we shall prepare a parallel DB server with the production data.

Once the DB server is ready, we shall leverage the benefits of Oracle Golden Gate (GG) to sync the data between the existing DB server and the new DB server. Once the GG lag is zero, then we shall break the replication for a time being. We shall do a complete upgrade in the new DB server, and after the upgrade, the GG replication can be initiated again in GG (upgrade mode) to sync the data from the old version of BRM DB to the new version of BRM DB

Later that, on the exact Go-Live date, the live traffic can be routed from the old server to the new server. To sync the data from the new DB server to the old DB server, we shall use the capabilities of the Oracle GG again in a downgraded mode to sync the data. Based on the overall performance and the stability, the BRM DB server in a lower version can be rebuilt with the latest version.