Future-proofing your Microsoft Exchange Upgrade & Migration Strategy

Back to the Future time machineThe 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?”

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.

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.








Cloud based continuity insures against migration mishaps

Exchange migrations tend to be complex.  Even smaller organizations running Small Business Server with less than 75 users, may take a week or more to plan, prepare and execute their email migration.

Any business that’s been through a migration at least once will remember that most of the migration effort was spent in planning. Otherwise they may remember the large mop-up operation and the time spent visiting desktops, recovering mail and rolling aspects of the migration backwards and forwards.

Data loss (what PSTs?), client upgrades and wrongly migrated data tend to come to mind when thinking about what can go wrong, as well as the mail server that crashed during the migration. During a migration a fair amount of change is introduced and additional processing is forced onto both the source and target Exchange platform. For an older platform at the limits of its lifespan or operational capacity, the extra overhead an email migration introduces may be the straw that breaks the camel’s back.

Cloud based email continuity may act as insurance in this regard by enabling client continuity and transactional continuity in case the migration wobbles or breaks. Let’s explore that in a bit more detail.

Migrations are heavily process driven. In order to migrate, a fair amount of surveying, planning, lab testing, etc need to be accomplished. It makes sense to use the desktop visit of the plan/survey component to introduce the agents required onto the desktops in order to make client continuity possible.

If an Exchange server in the source or the target organization were to fail during the migration, Outlook clients would be redirected to the cloud, with little or no disruption to service or – crucially – the user experience. This allows the outage to be addressed, mail flow and client mail service to be restored without the pressure of fighting two fires concurrently – ie, a broken environment and a broken migration.

Cloud based email continuity allows you to benefit from the scale of the cloud as a side effect of leveraging continuity in the cloud, provided of course your users have the  required network or internet connectivity to beat a path to the cloud.

In our day to day lives we’re generally quite comfortable accepting the argument of personal insurance, which guards us against any number of possible scenarios, such as breaking a leg while skiing, medical insurance, insurance against theft, and so on. All of these boil down to paying a small amount of money to a much larger entity and thereby being guaranteed the benefit of that entity’s scale and reach in the case of something unfortunate happening.

As the idea of cloud on demand becomes more pervasive, insuring your migration in the short term against loss of email continuity makes as much sense as taking out insurance on your car before you take it on the road.


Guest Post: BPOS to Office 365 Migration- Managing Without Mimecast (or not)

This is a Guest Post from a prolific blogger- Andy Kemp who has recently moved from a long standing customer of Mimecast and moved to a Microsoft Gold Partner UniTech, one that doesn’t have Mimecast in place but excited about what the toolset could do for them. One of the recent things he’s been tasked to do is their Migration from BPOS to Office365 both internally and for a number of serviced clients, and it’s interesting to see what life without Mimecast is like…

I have used Mimecast in the past for several reasons, email archiving, antivirus and malware protection, business continuity and compliance. These are all great reasons for using it but one other is for email migration. In the past when I have done system upgrades it has been pretty painless and stress free, moving from Exchange 2000 to Exchange 2003 for example.  However I think that now it is a completely different ball game as the Cloud is involved.  Moving to the Cloud is again relatively painless (just a different approach), at least from a technical point of view; politically it can be very stressful.  But moving from Cloud to Cloud for me at the moment is proving a bit of a headache.

I’m in the process of moving from BPOS to Office 365, and you would think that this would be a pretty straightforward migration moving from one Microsoft Online Service to another.  Is it straight forward? No! As a Microsoft Gold Partner and one of Microsoft’s Cloud Partners we were an early adopter of Office 365 closed beta and I was getting to like it more and more the more I used it throughout the testing.  However, when it came to domain migration I started to like it less.

The main issue for me migrating from BPOS to Office 365 is migrating your domains from one to the other. It can take anything up to 48hrs for the domain to be removed from BPOS and FOPE (Forefront Online Protection for Exchange) and only then can you add the domain in to Office 365. Then if something had gone amiss and you needed to remove the domain from Office 365 (like I had to) you would have to wait for anything up to 24hrs. It turned out my problem was that the domain had not been fully deleted from FOPE on the BPOS side.

All this time means that your email might well be unavailable (more than likely to be honest) and could have serious knock on affects to your business as email is now treated as one of the most common ways in which we communicate with our customers.

The main drive for using Mimecast in my previous place of employment was to ensure that email was accessible at all times, even when the in house exchange servers were unavailable. This could also mean when you are migrating from one service platform to another, and I would say that the same principle could be applied to a hosted email service.

Through using Mimecast you could very easily remove the headaches from your migration from one service to another as the continuity that Mimecast offers would provide you with email delivery during the process of the migration. You’ll effectively be using Mimecast as a pivot I guess for the transition.

My migration from BPOS to Office 365 has been in process for four days now.   Fortunately it is a non-critical domain I am testing with, but if this was a live email domain that I relied on for business my customers would be receiving NDRs for every email that is sent in to me.  This could well be avoided by having Mimecast in the equation as email would be delivered through Mimecast to your email service, regardless of it being on premise or hosted.

Moving email platforms is something that you do not want to do or need to do on a regular basis but if you do need to migrate your email then you will find that having something like Mimecast will make the migration even simpler and reduce your down time to a bare minimum if any.

Even if you are doing a simple email migration/upgrade you’re at risk.  Sure you will have a full backup of your server to revert back to if the migration/upgrade were to go pear-shaped –  if you did have to do a restore how long would that take you? An hour? A day? A week? I previously worked for a law firm and lawyers like to hold on to their emails; I had mail stores in the excess of 150GB, mailboxes of 15GB and over! The restoration of the email data would take about a full day (in the excess of 400GB Email data) but once the stores were restored I would then have to do an offline defrag on each mailstore db which could take anything up to 8 hrs per mail store meaning email would be down for a week. With Mimecast you could work on your exchange servers for that week and still be able to send and receive email, even by using outlook on the user’s desktop.

How long could your business survive with email down time? I guess in all honesty not very long.

I eventually got the domain working fully in Office 365 after a few calls to Microsoft and a few days of waiting! Email was being delivered to the right domain in the right service, finally!

It was a good learning curve (which is why we did it with a test domain) so when it comes to moving the live production email domain we know exactly what to do and what to expect. I am hoping that the production migration goes a bit more smoothly now! Mimecast will not take every risk out of email migration, but it will certainly give you a great level of continuity if you did face any problems when it comes to email migration.