Recently we came across a scenario where a business had increased in size and wished to move into two separate entities, and in doing so, wished to separate out their Office365 accounts so they could be under separate billing arrangements. Natively, Office365 does not support this functionality and you’ll need to rely heavily on a third party service or tool to get this done the right way. Fortunately for us, after trialling MessageOps Office365 Exchange Migration Tool we came across another cloud based product that would suit our client perfectly. MigrationWiz.
Essentially what this product enables you to do is to migrate from any type of mailbox to any type of mailbox. Be that POP3, IMAP, Exchange, Google Apps, Office365 or some other scenario. You can also backup mailboxes to Amazon S3 where all mail, contacts and calendar items get transferred as individual .txt files grouped into their respective folder hierarchies. Frankly for the price, this tool is excellent and was an absolute saviour. However we did encounter some problems when moving forward but these problems were solely Office365 problems so we hope these suggestions might solve your issues if you’re having them too!
- First step in the migration process is to setup a brand new Office365 account in trial mode with your reseller (for example, Telstra Apps Marketplace) or with Microsoft themselves so that you have a platform where you are going to transition data into. When you sign up, you’ll need to choose a UPN domain for use with the new account such as greengrassexample.onmicrosoft.com (we’re imaging our current onmicrosoft domain is timberflooringexample.onmicrosoft.com)
- Once you have that account fully signed up and running in trial mode, let’s begin to add the users that we wish to migrate over to it. Now in the first company we have:
And it turns out that when we grow the company, Fred, Sally and Rachel are going to be headed over to Second Company. So let’s go ahead and create firstname.lastname@example.org, bill@, rachel@. Here you can choose to use the same passwords if you like so that it’s easier once they’ve fully migrated, the user’s phones and other mobile devices will sync right up again. This won’t allow Microsoft Outlook profiles to sync right up again, they’re a little more complex, but we will get to that.
- Now once we have created all the users in the new Office365 Admin Center and assigned them a licence, we need to consider our migration timeframe moving forward. In our cases, it has been best to run this over a weekend incase you run into difficulties such as we did the very first time, and so as to minimise the amount of email the customer may be receiving at their end that will be queued. Once we have a timeframe in place, we need to drop our TTL at the DNS provider for the MX records for greengrassexample.com.au down to 300 (or less if your provider supports it). This should be left like that for a few days until mail servers around the globe have had time to update the TTL’s that they’re relying upon. This will ensure that we have minimal to no (preferrably no) lost mail during the migration.
- During this time we can setup all our new users in MigrationWiz and specify source and destination server details being Office365. These must be an account that can use impersonation to authenticate. This will ensure that we achieve maximum migration speed. So let’s go ahead an add our users.
- After we have added our three users, it should look similar to the following. Note that in our old Office365 tenant, these users are still using their mailboxes on a day to day basis so we leave their usernames as what they would have been using before. Our source emails are such like email@example.com and our destination emails are firstname.lastname@example.org.
- Another important step is selecting impersonation which will speed up migration time if not enabled by default. It’s under your project’s advanced settings page.
- Let’s go ahead and start a pre-stage migration after we have verified credentials. This will essentially copy all mail from source to destination up to 30 days old so that this can run for a couple of days and ‘prime up’ our destination mailboxes ready for a full (delta) migration. You need to understand that a full migration is a delta migration, which is what we will run once we have flicked over the MX records, domain etc to the new account. This will copy new mail but will not copy changes the users have made to existing mail such as deletes, moving into folders, flags and follow ups and the likes. As long as this is communicated to your client early on in the piece everything should run smoothly for you.
- Once pre-stage migration is complete and was successful for all of our users, and it’s on Friday evening, let’s switch over our MX records. Currently greengrassexample.com.au is pointing towards greengrassexample-com-au.mail.protection.outlook.com. We’re going to go ahead and change that to nullroutable.greengrassexample.com.au. The benefit of this is that nullroutable doesn’t point to any IP address, so a lookup on that subdomain will fail (if it does point to something in your case for some reason then please choose something else). This means that mailservers will queue mail on their end for typically 24 hours, sometimes 48 hours as well before they will drop the mail and send an NDR back to the original sender.
- Now once this is done, we can begin detaching the domain from our old Office365 account. Our first step in this process is making sure we remove the email address for greengrassexample.com.au from all users that have this as a primary email, or an email alias on their mailbox, plus all shared mailboxes that may use this email as well. For mailboxes and shared mailboxes the process is essentially the same, find the mailbox, edit the mailbox, head to Email Address and change the primary address/remove the greengrassexample.com.au address. To change primary address, select one not in bold, hit the edit button and select the checkbox to make it the users primary email.
- Once we’ve done that, we can head into Domains within the Office365 admin center, change our primary domain (if we need to) and then remove the existing domain that was used so that we can attach it to the new account. Sometimes here is where you can run into difficulties which is where we faced problems on our first migration batch. The issue was with an old shared mailbox still retaining the UPN so we ended up migrating the mailbox and then deleting it completely. More in the next step.
- So what to do if we can’t remove the domain and it sits on a screen saying ‘Sorry this is taking longer than expected’ and asks us to leave the window open? Well after about 5.5hrs on the phone to Microsoft Support through remote GoToMeeting sessions, we were able to come to the conclusion that we had found and needed to remove an offending mailbox completely. This article explains brilliantly how to find those offending users.
- Now that the domain is removed, let’s add it into our brand new Office365 account and set it as default. We will need to modify the domain that we use in terms of the TXT records, specifically the Microsoft verification record MS=xxxxxxxx so we can add and verify the new domain. (Note that we are in the new admin center here for this screenshot)
- During the course of adding the new domain to Office365 it will ask you if you want to flick your users email addresses over to the new domain. Best to select ‘yes’ here so that you don’t have to go and do it manually for each user. At the same time, change your MX records to point back to greengrassexample-com-au.mail.protection.outlook.com so that mail starts flowing through again.
- Now we need to perform a full (delta) migration of all remaining mail using MigrationWiz. Because we have changed the usernames on both sides, let’s edit our existing users and make sure our source username uses the format @timberflooringexample.onmicrosoft.com (old UPN) and the destination username uses our full domain @greengrassexample.com.au seeing as we have changed that over now.
- At this point you will need to go around and reconfigure the Outlook profile for all your users as they will still be attempting to sync up with the old account. Best option here is to create a brand new profile in Microsoft Outlook and add the new Exchange address to it using the user’s email and password. If the user’s local Office365 was licenced with their old account, they will likely have to sign in again to activate it again or if you moved say from Business Essentials to Business Premium, you’ll have to re-run the install of Microsoft Office otherwise you’ll get a ‘product does not match licence’ error when you try to activate. Don’t forget to use a handy tool like NK2Edit to assist you in transferring over autocomplete addresses from the old profile and back them up just to be sure.
- Now in your old timberflooringexample.onmicrosoft.com realm you can convert the user’s mailboxes to shared mailboxes (so they don’t take up an active licence) and you can also rename them to show that they’re an archive. This is for ‘just in case’ purposes so that they’re not deleted just yet.