As with any major network upgrade project, you should be sure to carefully plan ahead. Develop a written master plan and schedule for the migration and review it on a frequent basis. Some of the items to consider in a migration plan include
Back-out procedures—For any big changes you make on a particular server, be sure that you plan a method to back out of the change if it doesn't function as you expect. Always maintain up-to-date backups of key systems that can be used to make a full restoration without seriously impacting the user base.
Alternative plans—Sometimes there's more than one way to affect a solution to a problem. If you can make note of more than one method of accomplishing a particular task, such as the capability to schedule users or resources for the project, that flexibility will enable you to adapt to changes in the project schedule.
Assign users and resources carefully—When you make decisions about which personnel are going to be used to execute portions of the project plan, be sure to keep in mind the existing workload of the person and how participating in the upgrade migration plan will affect his or her job. Again, it is a good idea to have a backup person or backup resource you can use if unforeseen events limit a person's capabilities.
Nonproduction testing—Test your plan in a laboratory setting! Nothing is ever as it seems to be (there goes my existential thought). You should always test any network modification using all the possible usages you can think of before deploying changes to any network, whether it be one based on a Windows network, or another, such as NetWare, Unix, or Linux.
A well-defined team structure—There should be a migration team that has a designated leader and assigned duties and areas of responsibility for each member. Nothing makes executing a migration plan more difficult than personality conflicts that can arise from the nonspecific assignment of duties to team members.
No comments:
Post a Comment