However the last migration or upgrade you performed was probably a little easier; the requirements were different then, and there was dramatically less data than today. The move from Exchange 2003 to 2007 was mostly about the new 64 bit hardware required, but the move to Exchange 2010 is often about the volume of data instead.
The future... if we actually had an endless supply of dilithium crystals or flux capacitors, gadgets like floating skateboards and Tricoders might be more common. But sadly they're not; so the only real prediction I can make for the future (that's relevant to this blog post anyway) is that Microsoft are planning to release a new version of their Exchange Server software every three years. We should be seeing the next version towards the end of next year, currently being called Exchange 15.
Like Christmas, it feels like new versions of core server software come round far too quickly, especially such valuable services like Microsoft Exchange. We've previously mentioned the lengthy procurement cycles that keep such services a constant version behind before, which generated some good feedback and discussion; many Exchange admins told me those delays adversely impact their own deployment plans, which is intensely frustrating for them and often forces their migration project into the red.
So, rather than roll out the ubiquitous predictions for 2012; I'm going to suggest that in the absence of 1.21 Gigawatts you can take a stab at future-proofing your Exchange environment now, so you're not left thinking in future -
"I'm migrating again. Surely not? Didn't I just finish the last upgrade?"
As your users make merry with the disk space allocated to the Exchange Stores, their mailboxes have grown and grown, you're probably wondering how you're going to move several Terabytes of data to the new Exchange platform; but, more importantly wondering when you might have to do this again. The short-term nature of IT and the constant cycle of upgrades and migrations means you may have to answer those question sooner than you expected.
One simple solution that future-proofs your migration and upgrade strategy is to deal with the data now by augmenting your on-premise Exchange with a Cloud based email management solution. Using this Cloud based email management solution is simple; the elastic and scalable nature of the Cloud lets you 'dump' your oversize email stores into a secure, scalable, flexible and resilient solution that will grow with you, but at the same time allow the users to have direct access to that email data through Outlook as though it was still on Exchange.
Now here's the part of plan we don't talk about very much, but one that provides a great degree of flexibility. When the next migration or upgrade comes around, or if you want to move from one platform to another, having already dealt with the data means your core email service i.e. Exchange, can be anywhere or anything. Upgrade, downgrade, move to Office 365 and back again, migrate some users or all users, the choice is yours; Augmenting Exchange with the cloud means you're not tied to any one solution or version, both today and next year when it's time to upgrade again.
Microsoft, and in fact Mimecast, are desperate to get you all off the old versions of Exchange, away from those Exchange 2000 or 2003 boxes that are still out there, but for so many the upgrade path stops at Exchange 2007. I began to wonder why this is, and after a quick unofficial straw poll I found a pattern emerging.
Mimecast recently commissioned Loudhouse, an independent research consultancy to take a look at the Exchange Migration situation. The research tells us that there is a mass migration of Microsoft Exchange Servers going on right now. At Mimecast we call this 'The Great Email Migration' and some interesting facts and figures have been discovered.
Underneath the headline research figures there is a lot going on that struck me as interesting if not perplexing and clearly frustrating; I'm often talking to CIOs and IT Managers about their email infrastructure and recently their plans to migrate to the next version of Microsoft Exchange Server; I'm always assuming they're planning to upgrade and migrate to Exchange 2010 or Office 365, but I'm hearing more and more choosing to stay a version behind on Exchange 2007, but not for want of trying.
Firstly I noticed that upgrade plans for Exchange have been in the pipeline for quite a long time. Many people tell me they were planning to upgrade from 2000/2003 versions to Exchange to 2007 pretty much as soon as they heard about the new release. But given the scale of the upgrade the project took them longer to budget and plan for, most blame their own internal and overly complex procurement process; whereby a non-technical procurement employee veto's or delays the project for trivial reasons.
Secondly, I've heard quite a few mentions of a "patch-and-pray" mentality to upgrades. Let me be clear, there is only so long this kind of support process lasts before your Exchange Admin is facing a late night and lost weekend due to some sort of failure, and that's the last thing we want. At some point the CIO has to admit the business and the users have outgrown their email environment and it's time to look elsewhere; but this overly cautious approach, akin to the "if it ain't broke don't fix it" method, means you'll never be close to the latest version. Fear of change, hesitation and caution are the enemy of new technology.
All of this frustrating behavior adds up to significant delays; delays that leave your IT project plans looking like the airport departures board during a heavy snow storm. You know you'll get there in the end, but the wait is agonizing and you would do almost anything just to "get on with it."
A permanent cycle of delays means your Exchange environment could always be stuck a version behind. Given that Microsoft plan to release a new version of Exchange every three years, I'm always concerned when I hear of project life-cycles that are even longer; how can you possibly take longer to deploy the platform, than it took the vendor to write the software in the first place? Don't answer that I already know how; project scope, evaluation, planning, more planning, more evaluation, procurement, re-scoping, procurement, deployment planning, re-scoping, procurement, and so on. Initial project evaluation to final deployment for Exchange 2007 could have taken so long, that Microsoft have released Exchange 2010 in the meantime. And so the cycle continues.
Breaking the upgrade cycle is something I've written about before; now is the time. Seriously, Exchange 2010 is worth the effort, especially if you're still floundering about with old versions like 2000 and 2003.
Looking at Exchange 2010?
What are some of those features?
What's been a real focus for Exchange 2010 is to directly enable the email user to do more, and to do it more easily.
Free/busy is a great example of where Exchange 2010 is a great improvement.
Free/busy is a well known feature to users worldwide, however in older versions of Exchange it's nearly impossible to see the free/busy status of another user in another organization. Exchange 2007 enabled cross-forest free/busy lookup to another Exchange organization if the pre-requisites were in place. But it was still just free/busy.
Exchange 2010 builds significanly to that, by allowing organizations to federate with each other, and exchange free/busy information with detail, controlled by the administrators.
Assuming that partner companies in different forests and different networks need to see each other, Microsoft will broker and vouch for the authenticity of the relationship via a hosted service, and then enable each company to dial up or down the detail visible to the OTHER companies recipients.
Free/busy is akin to the availability feature of Lync or OCS when it comes to making the decision to make a call or not. Seeing another companies free/busy massively empowers users to work faster and more efficiently.
Another big step forward is MailTips with Exchange 2010 Outlook Web App and Outlook 2010.
MailTips enables the person emailing to see the Out of Office of the recipients before they send the mail. This eliminates that frustrating workflow associated with sending a mail again after thinking it was dealt with.
Managing availability between organisations and MailTips are just two of the many new productivity features available in Exchange 2010 which truly reclaim minutes in the information workers day. Help your people be more effective with Exchange 2010.
Migration on the other hand, isn't always easy... so we've produced a series of webinars and how to guides to help you migrate in the Migration Readiness Kit (registration required).
According to the report, “The potential loss of data is at the top of the list with more than half (52%) of the companies mentioning this.”
Last week Mimecast announced the results of their Great Email Migration research, conducted by Loudhouse Research. Loudhouse surveyed 500 IT decision makers in the US, UK and South Africa and asked them about their email migration plans.
Companies are right to be concerned at the possibility of data loss. Infrastructure which is in flux opens companies up to be vulnerable to data loss, due to bad process, unmanaged configuration change and/or bad discipline. How can companies possible hope to mitigate these kinds of risk.
It is an old axiom that failing to plan is tantamount to planning to fail. In this context, planning should be a formal activity of every migration project, with a formal and on-going deliverable known as the migration plan.
Migration plans are only as good as the effort put into them and the accuracy of the scope which they are fed by. Accurate quantification of source environments, labs which approximate live environments, and a sample of representative user data are all prerequisites to ensuring a migration plan has the best possible chance of succeeding. In fairness, most of us don’t migrate for a living, so it’s not unreasonable to expect not knowing where to start. Here we will offer two suggestions:
Follow the military approach to planning by starting with the end goal in mind, and working backwards through every objective until the base understanding of the requirement is defined, without knowing how to solve every objective or process requirement. The end goal must be a clearly defined business or technical requirement. Follow up by adding process planning for each stage, known or unknown, and add technology choices last, so that technology becomes the enabler to the process, and not the other way around.
Migrations are epitomised by environments in flux. Flux is risky and is mitigates by process, planning and management. Migration planning as an on-going exercise as well as a living document is a foundation stone in the on-going exercise to mitigating on-going risk.