Problem solve Get help with specific problems with your technologies, process and projects.

20 tips for upgrade success

Be a lean, mean, upgrade machine!

1. Hey! This is a project too.
An upgrade is a project and it needs to be managed as such. All the normal project management rules apply; from roles and responsibilities to detailed planning and scheduling. If you did not manage your own implementation and you do not have access to experienced project managers internally ensure that you have this skill set available, you will need it.

2. Take me to your leader!
The consensus approach is great but when it comes down to it someone will have to make the calls when the going gets tough or issues get hot. Ensure that you have an empowered Project Manager who can make decisions.

3. Spend a dollar to save ten
The costliest phase of any project is the execution (realization) phase when you have a large team engaged. Problems and issues can impact many people, and delays are costly (and high profile). Emphasize learning and discovery during the assessment phase when only a core team is engaged. Use tools like the Uptimizer to check out your custom developed code, do functional overviews, put together a training plan, etc. A great deal of work can be done in advance; you will lower the risk, save money and impress the boss.

4. Get the GUI out early
A big difference for the end users upgrading to 4.6c or beyond will be the look of the GUI and screens. Look in to the possibility of rolling out the new GUI early in the upgrade project. It will help the users get used to the look and feel. Don't forget you have the option of "turning it down" to reduce bandwidth costs.

5. Target training
It's almost a given that you have users on the system. And it is also possible that they would like to know where all the key fields have moved to! Target training to the changes ? and create a training plan and curriculum as early in the project as possible. Web based and CBT training have come a long way and are a lot easier to set up and create than a few years ago. Other training options:
* Classroom training, especially if you are introducing new functionality or processes
* Lunch time learning ? most users will turn up if you order pizza
* Super user ? train the trainer
* Newsletters, posters, web sites
* On line context sensitive help
* And don't forget the project team!

6. Get a fix on your development
You may not believe it but there is a good chance that since you installed that pristine SAP system for the first time, many moons ago, those sneaky developers have been creating all kinds of custom objects and hiding them in the production system. And you said this was "vanilla!" These custom objects (reports, tables, enhancements, BDCs etc) have a nasty habit of playing dead when you upgrade. So the sooner you know the impact on these objects the better and more efficient the upgrade will be. Use the Uptimizer in your assessment phase to root out all those nasty bugs and create your Repair/Replace/Redesign strategy before you get to the realization phase.

7. Give equal emphasis to all components
These are the major areas ? someone should own them.
Business: Activities that are directed to the business or organization
Technical: Activities that involve systems, hardware or their environment
Functional: Activities that relate your SAP functionality
Development: Activities that relate your custom developments for SAP

8. Look for helpful tools & services
It may be only a couple of years since the original implementation but a lot has changed. I remember when I first installed SAP; we had to train users on how to use the mouse and they thought that solitaire was a really cool game. Now they have PDAs and trade futures on the Albanian Stock Exchange. So it is a given that there are new products and services targeted at upgrades. Look around for new tools and services that will help you. SAP is much more focused in this area now. The new on-line help, e-learning and documentation tools look really good. And perhaps I could plug the Uptimizer one more time?

9. Final cut over should be a non-event
There should be nothing on your final cut over plan that the team hasn't been through or tested a number of times. You have the timing down pat. Everyone knows what, where, when and why. The team is a well-oiled machine. It is simply time to push the buttons, sit back and relax!!!

10. Is it getting cold in here?
In some businesses asking for a complete freeze of development activities for the duration of the upgrade is likely to get you the cold shoulder. So you will have to ensure that the upgrade and testing environment is able to consolidate both the development and upgrade activities for testing. If at all possible avoid having independent management of the teams for the development and the upgrade. It may be easier to have the development managed as part of the upgrade. In any event once integration testing has started all development activity should be frozen until after go live.

11. Is this really a "technical upgrade"
OK the plan is not to introduce any "discretionary" new functionality but without doubt some functionality issues will be introduced that will need to be managed. Keep track of these, as they will form the core of the testing, training and change management. Also there will be a number of "low hanging fruit" discussions. There is nothing wrong with pulling in some "easy to use" new functionality, but ensure that there is a formal project process to approve this, as it is often discovered after the blueprint phase. Also ensure that the low hanging fruit is not a lemon!

