Our Customer

An Australian subsidiary of a multi-national member of the automotive industry. They are a leading and innovative organisation that strives to deliver the best customer experience in Australia. With a strong history in Australia, they operate multiple systems locally from a wide-range of functions that underpin their excellent customer service.

The Challenge

The client approached us with a problem. They had not upgraded their Oracle software for many years, and they have not had Oracle support for the past several years. They realised that they were increasingly being exposed to securityvulnerabilities of the Oracle software as some systems using the Oracle were accessed via VPN external to the organisation.

The client was facing a dilemma: They had no appetite to pay Oracle millions of dollars to reinstate support, even though that would be cheaper than the cost of a breach. In addition there was a separate strategy that stated the platform of the future had Microsoft SQL Server as its database. It was not possible with reasonable cost that the client could take 50+ applications across 20+ Oracle databases and WebLogic to the equivalent SQL Server.

The client has interacted with us for several years in a light capacity and asked us how we would approach this problem.

Transition Strategy

We had several conversations with the client about the current state and what they believed was possible. We discussed our experiences and how the outcomes required could be achieved and this led to a commercial engagement whose primary outcome was to arrive at a database transition strategy to the target state.

We undertook an engagement that was multi-faceted encompassing current state analysis, licensing & vendor support strategy, and application analysis as their connectivity to the database is crucial to understand what was possible. The engagement took 4 months to complete, the major steps performed were as follows:

1. Current database analysis. Corvus IT ran its information collections scripts across all the databases. These scripts give us deep insight into all different technologies used within the databases including niche capabilities such as streams and queues. We built an understanding of how the database is used and built a matrix of what database features are used across the database fleet.
2. Application Analysis. This was primarily performed using meetings with all the application teams where we interviewed the technical personnel and gathered all necessary information regarding the technology of the application, how its SQL is generated and dependencies on the underlying Oracle database.
3. Database Market Analysis. We then did an extensive internal exercise of mapping the usage of the Oracle database against 9 alternative databases including the target database of Microsoft SQL Server. It was important to demonstrate to the client the relative advantages and disadvantages of each database as the target architecture was not decided by the client based on ease of migration, it was decided based on cost-effectiveness and supportability of new workloads.
4. Migration Cost Analysis. We then did high-level cost analysis of the database to viable databases and challenges that would be presented to the application layer. Some of the alternative databases had already been eliminated and instead this exercise focused on the remaining 4 potential candidates including the target database of Microsoft SQL Server which of course could not be eliminated.
5. Draft Strategy Presentation. We then conducted a series of presentation workshops with a mix of management and technical leaders. We shared the process we conducted and the conclusions that we reached. It was important to understand the client's reaction to the conclusions being offered and ensuring that the strategy being tentatively offered is palatable to the organisation and could be entertained as a realistic strategy. The strategy offered was not expected by the client, but we demonstrated that it was a result of analysis, not bias. A key influence on acceptance of the strategy was cost to implement the strategy.
6. Strategy Submission. This was a reflection of feedback received, not to change the strategy which was universally agreed once understood, but to deepen the strategic relevance and how it could be implemented at the client. This also included a new section detailing a Proof-of-Concept exercise to validate what was being stated in the strategy.

The client then wrote its own briefing paper and attached our final strategy submission and circulated throughout the organisation. This led to formal endorsement of the strategy which enabled subsequent funding.

The Outcomes

The major outcome was that we devised a path to the target architecture that would have an external cost of 17% of their own estimates. To their surprise, the chosen database was not the target database of Microsoft SQL Server. Instead, it was another database combined with an excellent migration tool that would quickly allow them to a supported and current database and implement additional capabilities of encryption and clustering that were not deployed with their Oracle fleet. In addition we had to account for WebLogic. We also provided 2 recommended solutions for this and an Enterprise-grade option was chosen that was capable of High Availability configuration with little change required to the WebLogic Java WAR files with the exception of WebLogic specific extensions included in the code which fortunately for the client were not present.

To prove the capability and ease of migration, we undertook a proof-of-concept with the client where we installed the database in a clustered HA configuration on RHEL 8 and migrated the Oracle database data, data model, PL/SQL and other Oracle artefacts into the new database. The challenge in this exercise was the needless implementation of custom data types in Oracle and unusual usage of GUIDs that required a change of approach in PL/SQL and triggers in the new database. We handcrafted the treatment of custom data types and GUIDs, but the remaining migration was very successful.

The operation of the databases included starting/stopping, stopping a node with application continuity and database restore tests. This generated a lot of excitement within the client as this represented a significant improvement to a set of stagnant applications.

As there was a wide variety of connecting applications, we took a sequential approach where we proved the connectivity of SAP BI and once all testing was successfully completed with that, we then deleted all data and migrated another database that was accessed via Java using JDBC connections.

The POC proved that what we had claimed as a result of our analysis was indeed accurate and the client had a quick path available to migrate away from their Oracle footprint onto an interim high-performing platform. The interim platform is the key enabler of providing the client sufficient time so that subsequent migrations to the target platform can be done when ready allowing future planning of funding and organisation activity. This removes the pressure of being forced to undertake a much larger and higher risk exercise that would be far longer in duration resulting in the current state remaining with the security vulnerabilities remaining.

?