As MCT, I have a developer tenant for Office 365, and this year we are finally getting access to the Microsoft 365 function, i.e. Enterprise Mobility and Security. The disadvantage is that a new tenant is required and so a migration is pending. But at the same time, a lot of things have to be set up from scratch. I take the opportunity to write a series of blog posts directly from this.
In May 2015 I already wrote the article “Migration from one Office365 Tenant to another Office 365 Tenant“, but it describes the way very briefly, this time I will be a bit more precise.
Since I will write the article series in German and English, the screenshots on the online portals will be in English.
This article is mainly meant to give an impression of what there is to consider.
This is not a Blue-Print or Best-Practise. I am writing here my path on the journey I have chosen, with the pitfalls I have found. Since this is the first article of the journey, the processes and procedures may change in other articles of the series. Also, the approach does not fit all cases or company sizes. For some, a third-party solution might be a more suitable solution. This series of articles should be understood primarily as stimulation, as an inspiration for your own journey. Accordingly, I cannot give any warranty, guarantee or support for these methods. As always I try to answer questions through the comments, but they should be specific and not just be answered with a multi-page concept.
What’s important in something like this is a solid plan. I usually go there and start with a rough plan, which I work out more and more in detail. The tools I use for this are mostly a simple OneNote list, or a mindmap as you can see in the theme selected for the EUC-Meetup.
The first draft looks like this:
The advantage of this approach and the mind map method is that I can go as deeply as I like. I can also use this kind of topic areas to structure them according to rough dependencies. Of course, this is not a project plan in the true sense or a process, but I can use it for generating those.
For the exact dependencies and milestones, you should map the whole into a project plan or a process. Here is a short process picture I created from the draft. Here you can also think about the dependencies and show them.
The most important point is to create your own plan, with its dependencies and with a time schedule. You should also think about if there are other departments in the company that need to be involved. Examples of such units could be a works council or an IT security officer.
From my experience with various mail server migrations, I also know that it is worth to consider the mail flow separately. Nothing is more serious than when mails get lost. Especially you should pay attention to the DNS TTL and remember that changes here always take a while until they have “gotten around”.
I will describe the topic mail flow in detail in the article “Preparing the mail flow for the Office 365 migration”.
Topics to be considered
What should be considered for such a large project, or even for parts of it? Here are a few suggestions:
An emergency plan is always important for such a project. If anything goes wrong, how do I get back to work or get back to the initial state? In many cases, backup and good documentation can help here. But only if the backup can be restored and the documentation is correct. My tip, check it first, this will prevent problems in case of an emergency. However, this is often seen as selected insurance, you do not need it in most cases… but if you need it, then it is good to have it.
Ressourcen Do I have enough resources? Do I have the capacity for a few additional VMs in the datacenter? But not only these resources are important. More importantly, do I have enough skilled personnel and do they have the necessary know-how? Estimate the efforts (best with a buffer, drink coffee if everything goes smoothly is always an option) and check if you have enough employees in your team and if there are some for other tasks.
Another topic is licensing, do you have enough and are the procurement channels and budgets clarified?
rules and regulations
If you only want to use components from the series, or you are not sure if everything was done right in the last Office 365 implementation this is your chance to clean it up. Consider topics such as compliance, GDPR / DSVGO, commissioned data processing and more. Take the opportunity to do it right, if needed.
If you perform such a project, document it. If you document the individual steps correctly during the implementation, you will have an emergency manual directly in case it needs to be set up again. You also know directly what has been configured. Especially with certifications or audits, the question of how something has been configured often occurs.
The goal of my migration
For my purposes, I only want to migrate the email and OneDrive data of 3 users and some shared mailboxes. I also want to add other mail configuration, such as groups. Everything else I will rebuild. On the one hand to set it up cleanly with today’s knowledge, on the other hand, to write articles that are also relevant for new users of Microsoft 365.
Accordingly, I will not use any tools as they are normally used for migrations in a normal corporate environment. But maybe this will help one or two small companies, or even help large companies to get a feeling for the dimension.
The important thing about my migration path is that it influences the users in their ability to work. Also, a so-called “Big-Bang” migration is necessary. Parallel operation with both environments is not possible here without tools, because the same AD domain and the same mail domains are to be used. An additional complicating factor for me is that the mailboxes have accounts in several mail domains. With enough work, one could try to plan something here. But the most important reason why it only works with a big bang is that the integration between the mailboxes in different worlds does not work. So neither “Send as” nor check the calendar of the others. This is something I want to avoid in my scenario.
There are also some things that can cause problems. This is because there is no official way from Microsoft to change the tenant with an AD domain. The only official way there is to migrate an AD domain with an Office 365 environment to another AD domain with a different Office365 environment. The classic company takeover.
Things that can be particularly problematic or may fall by the wayside during migration:
- Office 365 groups cannot be migrated. Who knows a way, please let us know.
- Authorizations such as send as, send on behalf of, read authorization to mailboxes/calendars (May possible with some PowerShell magic)
- Outlook rules
- Public folders (Needs to be copied manual – mind the permissions)
- Remaining from old Exchange or SharePoint environments
- Azure AD settings on end-users’ computers
- Other Office365 tools, like ToDo, Teams, Planer needs to be considered
The problems I’m stumbling upon, I will address in this series. But as I said, I do it very much like the KISS approach (Keep it simple and stupid). Another article on this topic was published on Gooroo.io: Migration between two Office 365 tenants.