This question was posted in our Expert Challenge discussion forum. See what other helpful SearchSAP users had to say about this tricky problem!
SAPstalled: "Suggestions for the following situation would be appreciated: We want to upgrade but there are a few problems. We currently have one of the largest single instances of SAP with five separate business units having somewhere in the range of 2000 total concurrent users during peak hours. Plenty of customization especially in the SD module. SAP is thinking big bang approach but the majority of us on the IS development teams want more options. Many customers, vendors, shippers, and other business partners are shared bewtween the businesses. Its imperative for the migration to appear transparent externally to the corporation. Is anyone aware of documented and available information on similar migrations?"
EasVZLA: "We just went from a 3.0f to 4.6c upgrade. I do not see (and we did study the options) any way you can do this instead of going trough a Big Bang approach. We were ready for November 2001 to go at it, but our business rises in the last quarter, X-mas season, so we postponed it for spring break (carnival in this part of the world). You will need at least 3-4 days with the system down, depending on how big your data is. We took 6. We also upgraded our server, operating system, and Oracle version. Went from a 32bit to a 64bit. We did make a data capturing software for our production facilities.
SAPMGR: "Your problem is one that many have been through including myself. There's no way that I'm aware of that you could upgrade to 4.6 from 3.x and make it seem transparent. There's a huge delta between the two systems but here's an approach that we used that may minimize your downtime but will cost you more in terms of resources and hardware: We developed parallel systems to manage our upgrade, which also allowed us to understand the deltas and make the necessary changes outside of our production environment. We were able to refresh data into our systems on a weekly basis, allowing development & configuration during the week. The refreshes were used to ensure that production data was being used for our testing scenarios into the parallel systems. Once we tested all the functionality and processes to include (batch, legacy, interfaces, ale/idoc, payroll transmissions, bar code reader/transmissions, etc.) We scheduled our big bang to occur on a holiday weekend - this allowed us to complete batch, backup our systems and then perform big bang activities. We were down a total of 4 days (Fri, Sat, Sun, and Mon) There were plenty of post implementation issues but we had everything back to normal before the end of the week - If you need more specifics and or details let me know."
SAPstalled: "An interesting approach, I appreciate the response. In regards to the Parallel System, I have several questions since I'm assuming some of the details based upon your response. I would appreciate your reply.
1. Did the users practice on the new system performing identical transaction concurrent in each system, i.e., enter a sales order or production confirmation in 3.x and then again in 4.x?
2. Did you set up specific printers for the P.S. in order to validate the output of BOLs, Invoices, Packing Slips, etc.?
3. How did you test interfaces from bolt-on systems? I would suppose we could capture a sample of the actual inbound data files and run manually.What was your interface testing methodology?
4. You mentioned additional costs in hardware and resources. Can you describe your additional hardware requirements and resources? How were the resources managed and allocated, i.e., 2 employees for MM, 4 for FI/CO, 2 for PP, etc..
5. Was the parallel client a complete copy of the 3.x production system including all data or did you limit the size of P.S. to some point in time such as 6 months of data for example? Thank you in advance for your reply."
SAPMGR: "Our parallel environment contained 6 months worth of data so that we could simulate daily and end of month processing. As for printers - we configured the parallel system so that we could point to specialized printers. Special forms such as checks, orders, invoices, and notifications were all tested in the parallel environment. I don't think I answered all your questions because of the timeout option but I'm willing to share my experiences with you if you provide an email address where you can be reached."
BasisLogic: "You can't make it seem seamless to the organization because a lot changes (not to mention the GUI), and SAP Easy Access. The changes to SD require study. Some of your customizations may now be standard - or conversely - some of your changes may prevent the upgrade team from reverting SAP delivered code to standard. In any case, I suggest you get in touch with SAP, and investigate the CBU upgrade process. I performed a CBU (Customer Based Upgrade) at a client. It takes a lot of preparation, but the productive system was out of service for only 10 hours on a Sunday. Its a great tool."
This was first published in August 2002