Architecting a SAP upgrade and re-engineering your SAP Landscape.
I’ve had an idea for a series of SAP Upgrade blog posts for a while and am now getting finally around to writing them up.
This series of posts will describe how we upgraded and changed the underlying architecture of our SAP systems and improved our end user experience.
SAP Landscape pre upgrade.
SAP EP
Version 7.0 with ESS and MSS,E-Recruitment Business packages installed and configured for a full HCM implementation.
Single Stack
Dev QA Prod instances.
SAP ECC5
Web as 6.40 running a full FICO,PS,MM,SD,HCM and payroll. Running Java 6.40 due to SAP recommending that the portal talks first to a Java stack with the same version as ECC that your running so our EP-ECC-JAVA-ECC-ABAP is the round trip for ESS/MSS.
Dual ABAP+JAVA stack
Dev QA Prod instances.
SAP XI 3.0
Used to connect to oracle based systems, 30+ interfaces running, including cash processing and invoice processing via a online gateway. I.E. income.
ABAP+JAVA
Dev QA Prod instances.
SAP SRM 4.0
Used for requisitioning and approvals for purchase orders, posts back into ECC5.
ABAP only
Dev QA Prod instances.
SAP E-Recruitment
Running on a standalone ERP 6 /ECC6 EHP 3 system, installed post go live from ECC5 due to needing the newer functionality of what was the latest available EHP at the time.
Sits in its own 3 Tier Dev-Qa Prod landscape, again is external facing and used for job search. http://www.shef.ac.uk/jobs. If you search for jobs available that’s our E-recruitment system, live and external facing.
ABAP Only
SAP Business Connector.
Used for HMRC E-filing UK legal tax, both incoming and outgoing forms, P45,P60 etc.
Single instance
SAP Solution Manager 7.0
Documentation, ASAP configuration etc.
Single Instance
Hardware and Database
All of the above systems are running on Solaris servers using Oracle Databases and have a Netapp Filer attached and mounted for storage, which SAP runs off.
Scope of the upgrade
ERP 5 – ERP6 EHp4
XI3.0 – PI 7.1
SRM 4.0 – SRM 7 Ehp1
Other upgrade tasks are :-
Java stack removal on our ERP system
Deployment of SRM into Enterprise Portal, reconfiguration of Portal connections.
Patch the portal to the latest SP’s.
Landscape Post upgrade
SAP EP 7.0 – ESS/MSS/E-recruitment/SRM Business packages – Single Java stack
SAP PI 7.1 – Numerous interfaces – Dual Stack ABAP+JAVA
SAP SRM 7.01 – Classic Scenario, with external supplier catalogue via OCI. – Single ABAP stack
SAP ERP 6 EHP4 full FICO,PS,MM,SD,HCM and payroll – Single ABAP stack
The switch from Dual ABAP+JAVA, EP Patching ECC5-ECC6 EHP4 and SRM 4.0 – SRM 7.01 deployed in the portal all occurred during one weekend from Thursday night, with a shutdown Friday/Monday.
The systems available for business user testing Sunday/ Monday, and back with end users on the Tuesday morning.
No consultancy was used for Basis or Development, the only area where we used consultancy was SRM 7.01 Webdynpro & configuration on the application side.
During the Sandpit, dev and QA builds we all personally upgraded SRM and ERP systems to make sure that a cross set of skills was available for the upgrade weekend should the worst happen.
The development team consists of four SAP developers and three people including myself on the basis side.
Hi James,
this will for sure be an interesting series of blogs.
You said,
'The switch from Dual ABAP+JAVA, EP Patching ECC5-ECC6 EHP4 and SRM 4.0 – SRM 7.01 deployed in the portal all occurred during one weekend from Thursday night, with a shutdown Friday/Monday.
The systems available for business user testing Sunday/ Monday, and back with end users on the Tuesday morning.'
I think you were very lucky get have the luxury of the Friday and Monday.
I've been a member of the Basis upgrade team on large landscape upgrades at various companies during the last 6 years, and I've never seen a client where we could take the systems away Friday or Monday.
Infact, we were bound to very tight CutOver downtimes based upon calculations made from our experiences of upgrading the non-prod systems, we had to estimate to the hour how long our Prod upgrades would take and with no acceptence of fat in the estimate.
We were told if the CutOver was late we would cost the business money, and if the CutOver came in early we would cost the business money because the factories could have been running instead of being stopped.
We found there was normally one system which made the critical path for the whole CutOver, it could be on some upgrades Portal with all the Business Packages and Customer Developments, or ECC-HR with ECC6 EHP5 etc. This one system in the landscape would be the critical path for the CutOver timeline and downtime.
Systems would go live after Cycle Zero Activities and closing all of the defects found during Slow Motion Testing and then any new incidents after the systems are handed back to the business would be fix on fail.
Landscape upgrade at large SAP landscape Customers are a science.
We learn't a lot of tips and tricks during these years.
For example, at the Prod CutOver Go-NoGo meeting, the systems would be handed from Operations Maintenance to the Project Team, part of that handover would be a defects sheet describing all open incidents which existed before the CutOver. The point of this was to be able to isolate what incidents existed before the upgrade and which were new as a result of the upgrade.
Looking forward to your next blog.
All the best,
Andy.
We were technically ready Sunday to go live Monday morning, and areas such as payroll were able to use the system straight away on the Monday post upgrade, but more complex areas such as financial accounting wanted more time to check the system was working fine.
Great blog, James! That sounds like a very complex upgrade, but it sounds like you've got all your ducks properly in a row. I'll be very interested to hear how it goes. 🙂
Cheers,
David.
Already live David !
We went live in the second week of January this year on this landscape !
Went well !
LOL, sorry, I misread that.
Well, a hearty congratulations, then!
Battle stories are also enjoyed and appreciated, if there were challenges to overcome (aren't there always?). 🙂
Cheers,
David.