5 questions to ponder before you upgrade your company’s email server

If your company is like most, you've already got an email system in place, but there will doubtless come a time when you’re considering upgrading it. In this article, we’ve got some questions to help you decide whether you actually need to upgrade now – or whether you can save any expense and wait until a later date.

Here are five points you should consider before you open your wallet:

Just because it's old doesn't mean it's broken. Unlike physical assets, software doesn't crumble and rust over time. Don't let yourself be forced onto the upgrade treadmill. And even though something is newer, that doesn't mean you need it right now – especially for a mature product category like email servers. Of course, older versions may not have the security, stability, and even simple bug fixes that newer versions offer.

What's the return on investment? An upgrade can be a major expense. In addition to the cost of new software licenses, it often means beefing up hardware, taking time to test and roll out the new products, training staff, and migrating data. What will the impact be on all the stakeholders in the process, from end users to administrators? You'll likely have to justify the up-front costs, perhaps by finding savings associated with site and server consolidations, improved licensing terms, better scalability, and reduced maintenance requirements. Work up a cost grid comparing your current expenses with the upgrade.

What resources will your IT team need to commit? Don't forget to assess pain points, such as the time it will take to get comfortable with new infrastructure requirements.

What tools are available to help? If an in-place upgrade isn't possible, what kind of tools will your vendor provide to validate configuration of the new environment and to migrate your existing mailboxes, distribution lists, and shared content to the new system? What kind of support is available? Consider third-party tools that can ease the process, too. What's your fall-back strategy if something goes wrong?

Trade-offs? An inline upgrade offers a quick path for a time and resource-limited transition team. If something goes wrong, however, you won't have the deployment flexibility and cleaner rollback that an incremental pace allows. An incremental migration path that allows for a period of coexistence is more conservative than a rip-and-replace strategy, but you should still make a plan to deal with the coexistence of users, messaging, and public folders in two different systems.