Skip to Content with anything in the SAP space there seems to be an increasing degree of specialization in particular areas and this seems not different in the realm of BASIS administration. With the increased complexity and breadth of technologies in use in the stack I would guess that this is not suprising.

Veteran BASIS administrators who have been working with SAP systems for 5 or more years will likely have a good understanding of the sustainment issues related to care and feeding for SAP systems and they may have had their fair share of virgin installations of some additional systems like perhaps solution manager, TREX,  BW or PI/XI. In all likelihood they would have also implemented some archiving and even a couple of more discrete solutions like TDMS.

Out of necessity they would have likely applied some notes, support packages or even some support pack stacks. There may even have been some discrete kernel upgrades and all of these would have likely contributed to their learning curve and perhaps shown their personal weaknesses (or those of the technologies!) and may even won them praise and accolades from functional users and the corporate SAP user community as a whole. It is unlikely they really got any praise, but it is of course possible, and more importantly, if it was given, very likely well deserved!

Upgrading can be such a messy business. From a simplistic non technical perspective it seems so natural and well.. so obvious that you should! However in reality most BASIS administrators and functional analysts and users absolutely hate upgrades, the benefits seem to not weigh evenly with the effort. I daresay some would rather go to the dentist for a visit rather than do an upgrade to SAP production.  Additionally, if there is a general lack of corporate palate for upgrades then in all likelihood, some of those minor upgrade adventures  I previously described probably never really happened either.

Yes, the odd note may have been applied or perhaps even the odd kernel upgrade but it is unlikely that a full support package or stack was applied. When we get onto things like enhancement packages it becomes even less likely. This is not to say that they don’t happen, because of course they do, after-all some newer functionality can only be enabled by doing an upgrade and eventually the IT solution has to catch up to what the business is demanding. Upgrading though, is not for those with weak constitutions and requires careful planning and logistics to ensure that it all happens as smoothly as possible.  Project management skills and being organized becomes critical.

Installation BASIS resources, the kind that are often tossed onto virgin SAP implementations are often not the best kinds of BASIS resources to use for upgrades. The best ‘upgraders’ seem to  tend to grow up from within the support and sustainment organization and the reason quite frankly is because no ‘off-the-street’ BASIS resource can be reasonably expected to be able to quickly inject themselves into the existing BASIS organization with ease.

Consulting BASIS resources that are brought in at upgrade time are invariably directed in one or two different directions from the actual upgrade, though the upgrade initiative may be paying for them. They either have explicit experience of doing upgrades and do this so often that they are true battle-scarred and field-tested resources or they are relegated to doing the crappy mundane work that the sustainment BASIS administrators  normally do while the sustainment administrators  re-purpose themselves for the upgrade.  My experience is that a hybrid approach often works best. Get the best possible backfill for your in-house resources so that you can leverage that individual’s experience outside of your organization. Ultimately you can’t reasonably expect a contractor to have the same level of dedication as a full time employee, especially if he/she is only there 4 working days a week.

What’s in the BASIS toolbag?’s start with those true upgrade-experienced administrators  and examine what it is that they typically bring to the equation. My experience is that they typically have done this work solo or as part of a team, and when they are part of the team there is an expectation that they will bring very strong leadership skills and guidance to play. They have to be meticulous individuals. They are the kind of resource that inherently knows the contents of the checklist that they have to build when preparing all the BASIS tasks for the upgrade. In environments where upgrades have been few and far between they have to quickly assess the climate for the upgrade. They need to understand the drivers for the upgrade, the leadership model and the extent to which the organization has prepared for the upgrade.

I have hardly ever seen an upgrade that ever went perfectly smoothly and often it seems the initial projections of the level of effort for the upgrade are underestimated on both the technical and functional fronts. The original idea behind upgrades was that notes were applied to address very specific bugs or defects in the application logic or to improve system performance or related issues. Support packages were expected to bring corrections for program errors and often encompassed notes that may have been previously applied; support packages were never meant to include functional changes or SAP Enhancement Package 1 for SAP NetWeaver 7.0, just corrections. But, as any experienced BASIS admin will tell you, sometimes a support pack did include a ‘correction’ that made a functional change or enabled a new feature. If you wanted new features you were expected to implement enhancement packages.

