Migration Into BPOS
These days, very few companies are starting their software deployments from scratch. Most already have the servers and applications up and running. One of the perceived barriers people may face is the task of migrating from an installed application base to a new model (SPS) or even a new vendor (Microsoft). How much of a barrier is this?
For businesses running Exchange, the task is negligible. Microsoft provides the free Microsoft Online (MSOL) migration tool, available through the Microsoft Online Services Administration Center Migration tab. You simply download the 32- or 64-bit version of the tool, install it on any and all client PCs, and run through the wizard. The administrator has to provide his or her credentials to get the ball rolling, select the Exchange mailboxes to migrate to Exchange Online, confirm the types of content to copy, and let it rip.
For those who run something besides Exchange, there are plenty of third-party options. For example, those using IMAP or POP services, such as AOL, Gmail, Hotmail, MSN, and so forth, may want to try Mailbox Migration from Migrationwiz.com. For quantities up to 5,000 accounts, the price is only $9.95 per mailbox. The company also offers a mailbox synchronization service for businesses that want to pilot Exchange Online and haven’t decided to take the full plunge yet.
As you might expect, there’s a migrator tool for practically any platform you could ask. Those with Lotus Notes or Novell Groupwise might try the tools from Quest Software. In fact, if you’re looking at migrating from Notes, register and check out Quest’s best practices brief. The bottom line is that migration onto BPOS is not complicated, and there’s no risk during the process because data is being replicated, not moved.
Migration Out of BPOS
The follow-up question you don’t hear Microsoft discuss much goes in the opposite direction. What if you’ve put your business on BPOS and want to migrate off of it? Are customers locked in? There are several scenarios in which reverse migration might be necessay, including if the company’s business model or ownership changes and the group needs to transition back to an on-premise Exchange server. The process is really just as simple as exporting a .PST file from Exchange Online and importing that file into the local mail server. With SharePoint, you would back up using SharePoint Designer, then move the data to the local SharePoint server. Again, third-party services can make this process even more painless.
We asked Microsoft why a company would want to abandon the cloud model after migrating to it and what reasons have businesses given for doing so. It seems that BPOS is so new, having only been on the market for less than a year, that few if any of those who have come onboard have left. Still, that doesn’t mean that customers aren’t moving cautiously. Many organizations are starting by putting one group or division on BPOS while the rest of the company remains on on-premises servers. If the trial goes well, then the whole business comes over to SPS. But it could go the other way. A company could move from “co-existence” back to being solely on-premises, and there have been organizations that have done this, although, according to Microsoft, it’s rare.
Why would a company move back? The number one reason given is administrative control. With BPOS, you lose some functionality. For example, in Exchange Online, there’s no more PowerShell, scripting, or similar nuances for tweaking. Microsoft takes care of all that on the back-end, and Microsoft’s goal is to strike a configuration that covers the needs of the majority. But if you’ve got Exchange tweaked and twisted with years of fine-tuning, you’d have to give that up when coming to BPOS. Similarly, third-party apps tied into Exchange won’t carry over. A faxing or VoIP product tied to Exchange will be stranded in the SPS move. For some, this may be a deal-breaker and leave them running on-site.