Having a well-thought change strategy and performance roadmap will ensure your Office 365 CLoud experience is a great one.
Some companies who have a managed IT infrastructure will want their self hosted and Corporately-Opened office 365 Tenant to put into play their processes and practices as the previous tenant might be overly customized and not reflective of what they currently represent.
In such a case, they will need to migrate operation and licenses to the new Tenant. They will also need to maintain their custom domain during this switch. Achieving that is now the subject of concern.
The most common migration which requires a different ISP with Microsoft or vice versa has laid down procedures on how to achieve them. But this Office 365 – Office 365 Migration is one that requires wit and strategy to achieve as so many things can go wrong not limited to Data Loss and email rerouting, to name a few.
I have taken the pleasure from my many weeks of supporting office 365 to throw in my opinion on how best to achieve this feat;
See the needed steps below in achieving this process;
Make a PST Backup of your emails from the old tenant
The first thing before any major migration exercise is to have a fail-safe backup of necessary and vital data as so many things can go wrong during a migration batch which could lead to data loss. Having things backed up ll save a lot of memos being sent out later on.
Creating a backup of email exchange is key when doing a cross tenant migration preferably in PST format so we can import them easily after the switch.
Create a new trial tenant to be used newly by your organization
This is the time we create a new tenant from scratch, putting into effect our processes and practices, laying down organization best practices and themes.
NB: You will have to go with a different company prefix from the old tenant
Create a corresponding .onmicrosoft.com account for the users on the new tenant
This is the stage where you create a corresponding user account for use within your organization relying on the default <company prefix>.onmicrosoft.com provision so you can have a mailbox to import backed up data to.
Get a trial subscription that has exchange attached for the users
The subscription you will go for needs to have Exchange as a service so the user accounts you are creating will have a mailbox to house your imported emails
Use this link to get an Office 365 E3 Trial License for your organization to see the features and addons you have access to.
Remove the domain from the old tenant
This is the stage where after all have been backed up and new provisions made, you now disconnect your custom domain from the old tenant and proceed to add it to the newly created Office 365 Tenant.
You will experience a service downtime during this process as email exchange will be hindered through office 365 until you redirect the traffic by adding the domain on your newly created Tenant.
Emails get queued up for 24hours after which they get bounced back to the sending server with a Non-Delivery Report (NDR).
Now add the domain to the new tenant (the process will be less stressful seeing the needed records are already on the DNS records for your domain)
This is where you Point your newly created tenant to your custom domain so that email delivery can be restored.
Use this link for information in achieving this.
Add the actual user UPN as an alias to their corresponding .onmicrosoft.com account
This is very important to ensure there are no duplicate entries or misconfiguration, adding an alias of the actual user UPN to the afore created corresponding .onmicrosoft.com accounts of each active user and turning that actual UPN to their primary email address.
For example, you created a new user on the new tenant as <username>@<company prefix>.onmicrosoft.com and now we added an alias of <Username>@<custom domain>.com to the same user account. We will then turn the <username>@<custom domain>.com to the primary email address from the Ofice 365 Admin center to revert the email flow to the mail account.
This process can be done for as many users as possible
Kindly be informed that the recommended periods for migrations of any sort are on low mail exchange periods (not peak periods) so as not to experience service downtime and service incidents.
If you find this article informative and worth the read, kindly drop a comment in the comment section and do well to share it within your circle.