So in the sustainment scenario I would expect that an agile BASIS team would apply support packages as frequently as they are released. They may not implement them as soon as they are released, but a regularly planned schedule for keep the system up to date ultimately implies that there will be fewer notes applied in the interceding period between support package upgrades.  The reality though, is that BASIS invariably doesn’t do anything about upgrades unless they are driven by a business requirement. This the inability to apply a given note because the system is so far behind on support packages may become the catalyst for a project to do an upgrade.

Again, familiarity with the landscape plays heavily into being successful with the upgrade. Part of the upgrade BASIS resources role, is working with the SAP functional analysts to determine the areas of the system that will be impacted by the upgrade. This may involve a laborious review of the release and sap notes and a comparison with the applied notes. It may also involve a heavy technical and functional scrutiny of system customizations, understanding the maintenance optimizer, understanding or deconstructing user exits, interfaces and related technology components. Taking inventory, assessing some degree of risk, analysis of objects and understanding some of the standard SAP methods for analysis system impact as well as 3rd party solutions all becomes part of the toolbag. I’d expect many of these to already be part of the sustainment BASIS resource’s bag  but you would be surprised how few resources know more than the routine stuff, especially if they don’t do upgrades very often.

Upgrade resources need to have a collaborative mindset

As the nominated technical resources on an upgrade project the BASIS resource typically has to work with the PMO to ensure that he/she has the resources needed to spin up a test and QA environment. This will typically require liaising with other technical groups like non SAP administrators, the QA team and the techno-functional resources tasked with verifying configuration and functionality. While the testing teams are testing functional quality, the BASIS resource will be looking at ways to optimize the upgrade and perhaps a cutover, planning a fail-back scenario, developing the short interval schedule that will dictate how much system downtime is going to be required. BASIS will ultimately also facilitate ensuring that users are locked out, logins disabled, logins enabled, a sample of users monitored for the thread or smoke test etc.

My experience is that large size databases seem to be an issue with getting upgrades in, this should come as no surprise. Between the time that the final testing of the upgrade was done (hopefully it was tested many times) and the day of the actual upgrade to the productive system business doesn’t stand still, the snapshot of the system changes and of course other elements will have changed. Additionally, the testing may not have covered absolutely all business scenarios. Some problems will arise, perhaps not on the day, perhaps not even within the week, perhaps only at month-end.

So on the day of the upgrade, you’re calling for cool and calm resources who will show initiative, patience, competency and leadership and above all demonstrate a good understanding of what they are doing so that when things go awry, they can quickly recover the situation or assess whether it is less risky to go ahead and fix forward or roll back and slam in the upgrade another day after they have triaged the unexpected outcome.

Here’s a great book by Martin Riedel and Anja Muller and offered by SAP-PRESS that you might also want to consider : though primarily focused on upgrading ERP 6.0 it has a lot of relevance to all SAP systems particularly in the context of building the team (section 4.1 Building a Project Team pp118).

To report this post you need to login first.

1 Comment

You must be Logged on to comment or reply to a post.

  1. Markus Doehr
    …often a pain in the a**, true.

    For ABAP out of my experience there level of stability and predictability increased over time but the level of complexity in the overall process (speaking of Solution Manager and specifically MOPZ) makes the whole thing messy. This is especially true if the system contains non-direct SAP Addons that are supposed to be compatible with the target release but are not released by SAP but by 3rd party vendors.

    Basically it’s nowadays more work to get the Landscape verification installed and configured (and notes-patched), set up MOPZ, download the stack and put all pieces together than doing the upgrade itself. Not much has dramatically changed since the first release upgrade I did (2.2D to 3.0E), phases are likely, error logs still have the same names and even some odd errors popping up since 10+ years are still doing so.

    Usually, as soon as you passed the step with the software packages target versions it’s quite straightforward and has always been like that. It’s mostly the environment (Solman!) that keeps me procrastinating, not the upgrade process itself.



Leave a Reply