Welcome Red Plane
My company is in the process of rebranding, and with that comes a new name: Red Plane.
Whilst it is straight forward enough to add an additional domain to Office 365, update the user accounts to use the new domain as a default, and register 2 email addresses as routable this doesn’t get around the SharePoint Urls that will still be on a hostname that relates to my old company “SharePointStudio.sharepoint.com”. Unfortunately there is no way to change this.
For a lot of companies they may have a large SharePoint implementation and it just isn’t worth the effort of moving everything over from one tenancy to another, but in my case I don’t have that much in there, so I have nothing to lose really… just my email mailboxes.
I have decided to keep this blog post simple and will consider the scenario where ADFS is not involved. In fact, in my real scenario I am using ADFS in the original tenancy, but will not be in the new tenancy. At least not for now.
What we want to achieve
To allow us to migrate our user mailboxes with as little disruption as possible I have come up with the following steps:
- Create the new tenancy in Office 365
- Import and verify your new domain
- Configure User and Mailboxes in the new Tenancy
- Connect the new mailbox to outlook and test mail routing works properly
- Create External Mail Contacts in the original tenancy
- Set up Mail Redirect rules in the original tenancy
- Test emails to the original address (SharePoint Studio Tenant) get routed to the new address (Red Plane Tenant)
- Export to .pst all content from the original mailbox
- Import .pst to the new mailbox
- If necessary, copy the Calendar items from the original mailbox to the new one
- Check everything is working and routing as necessary
- Remove the original mailbox from Outlook
The next steps
Those steps are all well and good if you intend to maintain the two tenancies and two sets of Exchange Online licenses until you feel you can “turn off” the old email addresses, which may be never and is a total waste of money. So, we really need a mechanism to configure the old domain in the new tenancy and then set up a secondary email address for our users in the new domain.
Unfortunately this isn’t as easy as it sounds. This would require us to remove ALL uses of our domain in the original tenancy so that we can remove it, then remove it, then add it into the new tenancy. Now, if you have ever tried to extract a domain, especially a primary domain from Office365 it is a LOT of work and will probably take a heck of a long time and frustration to do it. There will also be a period of time where email will get bounced when sent to the original email address as it will no longer be routable when removed from our user mailboxes.
In this scenario what we need to do is implement a intermediary mail server than can do the mail redirection whilst we close down the original tenancy, free up the domain name and can import it into the new tenancy. This could take the form of a temporary Exchange Server (either on-premise or in Azure) or, as in my case a cheap web host that offers mailboxes and redirects will do the trick. Here’s the steps I took:
- Create mail forward rules in the external mail provider (eg. forward firstname.lastname@example.org to email@example.com)
- Create a new catchall (@) MX record in DNS for the external mail servers with a higher priority (lower number) than the Office365 MX records
Now, your email should be forwarding from your old addresses to your new addresses without going through Office365 – and hopefully performing as well as the mail redirect rules within Exchange!
The Final Steps
Now that we have removed reliance on the old tenancy we can delete it, assuming all other data has been migrated out! When it has gone and we have been able to bring the original domain into the new tenancy and set up secondary email addresses for our users we can remove the forwarding rules and reset the default MX record to point to Office 365 again.
A word about Licenses
The steps outlined above work great for making a migration from one tenancy to another, but there is a big question around the license implications.
In my scenario I have less than 25 users so I am able to run an E3 trial for 30 days and use that time to make my migration. I can then terminate my original licenses (a Service Request to Microsoft is a good way to do this) and then re-purchase them in the new tenancy. This should allow for the minimum amount of cross over and cost.
In environments with more than 25 users this isn’t feasible and there may be some cost implication in running dual licenses for a short period of time while you make the transition. In this case I would highly recommend contacting Microsoft and asking them if there is any way they can help you out. I have not asked the question, as I didn’t need to, but you could ask if they would give you a months “grace” while you make your transition. If not then you will be working your timing so that you perform your migration right at the end of a billing period so that you have the minimum amount of time between the two sets of licenses.
As with anything Microsoft, the most complex topic is probably licensing!!