After you have decided to upgrade to Domino 8.5, you will need to create an upgrade plan. Most companies are not able to upgrade all users (clients) and servers at once. There are several things that you need to consider before you upgrade. This chapter explains these things. Overall, the upgrade process from Notes 6 or Notes 7 client is relatively easy. You can use the SmartUpgrade process to help upgrade these clients.
This chapter is divided into two main sections. In the first, we look at the Notes/Domino upgrade process in general, discussing concepts and steps that should be considered whenever you upgrade to any major release of Notes/Domino. In the concluding section, we look at upgrade issues that are specific to Notes/Domino 8.5.
The Domino/Notes upgrade process consists of a number of phases, as follows:
- Vision and direction
- High-level architecture analysis
- Use cases
- Requirements
- Agreements
- Final target architecture
- Creating the design and upgrade plans
- Creating a test plan
- Testing
- Creating upgrade process documents and plans
- Executing logistics plans and schedules
- Creating the pilots
- Updating and final changes
We discuss each of these phases below.
Vision and direction: This phase is where you define your goals for the upgrade. These goals can include your business needs, a basic idea of your current IT architecture, and some rough timelines for the upgrade. A simple vision charter might read something like this:
THE COMPANY will upgrade their ND5/6/7/8 architecture to Domino 8.5 in X months, taking advantage of new Domino 8.5 features, and will also consolidate several servers during the upgrade.
High-level architecture analysis: Before you upgrade, make sure you know what you have. Experience tells us that most companies cannot identify 100% of their environment. A good review is prudent, so as to keep surprises to a minimum. Take the time to obtain a list of applications, including e-mail applications and custom applications, backup systems, virus scanners, and web-based services and appliances. Build an inventory of all things that "touch" Domino. This will help you identify any items that may be affected by the upgrade.
One of the best methods to help determine your inventory is to use native Lotus Notes/Domino tools. These include:
log.nsf(the statlog process will create the entries inlog.nsf—database inventory).names.nsf(use the server view to get a complete inventory of servers).statrep.nsf( the collector process will update this database).DDM.NSF(if enabled, use this to determine the overall health of your Domino environment).- Domino Configuration Tuner: This tool provides an extensive list of potential problems that should be fixed before you upgrade your servers.
Use cases: A use case, in this context, is a statement and description of a system/service that defines the use and behavior of an environment. A basic use case should include the following elements:
- Upgrade steps
- Description of requirements
- Goals to help target requirements
- Identification of "actors" (the people using the system: users, administrators, operators, and so on)
- Identification of associations between use cases and actors
These documents will help you build a set of requirements. In each use case, you should also identify various states of the upgrade. Examples include upgrading the servers, and enabling the new mail policy feature once all of the clients and servers have been upgraded.
A use case can point to the need for:
- Client upgrade
- Server upgrade
- On-Disk Structure (ODS) upgrade (optional with Domino 8.5)
- Communications and transformation management
- Application upgrade
- Custom API upgrades
- Calendaring and Scheduling (including rooms and resources)
- Administration tool upgrade
- SMTP service upgrade
- Security impacts
- Directory impacts
- Process upgrade
- Help desk
A sample use case is included at the end of this chapter.
Note
As stated, ODS 51 is optional with Domino 8.5 but ODS 51 is needed if you require the use of Domino Attachment Object Service (DAOS).
Requirements: When all the use cases have been created and agreed on, you can summarize them into a total list of requirements. These use cases and requirements can be used to determine upgrade steps, use of new features, systemic impacts, budgets, and timelines. These requirements will be used to create the "draft" target architecture.
Agreements: This is where you will build out your budgets, build out decision records, and obtain agreements from all interested parties in your organization. After all of the agreements have been approved and signed, then your target architecture can be finalized.
Final target architecture: At this point, the final target architecture can be created. In most organizations, there will normally be a phased approach. It can take several iterations to get to this final architecture. One example would be the new Domino 8.5 programming functions. In order to take advantage of this feature, you will need to have both servers and clients upgraded before the new functions are enabled.
Create the design and upgrade plans: This step is where you start the process to detail the upgrade process. Also, you begin documenting the process that will be used as a step-by-step upgrade guide.
Create a test plan: Remember the identification of new features and requirements? This is where you create a test plan to test each of the upgrade elements, which includes the server, clients, applications, custom tools, and other items.
Testing: The flowchart below shows the testing and pilot process.
Each part of the upgrade should be tested before you actually put any new technology into a production environment. Most companies execute what are known as "unit" or component tests. These tests are the basic components of the new technology. For example, you might choose to test the Notes 8.5 client on a sampling of your current PCs. This particular test verifies that Notes 8.5 will run on your exiting hardware, and does not affect any other applications and/or PC environment. As testing progresses, you will start to include each other element into the environment; for example, Notes 8.5 on the network, Notes 8.5 on applications, Notes 8.5 client that will access a Domino 6 or 7 server, and so on.
The goal is to test Notes/Domino in a holistic test environment that replicates various part of your production environment.
Note
One very important step is to contact each vendor for any third-party tools and utilities. The upgrade process will make changes to the directory, and then to each server. Be sure to contact every vendor and determine whether or not Domino 8.5 (or any new release of Notes/Domino) is supported by that vendor. Double-check to verify that APIs have been recompiled (as needed) by the vendor, and that the new directory is supported. Then do your own testing, to make sure all are working as advertised by the vendor.
Create upgrade process documents and plans: Create all of the upgrade steps, procedures, and schedules, training, and Frequently Asked Questions documents. Some of these documents will be the actual upgrade steps and checklists. If you are upgrading a large number of servers and users, then you can use a tracking database and/or spreadsheet. The results of the testing will be manifested in the upgrade process. Also, communications plans should be created at this time.
Execute logistics plans and schedules: This is where you order any equipment, hire any additional staff, and start the overall upgrade process. Included in the scheduling process will be the execution of the pilots. (See the following step.)
Create the pilots: Next, create and document each pilot that is needed. You will need two pilot types—non-production pilots (technical pilots, process pilots), and production pilots (shown in the diagram later in this chapter).
As we mentioned earlier, you should test as much as possible in a test environment before executing a production rollout. These non-production pilots are an opportunity to test each step of a process. These should include:
- Upgrade steps
- Training and education
- Communications
- Help desk testing and FAQ
- Executive help staff
One important step of the pilots is "lessons learned". Each pilot is an opportunity to modify upgrade steps and processes.
Non-production pilots are normally separated into two types, technical pilots and process pilots. Technical pilots verify that each holistic step of the upgrade works correctly. Process pilots verify that the actual checklists and documents are correct.
Transformation management: When upgrade/migration projects fail, it is always people issues, not technical problems, that are the root cause. Transformation Management (TM) is a formal process to help identify and mitigate the people issues associated with each project. Change is implied by any upgrade and/or migration. TM takes into considerations the various work environment issues that occur during the upgrade/migration project. One core fundamental part of any TM plan is communication.
Here is a simple example that could form the basis of the communication part of a TM plan.
Your company is taking on a migration/upgrade to Domino 8.5. Your company may experience a few changes to the architecture, some changes to end user clients, and possibly a few changes to the administration teams. In some cases, the end user and administrators may require some training on Notes and Domino 8.5. Your company should consider the following activities as part of the administration and migration team's transformation management activities:
- Develop a team name: for example, The Domino 8.5 Upgrade Team. (Also create a team logo.)
- Develop a team charter: for example, Migrate/upgrade x number of users in n number of weeks.
- Announce the date of the final "migration done" party.
- Create an intranet website with a list of FAQ, and the names and pictures of the migration team members.
- Create a Red/Yellow team to isolate the migration team from the end users (post-migration issues).
- Develop two sets of communications from the migration team to end users. This should be added to the overall TM planning.
- Introduce users to the migration team. These users will be notified about the migration team and their purpose. Also users should be instructed about whom they should contact with questions about the upcoming migration. LPS/ISSL recommends that the help desk be trained about the migration and possible end user questions.
- A pre-migration FAQ should be created and hosted on the Intranet.
- Print posters with the name of the team and the logo on the top of the poster, and place them where they are likely to be seen (break rooms, elevators, and so on).
- After users have been migrated, send out a weekly message to migrated users, with "Tips of the week" and other relevant information.
- Three milestone meetings will be needed for your company's
migration/upgrade:
- The opening meeting: The CIO or CEO should open this meeting. A quick five minute pep talk is all that is needed from the VPs, but it could be important for the team to let them know that there is executive support. The lead project manger will launch the migration, announce the plans, hand out procedures, and review the whole process.
- The "half-way" meeting: This occurs when 50% of users have been migrated. This is a great cause of celebration, so give out some special awards!
- The final party: At the "98% of users migrated" mark, close out the migration. Move the remainder of the migration processes into the permanent support staff.
- Close out the project.
- Transfer any leftover migrated users into the "Customer Ready State" and then notify the support staff that this step has been completed.
A "go/no go" decision is made before the production pilots are executed. This decision will be based on the results of the testing and pilots. If all have been successful, then the next step will be the production pilots.
Once all of the pilots had been completed, you will need to start the actual upgrade process. Use a set of "friendly" users (never use executives!) for the first pilot. The preceding diagram shows two production pilots. In reality, you will execute as many as are needed. Each pilot will provide lessons learned to be used for the next pilot.
Update and final changes: After all the pilots have been executed, and you have had an opportunity to update the processes and make any final changes to the overall upgrade process, you will be ready to roll out the upgrade to your enterprise.