Migration projects often arise because of mergers, acquisitions, or divestments. If you are thinking of initiating a migration or are in the process of it, an Office 365 to Office 365 migration may have you at a loss for where to even begin. Luckily, such a migration isn’t as complicated as it seems.
Migrating from O365 to O365 is different from migrating from another platform into O365 in some significant ways, so you’ll need to understand the process before embarking on a migration project.
In this guide, we’ll be looking at everything you need to know for an O365 to O365 migration.
Office 365 is now very mature in the market and lots of businesses have been using it for a long time. In the natural business cycle companies merge with, or acquire, other companies, or divest of business units that set up on their own. As a result of this we are now seeing a lot of Office 365 to Office 365 migration projects.
For example Company A (which is on O365) acquires Company B (also on O365) and they want to integrate all the IT systems. Or Company C (on O365) divests of a business unit that becomes Company D (sets up on O365) and there is a requirement to migrate the users, data and domains for Company D into their own tenant.
You might think that as both entities are on the same platform – i.e. O365 – that Microsoft could just flick a switch in the background and everything is migrated. Unfortunately, this is not the case. Migrating from one O365 tenant to another is a complete migration project in the same way as if you were migrating your domains, users, mailboxes and file content from on-premise systems to O365.
The more services that you are using in O365 (email, SharePoint, OneDrive, Teams), the more there is to migrate and the bigger and more complex the project is.
There is an additional and very important complication which makes an O365 to O365 migration harder than an on-premise to O365 migration – the migrating domain(s) can only exist in one O365 tenant at a time.
If you are currently using mydomain.com in O365 tenant A, and want to migrate this domain, mailboxes and users into O365 tenant B, then before you can add the domain to tenant B you need to remove or rename all objects (e.g. mailboxes, user accounts, O365 Groups etc) using that domain from tenant A, then remove the domain from tenant A, wait for the O365 platform to recognise the domain isn’t associated with any tenant, and only then can you add it to tenant B and create objects on that domain.
For migrating the domains, mailboxes and users we use a tool (SkyKick) which creates the users and mailboxes in the target tenant using place holder names (i.e. not using the migrating domain), and copies over mailbox content while the users are still working on the source tenant. At cut-over time all the objects on the source tenant are re-named so as not to reference the migrating domain, the domain is removed and then added to the target tenant. At this point the objects (e.g. users, mailboxes) with placeholder names are renamed to exactly the same names they had in the source tenant.
Once the mailboxes (email@example.com) exist in the target tenant, they can start receiving new inbound mail (to add to the migrated mail). During the period that the domain was being removed from the source tenant and added to the target tenant there was no firstname.lastname@example.org mailbox in O365, and so any mails sent here will not be delivered and the sender will receive a Non Delivery Receipt (NDR) from O365. This period is typically 1-3 hours.
For some businesses this may be acceptable, for others it is not.
Fortunately, this can be mitigated by routing the email via another solution that can queue the mail during this period, for example Mimecast. In this case email is routed to Mimecast and then to O365, and just before cutover Mimecast is set to queue the mail – so it receives and stores the inbound mail. No mail is lost and no non-delivery receipts are sent. Once the domain has been added to the target tenant, the queued mail is released and flows into the mailbox along with any other new email.
We have discussed above how you can migrate the domain(s), mailboxes and users, but what about any other O365 content that you may wish to migrate? It is possible to migrate the SharePoint and OneDrive content with full fidelity and there are a number of tools available to help with this. However, at the time of writing there are no tools that are capable of migrating the Teams set up and content with full fidelity because Microsoft haven’t made the APIs available for this yet.
We deliver these projects by creating the same structures in the target tenant that exist in the source tenant, doing an initial copy of the data, getting the client to test access controls and data integrity, and then doing a delta sync of the content before cutover.
Migrating this content has to complete at around the same time that the mail migration does so that the users can access everything in the new O365 tenant. This is another difference with an O365 to O365 migration – everything has to go live in the target tenant at the same time.
Once the migration is complete and all your users are happily working in the same O365 tenant, what do you do about the one you have just migrated out of?
You can keep the data in the source tenant (that you have just migrated out of) for as long as you like, by keeping the necessary O365 licensing in place. Remember you haven’t moved the data to the new tenant, you have copied it. Once you remove the O365 licenses, all the data will be deleted within 30 days.
O365 to O365 migrations are becoming common place, and just require a bit more thought and planning that then original migration into O365 will have taken.
We have delivered lots of these projects, so if you’d like to know more, please contact us for a discussion with one of our O365 Specialists.Contact Us