Microsoft would like us to think of Office 365, its hosted email and collaboration service, as “cloud”. And it is in many ways; you can even get all your email and Onedrive-stored documents direct from a web browser.

The truth though is that Microsoft has been careful not to disrupt its desktop Office software too much. Most users, in my experience, choose Office 365 in part because of its integration with Outlook, Word and Excel. You can install the software from the Office 365 portal, and open and save documents from Onedrive for Business.

Another part of the service is online chat and conferencing, for which you need the Skype for Business (formerly Lync) client on your PC.

There is an issue here though. Part of the attraction of “cloud” is that you do not have to manage software; but in the case of Office 365 you do have to manage the software that is installed on your PC. Microsoft’s investment in click-to-run installation has helped to simplify the setup, but under the covers it is as complex as ever.

Take the case of a small business I know, which was on the Office Midsize Business plan. Microsoft has retired this plan, so when it came to renewal time the customer had to change to a different plan. If they wanted to keep *all* the features of Midsize Business, including the Access database app, they could migrate to the Enterprise E3 plan – at £14.70 per month, nearly double the £7.80 per user/month for Midsized Business. On the other hand, they could migrate to the Business Premium plan for the same cost and, well, *nearly* the same features. The horrible details are here.

They didn’t use Access so Business Premium seemed OK. On the cloud side, the migration was straightforward. However, since Access was no longer included they had to remove and reinstall Office, as well as the Skype for Business client.

In this particular small business, most of the users needed some assistance with this operation. Unfortunately there is no single button to click that will remove the old Office and install the new one. You have to remove Office using Control Panel, then reinstall it from the Office 365 portal. Removing Office removes the old Skype for Business client, but putting it back means choosing a separate installation option in the portal, which most of them missed. One user somehow ended up with two versions of Office 2016 installed, neither of which worked properly. Office would not activate, reported an error, and offered to repair itself. This was not going to work, since it was the wrong version of Office.

Even when it goes smoothly, the business of removing Office and reinstalling both the desktop software and Skype for Business takes a long time, over an hour.

Overall, life in the Office 365 era is easier than it was in the days of 27 Office floppies, one or two of which were bound to be unreadable. Nevertheless, it is friction, and not fulfilling the seamless promise of cloud.

Microsoft’s Office 365, which provides hosted Exchange, SharePoint and other services, comes in a variety of flavours, some of which include a license to run desktop Office. In some cases it is even possible to mix and match plans. For example, you can have some of your users on Enterprise 1 (E1) (no desktop Office) and some on Enterprise 3 (E3) (includes desktop Office). It gets more awkward though if you want to switch between “families”: the small business family and the Enterprise family. A table here sets out which plans are eligible for switching.

But what if you do want to switch between families, for example to take advantage of the good value Office 365 Midsize Business, which gets you hosted services and desktop office for £9.80 or $15.00 per user/month, compared to E3 which costs £15.00 or $20.00 per user/month? There are some extra features in E3, like Exchange archiving and legal hold, but the cost saving is substantial.

The answer is that you have to switch manually. Microsoft helpfully remarks:

Switching plans manually involves purchasing a new plan, reassigning the licenses, and then cancelling your old plan … If you have a custom domain, you’ll have to remove it from Office 365 and then add it again after you’ve switched plans. This will require some downtime of your services. If you’re switching to a plan in a different service family, you’ll need to back up all of your company’s information before switching plans.

Put another way, you are pretty much on your own. In Active Directory terms (Microsoft’s directory service), it means a new directory and therefore a new cloud identity for all your users. Any other services linked to that directory, such as Intune for PC and device management, will also need replacing.

I helped a small business make this change, so here are a few notes from the field.

The first step is to create the new Office 365 site. You can use a trial and purchase licenses later. It cannot have the name as the old site, for obvious reasons. Every Office 365 is part of the onmicrosoft.com domain. If your old site is mydomain.onmicrosoft.com, you can call the new site mydomain1.onmicrosoft.com.

These onmicrosoft.com subdomains are useful, since they are not affected when you move the custom domain (eg mydomain.com) from one site to the other. You can still use the old onmicrosoft.com domain to access the old site.

Then set up the users. In this case the business is so small it can easily be done manually.

1. Migrating SharePoint

Moving a SharePoint document store from site to another is painful if you cannot do what you would normally do, that is, backup the content database and reattach to a different SharePoint site. Microsoft does not provide any bulk export feature, though you can write your own code. There are third-party migration tools like Sharegate which probably works fine, but for a very small business it is not cheap, starting at $995 for a one-year subscription to the “Lite” version.

I found a quick and dirty solution using an Azure virtual machine. Create an Azure VM running Server 2012 R2, log in using Remote Desktop and install the Desktop Experience. Then navigate to the old SharePoint site, add sites to trusted sites as necessary, and “Open in Explorer” to use WebDAV and view the documents in Windows Explorer. Copy all the documents to a local directory. Then connect to the new site and do the same in reverse.

