You should approach your migration with the same careful planning that you used with your initial installation. Careful planning for your migration can help prevent critical problems later on. Before starting your migration, you need to familiarize
yourself with the new features in Notes Release 4.
This chapter lays out a standard plan for migrating your installation to Notes Release 4. Migrating can be a large job, and before diving in you should consider whether Notes Release 4 is the correct platform for you.
This chapter covers the following topics:
Lotus certainly acts as if it's a foregone conclusion that you will migrate your Notes installation to Release 4, but this isn't necessarily the case. Migrating to Release 4 involves retraining your support staff and end users, in addition to a
considerable amount of planning and time to carry out the migration. Before migrating to Release 4, organizations should review their use of Notes to determine whether a migration to Release 4 is the best investment of their support staff's time.
You certainly will want to migrate to Release 4 if:
Medium and small organizations need to do some rough cost/benefit calculations before migrating to Release 4. Even if you decide that moving to Release 4 is a smart choice for your organization, the timing of the move can be important. Waiting for an
update to Release 4 may make sense for any organization, large or small, that uses Notes to run mission-critical applications.
If you are currently experiencing problems with Notes Release 3, migrating quickly to Release 4 makes sense. Migrating to Release 4 often is easier than upgrading current Release 3 servers. If you plan to upgrade your Release 3 servers to the latest
Notes Release 3 software, consider migrating to Notes Release 4 instead. Notes 4 servers can coexist with Notes 3 servers and clients without problems, and should prove to be a more stable platform over time.
A Notes migration follows an eight-point plan similar to the eight-step plan for installing Notes described in Chapter 5, "Building a Deployment Plan," and Chapter 6, "Customizing Your Deployment Plan." The major difference between
migrating and an initial install is that, when migrating, you upgrade your applications after installing Notes software, instead of developing applications before installing. Each of the steps that you followed during an initial installation should be
redone during a migration. The eight steps in a migration plan are as follows:
The following sections discuss each of these steps in detail. You also should review the chapters in Part II of this book, "Planning Your Notes Installation," before carrying out a migration.
A Notes migration team resembles a Notes installation team in many regards. The political aspects of migrating are far less important than those involved in initial installation, so the choice of project leader isn't quite as important. You also don't
need a Notes evangelist as part of the migration team. A migration team should include the following members:
Large organizations may have both a Notes Release 3 administrative team and a separate migration team at one time. Medium or small organizations most likely will need to carry out the migration to Release 4 while maintaining the current Release 3
network. Consider adding some temporary personnel to the administrative team to help handle the load during the migration period. This method can benefit your organization by getting your organization up to speed with Release 4 faster than otherwise
possible.
The first thing you need to assess are your current plans regarding any Release 3 installations in progress. Consider whether it's worth the time to continue installing Release 3 software and then migrate it to Release 4 in the near future. In some
cases, switching to Release 4 rather than continuing to install Release 3 software makes sense. Testing Release 4 in your environment before installing it may cause an unacceptable delay for some high-priority planned installations. But there is no other
reason to continue installing Release 3 software rather than switching to Release 4. Release 4 clients can access Release 3 servers. Release 4 servers can support both Release 3 clients and servers. Replication mail routing works correctly in a mixed
environment.
You also need to do a skills assessment as part of your migration planning, in order to develop a proper training plan. This step should be far easier than your initial Notes installation because all your users should be knowledgeable about Release 3
features and know how to operate a mouse in a graphical environment.
You also need to assess your current installed base of hardware and software. Follow the steps outlined in Chapter 7, "Determining Hardware and Software Needs," just as if you were installing Release 4 on brand new machines.
You need to train your administrators, application developers, and help desk personnel before you attempt to develop a comprehensive migration plan. Computer base training is sufficient for many of your support staff. You also can contact a training
organization if you want on-site training.
Notes Release 4 contains enhanced replication and new mail features that can alter your network topology. In particular, if you aren't already using a hub-and-spoke architecture or hierarchical naming, you should plan to convert now. Chapter 9,
"Designing Your Notes Network," contains all the details you need to consider when developing your naming schemes and network topologies, but here is a summary:
You also can bundle other tasks into your migration, such as changing your operating system.
The procedures that change when you migrate to Release 4 are those concerned with certifying users, changing names, and issuing cross certificates. The Administration Process handles many of the tasks that were done manually in the past. Although you
can register users and servers the same way as you did for Release 3, the Administration Process is designed to ease these tasks. You should update your standard operating procedure for handling employee terminations. Use the Administration Process to
delete users from database and server access control lists.
When handling employee terminations, be sure to check the Administration Request Database to see that the request to terminate the employee has been completed. When you delete a person record from the Name and Address Book, you must use the button Delete Person rather than the Delete key. Pressing the Delete key doesn't generate a request in the Administration Request Database.
Cross certificates now can be issued over the phone. This system eliminates the need to exchange any media or even to have your computers connected at the time cross certificates are issued. Other standard operating proceduressuch as backing up
servers, monitoring the Notes log, and restoring the Public Address Bookdon't change.
Following are the steps involved in upgrading a server:
The first step in upgrading your Notes network is to complete your planning. Before proceeding you should have a complete plan showing when all servers and clients will be upgraded. This plan should include all servers and clients that will be upgraded
in the first eight weeks of your migration.
Your migration implementation should proceed by upgrading your servers first, followed by your clients. By upgrading your servers first, you minimize impact on end users and decrease the amount of effort required to perform the migration. Notes Release
4 servers have tools available to help you update and migrate client machines. All Release 3 clients can access Release 4 databases on Release 4 servers. Users shouldn't notice that the server has been upgraded to Release 4 or that databases stored on that
server have been converted to Release 4 format.
You should develop a complete schedule for your servers and client upgrades. Client upgrades should be coordinated with your training schedule so that each end user receives training within 48 hours of his or her machine being upgraded. During the
initial install, you had a way of enforcing the requirement that users receive training before receiving Release 4 on their machines. You could refuse to issue an ID until they received their training. You no longer have this option if users already have
their IDs, so you have to rely on persuasion to get users into training. Release 4 is just different enough that users should receive some training before you begin to upgrade applications to use new Release 4 features.
Before installing any hardware or software, you should upgrade your test environment to Release 4. Test out a representative sample of your applications. Do a complete test of all third-party products (such as mail gateways and application-development
tools) that you use in your environment. Contact the company from which you purchased your products for Release 4 upgrades. After you have tested all your gateways and a representative sample of your applications, you are ready to proceed with installing
hardware and software.
In addition, test a sampling of your other applications, such as noncritical work flow and simple discussion databases. You should accomplish your testing before migrating a single production server to Release 4.
You should have a complete list of your hardware and software upgrades required from Chapter 9, "Designing Your Notes Network." Now is the time to upgrade hardware on your server machines. You can begin to upgrade hardware on client machines
as the machines become available. Try to upgrade the hardware and software on any laptops as they become available during the migration. After you have upgraded the hardware, update the operating system and network software on your server machines.
Before upgrading any server, perform a complete backup. Back up all Notes databases, as well as DESKTOP.DSK; NOTES.INI; all IDs, including server, user, and certifier IDs; the Public Address Book (NAMES.NSF); the Notes log (LOG.NSF); and the server's
mailbox (MAIL.BOX). In addition to these databases, back up any Notes-supplied templates that you have customized, and all directory link files and database redirection files.
The first server upgrade differs from other server upgrades in that you need to upgrade the Public Address Book on the first server where you install Release 4. You should upgrade the Public Address Book on only one server, and then replicate these
changes to other Release 4 servers.
After upgrading the hardware, operating system, and networking software on a server and completing a backup, install the Notes Release 4 software. Install the software in the same directories as the Release 3 files, following the steps in Chapter 10,
"Installing and Configuring Notes Servers."
After you have completed the install and setup for Notes Release 4, manually copy any customized views or forms from your Release 3 template to your Release 4 template. You should never completely replace a Release 4 design element. Instead, modify
existing elements, using your Release 3 customizations as a guide. For example, if you modified the people view in the Public Address Book, don't copy the customized Release 3 people view directly into the Release 4 Address Book. Instead, take each of your
customizations, including a selection formula, and so on, and enter that information into the existing people view in your Release 4 Address Book. When updating forms, copy your customized fields directly into Release 4 templates rather than copying the
entire Release 3 form. You also may need to edit the NOTES.INI file. You can use any of the methods outlined in Chapter 13, "Administrative Tools," for editing the Release 4 NOTES.INI file.
CAUTION
Never copy a Release 3 NOTES.INI file directly over a Notes 4 INI file.
The one file you shouldn't need to update is your desktop. DESKTOP.DSK isn't changed during the install program.
The first server you upgrade should be a hub server. By upgrading a hub server first, you minimize problems when replicating your new Public Address Book. You also avoid potential problems with end users acccessing a Release 4 server before youve
tested it in your production environment.
Upgrade the Public Address Book in each domain. Notes automatically replicates the changes as you install other Release 4 servers. If you are using cascaded address books, upgrade each of these databases on the first Release 4 server.
You upgrade an address book with these tasks:
To upgrade the Public Address Book, follow these steps:
Do these tasks during off-peak hours, as updating all the documents in a large view can take some time. You may need to perform this step over a period of several days or weeks, depending on the size of your Address Book.
Before converting the file format of the Address Book, make sure that you have enough disk space to run Compact. In order to run on a database you need to have at least enough free disk space to hold a duplicate copy of the database being compacted.
Because Address Books can be quite large, you should double-check before running Compact on your Address Book.
You don't need to rebuild view indexes manually, as Notes automatically updates the indexes when it is restarted. After completing the update of your Address Book, you can take advantage of new replication features that allow you to replicate databases
more often with less system overhead. After you have converted all the servers in a hub-and-spoke topology, update the connection documents of the spoke servers to use the pull-push replication method. For more information on pull-push replication, see
Chapter 15, "Administering Replication."
Follow the steps outlined in Chapter 13, "Administrative Tools," to set up statistics and events monitoring. You should configure statistics and events monitoring before continuing to upgrade other Notes servers. Statistics and events
monitoring enables you to monitor your network more easily as you migrate servers. Because Release 4 statistics and events monitoring is superior to Release 3 in several ways (see Chapter 13 for details), you should upgrade immediately.
In Release 3, statistics and events monitoring documents were stored in the Public Address Book. In Release 4 they are stored in the Statistics and Events Database. As you no longer need them, you can delete the statistics and events monitoring
documents from the Public Address Book by following these steps:
Make sure that you have upgraded all views on the Public Address Book before deleting the statistics and events documents from the database. In addition, you will need to have configured the Administration Process on the server before you can delete
documents.
You don't need to copy your current statistics and events documents manually from the Public Address Book to the Statistics and Events Database. The Event server task does this the first time it is executed.
Repeat the process described earlier for upgrading servers, with the exception that you don't need to upgrade the Public Address Book the second time. After you have completed upgrading all servers in a hub-and-spoke topology, edit the connection
documents to use pull-push replication.
Actually, this step happens automatically the next time server runs the Compact program. The Compact program runs on a database every one-third of the purge interval in days. For example, if a database has a purge interval of 90 days, Compact runs on
that database every 30 days.
Databases that don't have an .NS3 extension will be converted to Release 4 file format. You can prevent your databases from being converted by changing the file name of the database from an .NSF extension to an .NS3 extension. (If you are going to
change the file name of your databases, make sure that you give your users an easy way to update their desktops.)
There really is no advantage to keeping a database stored on a Release 4 server in Release 3 format. Because of the hassle of changing a file name that requires users to update their desktops, you should go ahead and convert files to Release 4 format.
If you want to convert a database sooner, you can always run Compact from the server console on the database. For more information on Compact, see Chapter 13, "Administrative Tools."
Converting to Release 4 file format isn't a one-way street. You can revert to Release 3 file format by using the Compact routine. If you want to have a database revert to Release 3 format, enter this command on the server console:
Load Compact -R database name
Make a complete backup of every Notes client before proceeding with an upgrade. Back up NOTES.INI, DESKTOP.DSK, NAMES.NSF, all ID files, all local databases, directory links, and database redirection files, and any customized templates.
To install the Notes Release 4 workstation software, follow the steps outlined in Chapter 11, "Installing and Configuring Notes Clients." When you have completed the installation, restart the Notes workstation software. You may need to reenter
the setup information if you haven't installed Release 4 in the directory previously used by Release 3. Finally, to allow a user access to several Release 4 features, compact the desktop. To compact a user's desktop, follow these steps:
After you have compacted the user's database, he will be able to add and delete tabs from the workspace.
The Install program doesn't alter the user's desktop, personal address book, or customizations in the NOTES.INI file. The desktop file isn't touched at all until you manually compact it. Personal address books are automatically upgraded to use the new
Release 4 design template (PERNAMES.NTF). Laptops with outgoing mailboxes also overwrite the outgoing mailbox design template (MALBOX.NTF).
Although the design templates of the mailboxes are updated, the mailboxes themselves aren't automatically upgraded by the Install program. You must use the Convert server task to upgrade mailboxes stored on a server. Users can upgrade local copies of
address books, using a new agent stored in the design template for Release 4.
Complete your workstation upgrades for all workstations connected to a mail server before upgrading the mailboxes on the server.
The license types for many Release 3 clients will convert when upgrading to Release 4. The license type determines the features available to a user; the person document for each user must reflect the license type. An administrator needs to edit the
user's person document and enter the correct type of license in the Client License field. After the person document has replicated throughout the domain, each user should upgrade her license type by following these steps:
You should upgrade mailboxes only after all workstations have been upgraded to Release 4. Users who have customized their mailboxes will need to save these customizations and reapply them after conversion. Although preserving customizations for users
would be nice, no automated task exists for this purpose. To upgrade all mail databases on a server, you use the Mail Conversion utility provided with Release 4. To use the Convert Utility to upgrade mailboxes, perform the following procedure:
Tell Router Exit
Load Convert Mailbox.NSF STDNOTESMAIL MAIL4.NTF.
Load Convert Mail/*NSF STDNOTESMAIL MAIL4.NTF.
Load Convert -R Mail/*NSF STDNOTESMAIL MAIL4.NTF.
Load Convert -F MailList.TXT STDNOTESMAIL MAIL4.NTF.
Load ROUTER
The syntax of the Convert Utility is as follows:
Load CONVERT (-F) (-L) (-R) (-I) (-D) (-N) (FULLPATH) database file name (CurrentDesignTemplate) (NewDesignTemplate)
where CurrentDesignTemplate is the name of the template that a mail file must be using in order for it to be converted, and NewDesignTemplate specifies the name of the new template that will be used by the mail file.
All parameters except the file name of the mail database are optional. The following list describes the parameters:
Use the -L argument to create a list of mail files. Delete the users whose mail files shouldn't be converted. Using -L is normally faster than typing entries by hand, and avoids typos.
If you don't specify a current template and a new template, the Notes Design won't be upgraded to Release 4. You must always specify current template and new template when using the Convert Utility on mail files that aren't already using the Release 4 mail design template.
You need to upgrade only the primary mailbox for each user. If they maintain local replicas, all changes will propagate. Don't upgrade both a user's primary mail file (the mail file to which the router delivers mail) and replicas stored on workstations
or laptops. Documents may not appear in the correct folders if you convert both a primary mail database and its replica.
A user who has her primary mailbox on her local machine can upgrade to Release 4 by using an agent contained in the Release 4 mail design template. She must replace the design of the current mailbox so that it uses the new design template for mailboxes,
run the agent contained in the design, and then copy over any customized forms or views. The user who wants to convert her personal mailbox should follow these steps:
Figure 12.1.
Use the Replace Database Design dialog box to update the design of your mailbox.
After you convert a user's primary mailbox on a server to use the new Release 4 mailbox template, the user needs to replicate the new design element to any local replicas of her mailbox, and ensure that all design elements will replicate. To ensure that
all design elements replicate, follow these steps:
Alternatively, to maintain a Release 3 design of any local replicas, uncheck the Forms, Views, Etc. check box and the Agents check box.
After you have converted a server, workstation, department, or workgroup to Release 4, you can start to take advantage of Release 4 features. You can use some features if even a single server has been upgraded, while other features, such as Release 4
Mail, should be used only after you have converted an entire workgroup.
Notes Release 4 contains two key features that enable you to replicate data faster and with less administrative burden than in Release 3. Release 4 databases can have multiple replicators updating them at a single time. Also, field-level replication
reduces the amount of data that must be replicated. Replication is faster in a hub-and-spoke architecture, because Notes Release 4 doesn't scan the disk drive for new databases every time a replication starts, instead storing information on all databases
in memory.
These features combine to greatly enhance the speed of replication in a hub-and-spoke topology, where a hub may contain several thousand databases. You can configure the spokes to push changes to the hub rather than relying on the hub to pull changes
from a spoke. Because all the spokes can be pushing changes to a database at once, the amount of time it takes for a change to propagate is greatly reduced.
To take advantage of pull-push replication, you need to modify the connection documents for all spokes in your topology.
Chapter 13, "Administrative Tools," covers the Administration Process in detail. To set up the administrative process on a Notes server, follow these steps:
After you have the Administration Process up and running on a server, you can begin to convert your names.
You can potentially regain a considerable amount of disk space on a server by using the shared mail feature of Release 4. Shared mailboxes that have shared mail enabled store their messages in a single common database on the server. Messages addressed
to multiple recipients are stored a single time in the database. Several ways exist to configure shared mail; they are all discussed in Chapter 14, "Administering Notes Mail."
After you have upgraded your servers and clients to Release 4, you should certainly convert to hierarchical naming if you haven't done so already. The Administration Process greatly simplifies the burden of converting users and servers to hierarchical
naming. You should carefully design your naming scheme before proceeding. See Chapter 9, "Designing Your Notes Network," for details on developing a naming scheme for your users, servers, domains, and networks.
Before changing the name of a server or user, you need to carefully check the access control lists on other servers. This step is required in order to continue to have a functioning Notes network. If you change a server from flat to hierarchical naming,
you may no longer be able to replicate changes to or from the server.
The first thing you need to do is to ensure that there is a certified public key in the server document for all servers that will be upgraded to hierarchical naming. You should also ensure that there is a certified public key in the server document for
all administration servers. You can accomplish this by migrating the server to Notes Release 4 and letting the Administration Process run to completion. After the Administration Process is idle, reboot the server. This action will cause a certified public
key to be copied into a server document.
If you are having trouble using the Administration Process, make sure that you are starting the administration server before the workstation. If not, you need to shut down the workstation, start the server, and then restart the workstation. The Administration Process doesn't work if the server isn't started before the workstation.
Because the Administration Request Database will hold name-change requests for servers in your organization, you should control access to this database carefully. Only administrators who need to be involved in the conversion to hierarchical naming
should have access to this database. Carefully control depositor, editor, and author access to this database. Don't forget to give your local domain servers access to this database so that they can replicate requests.
After you have set up the access control list for your Administration Request Database, turn off ACL replication so that a change made at one workstation doesn't replicate to all. To turn off ACL replication, follow these steps:
Processing a renamed-server request causes the Administration Process to access several views and documents in the Public Address Book. Make sure that the index updater isn't running while the Administration Process is handling a rename-server request.
Your server's performance will be significantly lowered by contention between these two processes. To ensure maximum performance during a Rename Server command, follow these steps:
Tell Update Quit
Tell Router Quit
Tell Replica Quit
Tell ADMINP Process New
Load Update
Load Router
Load Replica
Push ServerName Names.nsfwhere ServerName is the name of the server running the Administration Process.
You can't convert a mail server using shared mail from flat to hierarchical naming. Doing so would prevent you from accessing the shared mail database. The shared mail database is encrypted using the flat ID file for the server. Before converting to
hierarchical naming, unlink all mail files. See Chapter 14, "Administering Notes Mail," for directions on unlinking shared mail files. Unlinking mail files takes at least a day to allow all messages to be purged from the shared mail file.
After you have completed the conversion to hierarchical naming, you can relink all mail files on the server.
Make sure that you have enough disk space to unlink mail files before attempting to convert to hierarchical naming.
Users and servers that have only their common names listed in a database or server access control list are assumed to have used the same organizational certificate as the server on which the database resides. If this isn't the case, users and servers no
longer can access the database or server that contains only their common names. When converting a server to hierarchical naming, you need to review all server access lists and database access lists on that server. Any common names should be converted to
their full hierarchical names before converting the server to hierarchical naming. Check off each of the following items:
Even when you take care to upgrade all access control lists, there will be a time during which Release 3 servers can't access a Release 4 server that has had its name upgraded to hierarchical naming. The Public Address Book must replicate throughout the
domain in order to reestablish this access.
When you are ready to proceed with your conversion to hierarchical naming, follow these steps:
To convert the first server to hierarchical naming, follow these steps:
After you have converted a single server to hierarchical naming, you can batch process the rest of the servers. All servers that will be certified using the same certificate can be processed at one time. To convert subsequent servers to hierarchical
naming, follow these steps:
Repeat this process for each set of servers that use a different certificate.
The Administration Process completes all the steps needed to convert your server names, including:
For more detail on how the Administration Process accomplishes its magic, see Chapter 13, "Administrative Tools."
After these requests have been processed by the Administration Process, you can begin the conversion of users to hierarchical naming. Once again, remember that you shouldn't change a user's common name at the same time that you are upgrading to
hierarchical naming. Changing a common name at the same time results in the user being unable to access databases for a brief period of time.
You can batch process all user names that will be certified using the same certifier ID file. To upgrade a group of users to hierarchical naming, follow these steps:
Repeat this process for each set of users in your organization.
You may not be able to wait until you have completed a complete migration of all users to Release 4 before beginning your conversion to hierarchical naming. Of course, it is highly recommended that you complete your migration to Release 4 before
converting to hierarchical naming because of the massive amount of effort saved with the use of the Administration Process. If this is impossible, keep in mind that access control lists for databases that have no replica on a Release 4 server won't be
updated. If you use a hub-and-spoke replication topology, you need only upgrade the hub server to Release 4. For every database on the hub server, specify an administration server. This strategy enables you to have all database ACLs updated by the
Administration Process. Changes to databases on the hub server will replicate to the Release 3 spokes.
Release 3 servers can't automatically upgrade users that contact them. Release 4 servers automatically upgrade a user's ID file when appropriate. If you want to upgrade user ID files by using the Administration Process, you should upgrade all mail
servers to Release 4 format. Because everyone accesses their mail server frequently, this scheme enables you to have their IDs upgraded automatically when they contact the mail server.
Check the Administration Request database several times a day while you are upgrading servers and users to hierarchical naming. The Administration Process creates response documents for all requests, indicating the current status of the request. If an
error has occurred, a red x appears next to the response document. Be sure to fix any errors in a timely manner to minimize disruption of your Notes network.
You should set up ACL monitor documents in the Statistics and Events database. This plan causes the Events task to mail any errors directly to your mailbox.
In addition to the Administration Request database, you need to monitor the Certification Log database (CERTLOG.NSF). Additional information on errors is recorded in the Certification Log database.
It is inevitable that for a period of time you will have some servers running Release 3 and some servers running Release 4. In addition, many organizations will end up with some users running Release 4 clients while other users are still running Release
3 clients. Lotus has planned ahead for these eventualities; you should have no problems in these environments if you don't break any of the following rules:
Three situations will arise during your migration for which Lotus has planned:
Release 3 workstations can't edit macros containing Release 4 features. Release 4 workstations, on the other hand, can edit either Release 3 or Release 4 macros. Macros in Release 3 format are stored in Release 3 format. If you alter a Release 3 macro
to include features from Release 4, the macro will be stored in Release 4 format and will no longer be editable by Release 3 workstations.
Full-text indexes aren't interoperable across releases. A Release 4 workstation can't access a Release 3 full-text index, and a Release 3 workstation can't access a Release 4 full-text index. Notes Release 4 can read but not update a Release 3 index.
During the migration, you may have some clients using Release 3 and some using Release 4. During this period of time, all databases should be maintained in Release 3 format. All updates to full-text indexes should be performed from Release 3 workstations.
Some features in Release 3 databases, such as navigators, don't work correctly when accessed from a Release 3 database. In general, a Release 3 database can't use special features from Release 4. In addition, large views or bitmaps stored in Release 4
databases may cause memory allocation problems in Release 3. The largest memory segment Release 3 can handle is 65,000 bytes.
If you are using a workstation that has both Release 3 and Release 4 installed, you may experience delays when opening databases. Each release of Notes needs to rebuild databases in its own format before using the database. In addition, if you are using
a workstation with both Release 3 and Release 4 installed, you shouldn't use the Release 4 Workspace Edit feature. Release 4 allows you to create and delete tabs on the workspace, but Release 3 always handles exactly six tabs. If you use the Release 4
feature to edit your desktop and then later try to access it using Release 3, Release 3 will try to rebuild the desktop, thinking that it is corrupted.
Clients using Release 4 mail should be careful when sending mail to Release 3 usersyet another reason why you should wait until all users have been upgraded to Release 4 before upgrading mail files. You can avoid these problems:
Release 4 OLE objects can't be used by a Release 3 user. If you need to share OLE objects, you must create them using Release 3. Release 4 can launch OLE objects created using a Release 3 workstation.
Several system databases received new design template names in Release 4. You must ensure that these design templates are replicated to all databases. You should avoid the situation where, for example, a Public Address Book on one server has the Release
4 template, and another server has a Release 3 template. This situation can cause your Notes 4 servers to be updated using the Notes 3 design. Avoid this situation by eliminating design updating or design replication. To turn off design updating, you
simply need to replicate the R4 template name to all R3 Address Books using the following method:
The next time these two databases replicate, the Release 3 database will inherit the STDR4PublicAddressBook template name from the Release 4 Address Book. The Release 3 design will no longer be updated because the Release 3 server doesn't have a copy of
this template. Instead, the design task on the Release 3 server simply generates an error indicating that it can't find the template.
You can also prevent servers from replicating design changes:
By severing the link that updates the design, you prevent the Release 4 design from being overwritten from the Release 3 database. When the Release 3 server is eventually upgraded to Release 4, be sure to go back and re-enable replication of design
changes.
Upgrade your servers before upgrading users. If you have users with a Release 4 workstation with access to a Release 3 server, the users must know exactly which features can and can't be used. The Release 3 server is unable to support all the features
accessible to the client when using a Release 4 workstation.
If you migrate users to Release 4 before you have migrated their mail server to Release 4, they can't use these features:
Don't use Release 4 workstations to edit formulas of databases stored on a Release 3 server. Any Release 4 functions included in the view won't be recognized by the Release 3 server. Generally the Release 3 server can build a view, although the actual
documents in the view probably won't match up with the ones that you wanted.
This chapter has discussed the why and how of migrating from Notes Release 3 to Release 4. Notes includes several tools to ease the transition to Release 4, such as
You should approach your migration with the same planning steps that you would use for an initial installation. Create a team, involve the entire organization, assess your hardware and software installation and needs, design your new Notes network, and
upgrade your servers, clients, and applications to Release 4.
Don't forget to train your administrative staff and end users before migrating to Release 4. There are enough new and changed features to justify the training expense. The Notes training is the one task that Lotus wasn't able to automate.
You also need to do exhaustive testing on your third-party products and mission-critical applications before migrating to Release 4.
With all the new tools included in Notes, migrating to Release 4 should be simpler than migrating from one Release 3 version to another. With a little bit of planning, you should be able to avoid all critical problems. Be sure to review Part II of this
book, "Planning Your Notes Installation," for a complete set of details to consider when installing or migrating Notes.