12. You may not get a prize for being first
When SAP releases a major new release there are normally three waves of uptake:
* True believers (first customer shipments); "that one power point slide has really convinced me, send the CD's"
* Followers (early adopters); "I've seen the web demo, and I know a true believer, send the CD's"
* Observers (the rest); "Great ? let's wait and see, but no need to send the CD's just yet"
There may be real business or technology reasons that you need to be "converted" earlier rather than later. Your project plan should reflect the added risks and contingencies that are inherent in being one of the first. It will take longer, and you will need to put extra emphasis on the "sandbox" learning & assessment phase before you involve the whole team. Tip #3 is especially relevant in this case.

13. Spread the load!
You have taken out the stopwatch and timed the cut over; it takes 60 hours. The only problem is that the business says that you can have 48 hours max. Reduce the load by doing as much as possible before the cut over begins. If you still cannot get your timing down enough, ask SAP about it's CBU (customer based upgrade) program. By the way, if the first time you find out that the upgrade will take 60 hours is on the Sunday of cut over weekend, your options could be rather limited!

14. Selecting test data
Don't use test data ? use real data as much as possible. One of the biggest differences between the original go live and the upgrade is the amount of data that is now in the system. Test data can be used for sandbox and functional testing but you will need real data to ensure that things are really working the same way as before. Ensure that testing includes modification of existing data (transaction and master) as well as the adding of new data. Stress and performance testing for critical areas are a must and are only realistic if the system is fully data loaded.

15. Supporting your current system while upgrading
Users are very unreasonable, they know that you and the team are working round the clock to get this system upgraded and they still expect the same level of support on the current system as before!! There just is not enough staff to do both. Why not call a consultancy company (hint ? Intelligroup) to help with the upgrade. Great idea! Not so fast Sherlock! What happens when the consultants go home? Your team that has been busy supporting the old system doesn't know anything about the new one. Is the answer to keep the consultants around a little longer while the support team comes up to speed on the new system? Perhaps not ? if you do not have the bandwidth to support AND upgrade, consider backfilling the support team with consultants (hint, we are rather good at this too!) rather than the upgrade team.

16. Start insider trading
The last thing that any IT project should be seen as is an IT project, even if it is. Get the support of management and key users for the project. Lobby to get business leadership and buy in, not just budget approval. Ideally they should think that the whole thing is their idea. After all if you have an upgrade meltdown you can say that you were just following orders. Read up on Enron management strategies for more tips in this area.

17. (a) Is there such a thing as an ROI for an upgrade?
17. (b) OK how do I persuade management that there is an ROI for an upgrade?
First of all you might need to look at upgrades as a total cost of ownership (TCO) issue, in the same way that regular servicing is part of the TCO of a car. Then we need to look at the possible savings and benefits that are either a direct or indirect result of the upgrade:
* Removal of high maintenance enhancements or work-arounds
* Retirement of legacy system or bolt-ons
* Reduction of operating costs
* Increased efficiency
* Competitive advantages
* Operational business benefits of new functionality that can be used ? either as part of an upgrade or phase II
* Strategic business benefits of new SAP solutions (CRM, WAS, Portals, etc).

18. Beyond "low hanging fruit" ? adding new functionality
There are two schools of thought on this: elementary school, "Dad, can I watch TV" and high school, "Dad, can I borrow the car". Or was it tactical and strategic? Anyway one is a lot more complex than the other, but either way you need to pay attention in class and do your homework. Oh! And avoid the bullies ? you know who they are!

Seriously, if you plan to add significant new development during the upgrade pay particular attention to what's on the critical path, scheduling and task dependencies. Personally, I prefer the elementary school approach, it's a lot less stressful and I can spend most of my day coloring in the Gantt Charts.

19. Network
Nobody knows everything, with, of course, the exception of my teenage children ? who I can make available at very competitive hourly rates. For the rest of us mortals it is just a challenge to figure out what we don't know. Networking is the best way to get a head start on this. It does not need to be a massive effort of dinner and golf trips, unless you are in sales! Find three people in the same job role as you in other companies that have already "been there done that". And call them for a chat, most of the time people are very willing to share the experiences ? I think it is therapy for them!

20. Don't forget the obvious!
* "I thought you were telling the users/customers/vendors/management/auditors!"
* "What do you mean the hardware lead-time is 12 weeks?"
* "What vacation!"
* "Doesn't everything work on 64bit?"
* "Who could have guessed that we had 3 year old PCs"
* "What other things need upgrading?"

It would be great to hear from you regarding your SAP projects and upgrade experiences, tips or tricks -- send email to

Dig Deeper on SAP implementation

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.