Why Azure? The idea is to benefit from fast connectivity between Office 365 and Windows Azure. This worked well and the documents copied much more quickly than I could achieve when connecting from my own network.

You do lose document history using this technique. Further, all documents will now be “last modified” on the date the copy is made.

Timing is a problem. In order to minimise downtime, you want users to be able to keep working on the old site for as long as possible. However, during this time they might add or edit documents in SharePoint. I did two passes, once before the cut-off point to get the bulk of them copied, and once after, using Search in Explorer to identify the documents added or changed.

2. Migrating Exchange

Exchange migration is also tricky. Office 365 includes Exchange migration tools but they are designed for moves on-premise to Office 365, not for moving between families. It may be possible to make them work, though this official advice is not promising:

Since they are different service family, and we cannot use such as  Cutover migration to achieve this goal, we just can use export and import pst. Moreover, we cannot parallel 2 user accounts which have the same domain in both 2 tenants, so the service may be impacted. Sorry for the inconvenience.

This support person is suggesting using Outlook to move a mailbox by exporting and importing data. It is an ugly procedure, especially if you are trying to do this without involving the users much. You would have to impersonate each user, connect in Outlook, download the entire mailbox, export it, and then connect Outlook to the new mailbox and import.

I used a third-part cloud service, MigrationWiz, instead. This connects to each hosted Exchange using either impersonation (an Exchange feature which lets a user connect to a mailbox as if they were the mailbox owner) or a user with full control permission on all mailboxes, and copies all the items across.

Unlike Sharegate, MigrationWiz is priced per mailbox, at $11.99 each for a multi-pass license. This make it affordable for a business of any size.

I found MigrationWiz excellent. It was not entirely trouble-free and I got some time-out errors on my first attempt, but these may well be the fault of Office 365 itself. The user interface is good with plentiful statistics on how your migration is going. It did not create any duplicate items.

The worst thing about MigrationWiz is that you have to give your mailbox administrator credentials to a third-party. In some cases that might rule it out; but the company says:

Mailbox credentials are stored using AES encryption. Once credentials are submitted by either the administrator or end-user, the credentials cannot be retrieved or seen. The credentials are immediately purged from the system once you delete the corresponding configuration to which it is associated.

The company is based on Microsoft’s doorstep in Kirkland, Washington, and given how detrimental a security breach would be to the company’s reputation I figured that the risk is small.

3. Moving the domain

How do you move your company domain from one Office 365 account to another? MigrationWiz has a help document on this which is mostly helpful. You do have to accept some email downtime. I did what MigrationWiz suggests, which is to point the MX records for the custom domain at an unreachable site, temporarily. You can do this in the middle of the night or at the weekend to minimise the inconvenience.

However, I did not like this advice:

Delete all users, contacts and groups from the source Office 365 account.  This step is important to ensure that no object reference the domain.  Just removing the email address from objects is not sufficient.

I am cautious and wanted to keep the old site intact with its mailboxes until the business says it is confident that everything has been transferred successfully. Therefore I tried doing this the way Microsoft suggests:

• Remove all references to the custom domain from the old site. This includes making sure it is not the default domain, and removing any email addresses which reference it, not only from users, but also from mail-enabled groups or resources in Exchange. If you have a public web site using the custom domain, remove it from there as well.
• Remove the custom domain from the old site.
• Add the custom domain to the new site, verify it, and amend the DNS records as needed.

I was successful and moved the custom domain without having to delete the old user accounts.

4. Reconfiguring Outlook

What happens when users now run Outlook? Might Outlook prompt for the new password (presuming you changed user passwords), connect to the new site, and upload the contents of its old mailbox to the new mailbox, duplicating the work of MigrationWiz and leaving users with two of everything?

Apparently it does not do this, though my recommendation is to delete the old Outlook profile (mail applet in control panel) and create a new one before attempting to connect to the new account. Outlook will have to re-download the mailbox, though it is smart about downloading new and recent emails first.

5. Migrating Intune

If you also use Intune, you have to set up a new Intune account linked to the new Office 365 domain (even if the custom domain is the same), and remove PCs from the old Intune account. You do this by “retiring” them in the Intune portal. This is meant to set up a scheduled task on the client PCs which removes the Intune client. Then you can join the client PC to the new Intune account by running the Intune client setup from the Intune portal.

If this does not work, and the client PC remains stubbornly enrolled to the old Intune account, you can use this procedure:

1. Open an admin command prompt
2. Navigate to C:\Program Files\Microsoft\OnlineManagement\Common
3. Run "ProvisioningUtil /UninstallAgents /WindowsIntune"

It will create a scheduled task and shortly uninstall all the agents. (be patient)

