Planning the Notes/Domino 8.0.x deployment

Business Drivers: Start first by understanding the business drivers and why this upgrade is being undertaken. What does the business want to achieve with this upgrade ?

Project Expectations: If the business is going to spend money on an upgrade, then there must be some expected return. It is important that business stakeholders are aware of what the project is going to achieve and maybe more importantly the things it will not. If expectations are not properly set, then even if you (IT) perceive the project to be successful, the business may be left wondering why they spent the money.

Architecture Planning: Depending on the scale of your existing environment, you may or may not be able to do all of the work you would like in one project. Defining the scope and exactly what things will be undertaken as part of this particular project helps with expectation setting and with planning. As well as upgrading software there may be a number of other changes that you wish to perform at the same time. For example, a switch in hardware or operating system to better align with strategic directions.

Test Planning: Testing can be an expensive, boring and time consuming task. It is very important, but planning what is going to be tested and how that testing will be accomplished are details that help to prioritize and estimate project effort.

Training and Communications: When budgets are tight, these types of activities are often the first casualties of the plan. But they are extremely critical for both acceptance of the change being expected of users and to maximize the return being expected by the business for their investment in this upgrade. It can be a false economy to skimp on training and communications, if you pay the price later in support calls, lower productivity and dissatisfied users.

Pilot Planning: A pilot is really the final opportunity to validate your solution with some real world, and typically non-IT, users. While test planning will allow you to think of the major cases you need to validate, users somehow always find obscure ways to use software. Allowing real end users some time on the solution prior to deployment to the masses will help ensure that you have covered your bases and reduces the risk of unexpected surprises.

Deployment Planning: When you are ready to pull the trigger and upgrade the user population as a whole, you will need to have a specific sequence and schedule in mind. Since this can be the most time consuming portion of the project, the way the deployment is executed can have a big impact on the overall cost. Should it be done by business unit, geographic location, some other demographic criteria, or even a mixture of these ? Training and communication need to run ahead of the actual deployment schedule, so you need to know who will be upgraded and when so that these activities can be coordinated appropriately.

Evaluate

• Do a thorough investigation of the current state (starting point) and use tools to facilitate data capture
  - Server infrastructure (including baseline stats, performance, etc)
  - Clients / workstations
  - Applications
  - 3rd party Products
• Document pre-existing conditions and problems
  - Try to resolve outstanding issues and problems prior to upgrading
  - No matter how tenuous the link, an upgrade can be held responsible for any problem whether old or new
• Document things you want or need to address while you have the opportunity, focus and resources available
  -There is always cleanup that can be done ahead of time

Monitor

• Monitoring is a critical part of any upgrade, even a point release upgrade
• The goal is to understand your current cost of running the existing environment and to predict a problem before it happens in the new environment
  - This is really important when you are moving users and/or consolidating servers
• Steps:
  - Make sure you are capturing the available raw data from the servers
• Operating system capacity and performance metrics
• CPU, memory (usage, paging), disk (usage, I/O rates, performance), network
• Domino server specific statistics
• Other components (for example, SAN switches and disk metrics)
  - Interpret/analyze the data and create your baselines for your current environment
• What are the typical operating parameters for your servers
• What is the data telling you about your environment?
  - Execute your monitoring processes using your base lines
  - Create your daily/weekly/monthly reports based on your baselines
  - Create a remediation process based on outputs that exceed your baselines

This is the classic recommended deployment sequence. This does not account for organizational, demographic or other constraints. This should be used as a guiding principle while taking other factors of your business into account.

Items 1-3, highlighted in yellow, need to occur regardless of the overall strategy and sequence of server/client upgrades. If you upgrade the Domino directory in step 2, you will have to do that offline and pull the trr

Items 4-5, highlighted in red, can be achieved in various ways; all non-user facing servers upgraded before those that users access (as depicted here) or in larger organizations it may make more sense to upgrade all servers in a given location before moving to the next location in which case some infrastructure and some user accessed servers will be upgraded at the same time.

Items 6-9 are important steps to take advantage of all of the new features that Notes and Domino 8 have to offer. Given the large size of your Notes client base, communication needed, training required, etc. these steps are often carried out months after the server upgrades. This allows time for production testing before rolling out to hundreds or thousands of users.