Combined Upgrade and Unicode Conversion (CU&UC) Cutover Project Plan Execution
Completed another Upgrade and Unicode Conversion (CU&UC) project at the beginning of this month Feb 2009, taking the total number of such projects to a dozen! This project is an HR landscape with production system about half a Terabyte in size. This would be a good project to talk about, as all the techniques that I used for bigger databases in the past, were also used in this one. Half a Terabyte is not very big by today’s standards. However, this project has some unique features that are worth noting. First, the go-live was extremely smooth, with literally no open Basis tickets post Go-live!
The following is the flow diagram depicting the major milestones during the cut-over period.
PRODUCTION CUTOVER PLAN EXECUTION
Second, the total duration of this combined Upgrade and Unicode project was less than 4-1/2 months! The landscape comprised 5 systems – Evaluation, Development, Quality Assurance, Staging (dress-rehearsal) and Production. All were both Upgraded and Unicode converted from 4.7×110 to ERP6.0SR3 SPS3. Of course, to make this happen, throughout the project, Basis had to provide almost 24×7 support for various tasks like system copies, building 2nd landscape for production support, upgrades and Unicode conversions of main landscape systems. etc.
A smaller size database meant that it was easier to repeat a step (if required) without losing too much time. However, it obviously still demanded the execution of all the steps involved in the complex combined Upgrade and Unicode Conversion. A shorter overall project duration meant that all the processes and steps needed to be streamlined more thoroughly and executed efficiently. It was very important that we receive quick response from other groups like Unix, DBA, Basis, ABAP and functional.
Employed “Downtime Minimized” methodology for upgrade. Also used SAP tools – Distribution Monitor, Table Splitter, Package Splitter, and techniques Loadprocedure fast and orderby for Unicode export and import. Made use of 4 servers to perform the export and import, and 1 source DB and 1 target DB server. The hardware was not the best hardware that is currently available in the market. These servers were also used for other live instances and, hence, it was required to limit the amount of CPU and memory usage.
The above diagram is self-explanatory. The upgrade and Unicode export/import downtime processes were done within 20hrs (the left hand side of the diagram). The post Unicode steps and other downtime activities, including functional testing, took 38hrs and 20mns (the right hand side of the diagram). In spite of the older hardware and sharing the hardware with many other instances, the Unicode conversion time achieved was about 6.5hrs, which was good enough considering the large cluster tables in the system.
In the next blog, I will try to provide more details on the upgrade timings, export/import timings, and strategies employed.