For more information on removing the Intune client, see http://douwevanderuit.wordpress.com/2014/01/30/removing-windows-intune-client/.

There is a downside to this. Imagine you have used Intune to suppress some update that breaks something on your client PCs. When the Intune client is removed, the PC will revert to using Microsoft Update until it is re-enrolled in the new Intune. During that time it may install the update you were trying to suppress.

Note:

On one machine we got this error when reinstalling the Intune client:

“The software cannot be installed. The account certificate must be in the same folder as the installer, or the user account must already be authorized to use Windows Intune”

My guess is that the new Intune setup is fining the old Intune account certificate and therefore failing. The fix is to download the setup manually from the Intune Admin portal. This setup is a zip which includes the account certificate (the .exe download is different and does not include the certificate – you must use the zip setup). This setup ran successfully and rejoined the machine to Intune.

6. Why is this necessary?

Everything worked and while it is not entirely pain-free, with relatively little inconvenience for the users.

However, how difficult would it be for Microsoft to adapt its “switch plans” wizard to accommodate this kind of switch, subject to the proviso that anything which depends on a feature that does not exist in the target plan would not be migrated?

In fact, I am not sure why it is necessary to have so many plans at all. Why not have it so that you can mix and match licenses from any plan?

I have been working with a small business migrating its email to Office 365. The task seems simple enough: migrate just over 100 mailboxes from on-premise Exchange 2007. There is no requirement for a hybrid deployment, so the normal approach is a cutover migration. You run a script on Exchange at the Office 365 end which sucks up all the mailboxes, creating user accounts as it goes. Once the mailboxes are synched, the script (called a migration batch) synchronises the mailboxes every 24 hours. You then change the MX (DNS) records so that mail goes to Office 365, get users to log on to the new mailboxes, and decommission the on-premise Exchange.

It sounds straightforward, and I am sure works fine with small mailboxes and just a few of them. It is meant to work for up to 1000 mailboxes though, so I did not think just 100 would cause any problems.

Here is what I discovered.

First, we soon ran into problems. The migration batch seems remarkably slow, partly thanks to using an ADSL connection (fast download but slow upload) but even slower than that would suggest. Some mailboxes report “Failed” for a variety of reasons, the most common being that they simply stop synching for no apparent reason, or in some cases never start synching. Here are some of the error messages:

• Error: MigrationPermanentException: Error: Job is poisoned, poison count = 6.
• Error: SyncTimeoutException: Email migration failed for this user because no email could be downloaded for 5 hours, 0 minutes.
• Error: MigrationPermanentException: Error: The job has not made progress since 28/07/2013 08:43:19. Job was picked up at 27/07/2013 17:11:15.

So what do you do if you get these errors?

My first observation is that documentation for cutover migration is thin. It makes little provision for anything going wrong. There are a few things (like avoiding messages over 25MB or hidden addresses in Exchange) but nothing about “job is poisoned”.

Another observation is that the Cutover Migration Batch is lacking in common-sense options. For example, with a slow-ish connection you might prefer to migrate only two or three mailboxes at a time, rather than then 16, which seems to be the fixed number.

I was also puzzled by the option to “Stop” a migration batch, which you can do using a toolbar button.

What are the consequences of stopping a batch? Can you stop it in the morning, and restart in the evening, to reduce bandwidth during the working day, for example? Or do bad things happen?

I headed for the support community. Unfortunately this is not too good either. There are a number of unfailingly polite Microsoft support people there, but they don’t seem all that well informed when it comes to the details of what can go wrong and there is a lot of reference to support articles that might or might not answer the question; or an initial response that doesn’t quite answer the question and then no satisfactory follow-up; or retreat to private messages which, judging from the public responses, are also not always helpful either.

After being told that it was OK to stop and restart a migration batch I tried it. It did not work well at all for me. I even got this lovely error message for a Room mailbox:

Error: ProvisioningFailedException: Couldn‎’t convert the mailbox because the mailbox "mailboxname" is already of the type "Room”

I had better success deleting the migration batch and creating a new one, which is easy because it remembers the connection settings from last time. Mailboxes in progress resumed where they left off, and even some failed mailboxes started synching again.

Still, the detail of this is not so important. Fundamentally, Office 365 seems to me a strong service at a reasonable price (though I like Exchange better than SharePoint), and Microsoft is pushing small businesses towards it so hard that it is becoming difficult to stay on Microsoft’s platform at all unless you migrate – the disappearance of Small Business Server with bundled Exchange makes a small deployment expensive.

This being the case, you would have thought Microsoft would put its best effort into the migration tools, which are critical not only for successful transition, but also as many people’s first impression of the service. I did not expect what look like immature tools with skimpy documentation and poor community support.

Is Microsoft struggling to scale the system quickly enough to meet demand?

In some ways this may actually be good for Microsoft partners who still have their traditional role of puzzling out these kinds of problems and making it easier for their customers.