Upgrading to Lotus Notes Domino 8

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 time lines for the upgrade. A simple vision charter might read something like this:

THE COMPANY will upgrade their ND5/6/7 architecture to Domino 8 in X months, taking advantage of new Domino 8 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 email 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 impacted by the upgrade.

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 server have been upgraded.

A use case can point to the need for:

• Client upgrade
• Server upgrade
• ODS upgrade (optional with Domino 8)
• 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 excerpt.

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 time-lines. 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 new Domino 8 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 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 client on a sampling of your current PCs. This particular test verifies that Lotus Notes 8 will run on your exiting hardware, and does not impact any other applications and/or PC environment. As testing progresses, you will start to include each other element into the environment, for example, Lotus Notes 8 on the network, on applications, Notes 8 client that will access a Domino 6 or 7 server, and so on.

The goal is to test Lotus 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 (or any new release of Lotus Notes/Domino) is support 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 is working as advertised by the vendor.

Create upgrade process document and plans: Create all of the upgrade steps, procedures, and schedules, training, and Frequently Ask 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 manifest 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 excerpt).

As we mentioned earlier, you should test as much as possible in a test environment before executing a production roll-out. 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, which 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. Your company may experience a few changes to the architecture, some changes to end user clients, and possibility a few changes to the administration teams. In some cases the end user and administrators may require some training on Lotus Notes and Domino 8. Your company should consider the following activities as part of the administration and migrations team's transformation management activities: Develop a team name: for example, The Domino8 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 FAQs, 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 transformation management 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 migrated 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 left over migrated users into the current customer steady state support staff.

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.