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?