Mail Migration FAQs
At Kolaco, we have considerable experience migrating customers from Legacy and LAN based e-mail systems to client server messaging platforms such as Lotus Notes/Domino, and Microsoft Exchange. The following is a sample of questions that need to be considered when a migration from your current mail system(s). This is not a complete list, however, it should provide insight into the types of questions that need to be asked when attempting a mail migration project.
Reasons for change
In many organizations, the current mail system may be working with little or no problems. Why then, should a new system be deployed, or “If it’s not broke, don’t fix it”. There are many reasons to deploy a new system, other than it is broken. Below a few examples:
Is my current system Y2K compliant?
Since the current mail platform works, why would you assume that it will break on a specific date. We all know that this is not a real question, applications in nearly any area are susceptible to Y2K failure and mail systems are no exception. Microsoft Mail and certain versions of cc:Mail, for example, are not Y2K compliant.
Does my business need additional services from its e-mail system?
There are many examples of additional services, from simple discussion groups to complex web and workflow enabled data integration applications.
Does my company need a messaging system that will work on multiple platforms?
Many companies use Windows based PC’s. Many more companies use those same Windows PC’s, plus Macintosh’s, Unix workstations, and OS/2 systems. Using a messaging system that supports all of these can ease the burden of support of these disparate mail clients or environments.
My developers want standards based mail, but legal must have secured and encrypted mail.
This is a common problem in the age of the Internet. A solution can be created using several different mail systems, but a better solution may be a single messaging architecture that supports the entire user community, thus greatly simplifying the overall architecture, and creating a more reliable system.
Assessment
Once the decision has been made to deploy a new messaging system, assessment of the current environment and requirements are critical success factors. Without this information, an implementation may be complete, but lack several features/functions required and not be considered a success.
What does my user community want in a new messaging system?
To make an informed decision about what messaging system to deploy, the user community’s needs should be accumulated, additionally determine what other functions would they like.
Will the current mail system coexist with the new system?
Not only is it important for the new messaging system to meet the requirements of the users, but both systems need to have the ability to coexist during the deployment timeframe.
What other applications or processes use the current mail systems.
It is quite common for a company to use the mail system in ways in which it was not originally intended. An example of this is a company that has a time reporting application that uses the mail system as the transport mechanism.
Is the current mail system stable?
The easy answer is “Of course not, that is why we are moving!” but that is an oversimplification. The current system may not be as stable as required, but it may be as stable as is possible. Conversely, if the system is unstable in its implementation, the ability of the new messaging system to reliably communicate with the legacy system becomes much more troublesome.
Implementation and support
These two areas may not appear to be related. Proper planning for support of the new messaging system needs to be completed in conjunction with the architecture and implementation planning process.
How reliable does the new system need to be?
As electronic mail becomes a more mission critical application, the reliability of the system architecture becomes extremely important. If the current system is unavailable for hours a day, then hours a week for the new system would seem to be a large improvement, but may not be adequate for your users. If what is required is twenty-four hour a day, 100% available messaging services, then there may be a need to significantly change the network infrastructure, and possibly the support infrastructure.
Does the support staff have the ability to provide the required level of support?
Once the decisions about the reliability are made, the support organization must be capable of providing a level of service equal to the goals for reliability. If not, the goals will not be met.
How will all the new client software be installed?
In many software application deployments, the largest portion of the costs are associated with physically installing the software. Proper planning for software deployment can minimize the costs of these tasks, and/or greatly ease the complexity of the deployment process.
How will my users be trained on this new software?
Another of the oft-overlooked costs associated with the deployment of a new software application are the costs of training the users. Using alternative training methods to educate the user community can reduce the costs of training, and create a reusable resource for training new users in the future.
Kolaco, Inc.
88 East Main Street, Suite 300H
Mendham, NJ 07945
P 973.984.3000
sales@kolaco.com |
|
| |