The service checklist is a tool tha

The service checklist is a tool that you use to drive the entire process. The list should record what services are provided by the host, who the customers of each service are, and which software package provides each service.
Spreadsheets are an excellent way to maintain such information. The biggest benefit of maintaining this information in electronic form is that it can be easily shared both within the team and with customers. Making the file accessible via the web is better than mailing it to individuals, because the web version can be rapidly updated. People will always see the latest updates.2 However, the web is a pull mechanism. People won’t seek it out on their own. You can include the URL in every email about the project, but that will not guarantee that it gets read. It’s a good idea to announce any significant updates.
Double-check your plans by having a review meeting with key representatives of the affected community. Walk them through the plan, step by step, asking for people to verify your assumptions. It is most effective to begin the process with a meeting and then use email for updates, possibly having another face-to-face meeting only at key points in the process.
Including the customers as part of the decision and planning processes gives them a feeling of participation and control. Customers are invested in the outcome and become part of the team, which generally leads to a more positive experience for them and a better relationship between the SA and business units. Sharing dependency and status information with customers on the web and via email helps to maintain the working relationship.
A machine may be dedicated to providing a single service, or it may provide many services. Either way, many software packages may be involved in providing the complete service.
Usually, each service is directly related to a single software package. Sometimes a service is related to multiple packages, such as a calendar server that relies on an LDAP server. Document all of these interdependencies in the checklist.
It is also important to determine the key customers relying on various services. These customers may be directly relying on a service, using the service itself, or they may indirectly rely on the service, interacting with services that rely on another service for data or input. If they are people, they should be included in the process or at least notified that the process is happening. If other machines are dependent on the services, users of those machines should be included.
Often, you will find a service with no direct or indirect customers, and the service can be eliminated. These are always happy moments, but be careful: You might find the dependency after the service no longer exists. Consider having the service in a ready-to-run but dormant state so that it is easy to bring up, if necessary. Make sure that you document why the service is there but not running, so that it gets cleaned up next time through, if it has not been reenabled by then. The best place for this documentation is in one of the configuration files that will be edited to reenable the service.