I’m here to provide you a quick but thorough overview of the tenant migration process, and hopefully this will answer the majority of your questions.
The core issue is that the same domain name cannot exist really in two different accounts at the same time. The examples we have on the screen, Microsoft or Google Workplace are just two of those examples, but you can use this on any hosted email system that doesn’t allow you to have multiple domains attached to multiple accounts.
If you’re migrating between different services like Office 365 to Zoho, Google Workplace to Office 365, you absolutely do not need a tenant migration. Tenant migration is only applicable when you have a domain on one hosted vendor and you want to move to another account on that same hosted vendor and have your domain name attached there. We don’t copy, move or migrate any of your existing data from one tenant to another. You should use a tool like the Titans Migration wiz or if you’re doing Office 365, use the Microsoft Cross Tenant Migration tool.
The service that we provide is a place where all of the email is queued from.
When you click delete on your existing tenant all the way through to when you want that email delivered to your new tenant, a tenant can be offline from anywhere between four and 40 hours. We would say the typical migration time is around 8 hours, but that can be dependent on a whole bunch of different factors, time of day or things that are going on in those particular systems, but anywhere between four and 8 hours is probably a good estimation for how long it takes from when one domain name is deleted to where it can be reconnected to the other tenant.
Microsoft’s own guide to Migration, say you should point it to unreachable.example.com, but they say you might be sending non delivery reports basically called NDRs and that you should be using some sort of MX record backup service, and that’s exactly what we provide. We are that backup service to queue your emails and because of this, senders will not be notified of NDRs.
They won’t know that the domain is being migrated. As far as they are concerned, the message has been delivered and no errors will be sent to them. For you, the person who’s going to be doing the migration, what we are going to provide to you is a real time view of your message queue. You’ll be able to see the message logs. You’ll see feedback inside of the interface to know that your messages are being queued and also the ability for you to DQ those messages when it comes time to deliver them to your new tenant and when you’re delivering them to the new tenant.
If for some reason the emails are rejected by the new tenant when you make the switch, we have an exclusive feature called Message Replay and what that does is it gives you another opportunity to deliver those email messages to the inbox. I’ll give you a specific use case. We had a client who was migrating one tenant to another tenant on Office 365.
It was a merger, the newly acquired company. Their email format was first initial-last name, but the acquiring party’s email addresses were first name.last name. For some reason, the first initial last name was not created on the new tenant, and when they tried delivering their email, all of those emails got rejected. In a typical scenario, those messages that get 500 or permanently rejected would be lost. But with our exclusive message replay feature, those messages still remain accessible to you and they can be re-delivered.
We also don’t have a limitation for the number of messages that we are going to be receiving. So this is not a volume based service because we know that if all things go well, messages will be on our system for four to six to eight hours, and if things go badly, they’ll be here for 40 hours, but we don’t need to queue them for weeks or months. We know that eventually those cues are going to get despooled, and we can reuse that space for a different customer.
We support a number of different migration options. One is called Migration MX, and that’s the method that maybe 99% of the customer base follows. And that is where you have an MX record that accepts all of your emails. You don’t need to define any of your email addresses inside of the system. We’ll just queue everything.
This is a contrast on Migration forwarding. You need to have your one to one mapping of your existing email addresses to your new email addresses for the destination. And the destination server could be the default email address. Microsoft provides this or G suite provides this and we can forward from your existing domain name to this email address. The pro is that it has a zero downtime so you can do a migration. Emails will continue to run.
The pon is that you do need to map each one of the addresses and aliases on a one to one basis, and if emails are not mapped correctly, they will get rejected. We also support a hybrid migration, which is a blend between MX and Email Forwarding. The reason the primary use case we see on this is some organizations want to make sure that email addresses like support@domain or sales or info don’t go down, especially if they are multinational. So we can define a certain number of email addresses that will function like email forwarding, and the rest of them will continue to work like Migration MX.
In one specific use case, their support email was forwarded. We then forwarded it off to their Zendesk email address, so support@domain continued to work and from Zendesk, they were continuing to be able to respond to tickets, and all of the other emails were sitting there inside of the backup MX until they were ready to have those delivered to their new tenant, we publish a pretty comprehensive guide at support.tenantmigration.com. But really the overview is you’re going to be changing your MX record.
You’re going to allow our system to queue those messages for you, and when you are ready to accept those emails, you need to make sure that you’ve whitelisted our IPs on the receiving server. So on your Office 365, you’ll go in and you’ll create an enhanced connector. Once that has been created, you can feel pretty secure at allowing us to release the emails and deliver those to your inbox. And we have a fairly comprehensive guide on support.tenantmigration.com.
I often get asked, why should I use your service versus doing it myself? And for us, here is the bottom line. If you go to somewhere like DigitalOcean and you build your own backup MX service, we think that the pro on that is going to be that it’s going to cost you about $5 in hard costs, but we think that it’s going to take somewhere between 2-4 hours for your setup and validating of the system. When you do this, you are going to have to rely on the fact that you can have no technical support versus where we have 24×7 and you’re not going to have message replay.
You will probably not have a web interface for logs or queue management, and you’re going to either be doing an email forwarding or an MX, but you’re not going to be able to do a hybrid.
It’s definitely less expensive.
But again, no message replay. There’s no admin interface, no support for your migration, whereas we provide you complete visibility and the tools to be able to understand when your messages are being queued and how to release them. What our system requires is that you have access to be able to change the MX record, and then you should also have admin access to your email server so that we can whitelist those IPs. The reason that the IPs need to be whitelisted is because we are effectively acting as a man-in-the-middle and we will break DMARC and those emails will get rejected if the target email server doesn’t know our IP addresses.
And again, there’s comprehensive documentation on how to configure that.
Inside of our tool, there’s an admin interface that will help you to determine what your MX record is to manage your filtering rules and to manage the destinations server. We will also provide you the ability to have a color coded message log. Blue messages are good. Blue is cued. Green are fantastic because they’re delivered and black messages mean that there was some sort of error in delivering those messages to you.
These queue logs are real time, so as soon as you start doing your migration and you’ve changed your MX record, you can go through the process of going into the logs and it will show you exactly what’s sitting inside of there. If you need to, you can go down to a single message and you can look at the contents of a single message. You can retry that message. You can delete it out of your queue or you can bounce it as in send an NDR to the recipient or to the original sender.
You can also download the email in EML format, and you have a visual interface to be able to control your queue as well as a detailed message log that tells you a trace of every message, every action that we tried to do on those messages, all of our delivery attempts, and it’s really ideal for debugging.
We are GDPR compliant. We have a SOC 2 Type 1. There is a deletion of all of your records as soon as you close the account, the data centers that you can use are in the USA or in Europe, and in Europe, it’s in Frankfurt and everything is inside of AWS.
We see this as a self service product. You can just go to tenantmigration.com, sign up for an account. If you have multiple accounts, we can provide you a discount. If you would like to become a partner.
If you’re an MSP or are you going to be doing multiple migrations, we can help you with that. We have migration guides and 24×7 live technical support. Now I’m going to give you an overview of the interface.