One of the most important items for an upgrade is the Implementation Plan itself. The implementation is a critical document in any release, and it is much more critical in upgrades and patches. For each of the following items, I had a start time, a duration, and expected end time. I could tell you at any point if my team was running behind or ahead of schedule. The following items were part of any release I led for an application used by more than 5000 engineers. I led the team drive, and my "Release Manager" job was to ensure, we were smooth and quick transitioning one task to the next team member. Here is a list of the first 5 items I had on my list.

1. Client package deployment (the upgrade started before we even shutdown services. To push desktop clients to global sites had to start at 12pm or so because it would take hours to push packages to all global sites).

2. Start time for shutting down services. This is the actual start of the upgrade on the Enterprise servers. We started with the web application server because that was the entry point for all users. We then killed every user session that remained.

3. Create a restore point for the database. For an upgrade, you need a full backup of the database. There is no way a restore point can help. Ensure your database backups will not run either.

4. Database upgrade (may involve multiple steps). This is one of the most critical tasks and it had to start as soon as possible. I manage a critical path of tasks for the implementation plan. I let the team manage the uncritical tasks.

5. Multi-site Upgrades. If you manage an on-prem environment, you are likely to have one or two other sites that you must upgrade at the same time. You need to keep track of progress and learn from each other. The sites should have the same datamodel/schema.

While, I don't elaborate much, the rollback plan is a must. Have a detail plan how to rollback and how long, that plan will take. And it must include the Testing plan as well. No one likes this, but I actually had to rollback at least once that, I never went into a major application change without a rollback plan.

The second most important item for an upgrade is the list of contacts to support the upgrade. When something went wrong, I need to be able to call the right person to help. This is amazing to me that we never had the same issue so I had to book almost everyone. I create tickets to ask other teams to support the upgrade and I asked for their on call phone numbers. Most of the time, I got that information. Here are five of the teams I always needed on call.

1. Database support. This was one of my most critical support people. You must have an amazing dba person. If not, get two for every release. The great dba administrators can look at your application documentation and make decisions based on that. Sometimes, the application team may not know much about the database and what variables must be set. This should all be well documented by the time you are running the upgrade.

2. Client Deployment Support. If you have only web applications, you are golden. Sometimes, you have applications that have desktop clients, these are difficult to upgrade because you need to touch every computer. Hopefully, you have built an platform to push the client packages close to the end users and when they login, the morning after the upgrade, the updates will happen seemlessly. This never happens though. Plan for support the day after the upgrade.

3. Web Application Support - for a full enterprise application, the application team may only have control of the application itself, but not the web application server. There are times when a simple java patch causes so much trouble with the web application, thus always get your best support person. In fact, you may need web application support in DEV and QA before you even do it in prod. I had one instance where the application session would expire as soon as the user logged in and it was a firewall issue. Managing applications can be challenging and I wish my team owned it all but it is not possible.

The last item, I would like to discuss about upgrades is end user support. There are a lot of steps in the upgrade, but at the end of the day, your end customer must know that when the application comes back online, that the application team will be there to support them. My last item in the implementation plan was, end user support sessions. This must be run almost as soon as your application goes live and the first wave of end users (in a global environment) will start using the system. It is better to let one wave of users login and find the issues. Log defects and later when the application team is back online (they may have worked all weekend), you can start fixing things before everyone globally starts using the system. Plan this well and even if you don't have a perfect upgrade, you need to have the perfect end user support plan.

# PLM #Teamcenter #SoftwareUpgrades