Advice on a mail migration

@Sky-Knight Super helpful. Is it possible to batch migrate these mailboxes then?

I would leave the MX records in place, don't touch them.

Say out of the 200 I choose a batch of 30 at a time. migrate the mailboxes and reconfigure Outlook to 365? I'm just thinking though I don't know how I would point Outlook to 365 with the MX records still pointed towards GoDaddy.

Basically, as I was trying to say in my original post, to avoid pulling the trigger with an all or nothing cutover. That's why I was going to put in a forwarding rule for each mailbox so I won't have to change the MX records and the next day have a swarm of Outlook profiles to re-configure.
 
@neotechnet, Sadly, no... You have to use the user's login details to get direct IMAP access to each mailbox one at a time. I know... because I've done this a few times. :) Saving people from Godaddy is a full time job in and of itself, horrible platform. The Godaddy provided O365 being the worst possible place... you HAVE to use MigrationWiz for those, and mail WILL be down... because the same domain cannot be in O365 twice!
The domain issue shouldn't be an issue here since they are using IMAP rather than O365, but that is a very important point to keep in mind.
 
@Sky-Knight Super helpful. Is it possible to batch migrate these mailboxes then?

I would leave the MX records in place, don't touch them.

Say out of the 200 I choose a batch of 30 at a time. migrate the mailboxes and reconfigure Outlook to 365? I'm just thinking though I don't know how I would point Outlook to 365 with the MX records still pointed towards GoDaddy.

Basically, as I was trying to say in my original post, to avoid pulling the trigger with an all or nothing cutover. That's why I was going to put in a forwarding rule for each mailbox so I won't have to change the MX records and the next day have a swarm of Outlook profiles to re-configure.
You could do one domain at a time to split up the migration.
 
*Ahead of time, make sure you have access to their domains registrar account, AND especially their public DNS control panel if that's different from the registrar (as it should be).

*Ahead of time, ensure MX records are dialed down for their TTL

*Ahead of time, prepare your non mail related Office 365 domain records to save time

*Ahead of time, fill in your migration tool...be it O365 native migration tools, or 3rd party like BitTitan.

*Ahead of cutover weekend ,like a week ahead or more, "Pre-seed" their new O365 tenant with the majority of the email.

*Ahead of cutover weekend, deploy documents to end clients for them doing whatever part of your contract you have them doing. Don't forget smart phones.

*Cover weekend is now easy, flip the MX record, cutover workstations. While doing so, ensure delta passes are happening for straggler email coming from slow DNS updated mailservers to old mailbox. Keep punching delta passes over next several days after migration.

*Post migration after double checking all, clean up old DNS records, remove old mailboxes (after optional archiving).

As to which migration tools to use. For very small clients like onsies/twosies I'll just manually pull down to PST, and push that content up to new mailbox. For slightly larger than that I'll use O365s migration tools (which are very basic/simple). For bigger projects or clients that need better overwatching I'll use BitTitan (formerly known as MigrationWiz). This company was started by an Ex Microsoft guy (from the Exchange team). I used them waaaay back in the early days when it was just him. Has since grown and gotten popular. Several different migration products from just mailboxes to fancy tools you deploy to end workstations and it will push out the Office install and configure Outlook for them..does all the legwork.

Don't forget to think of things like *Distribution Groups, *Public folders like calendars, contacts, mail enabled folders. *Additional Alias on prior mailboxes On some clients...these last few items can actually take longer than the mailbox migration..there is a lot of documentation involved. *Any existing Sharepoint *What can be redone in teams/shared mailboxes/groups

*Don't forget to determine bandwidth of client
*Don't forget to determine health/condition of clients computers...sucks trying to install latest Office on ancient computers with tonsa adware/junkware, lack of Windows updates, old spindles, underhorsepowered rigs
 
Thanks @YeOldeStonecat that was very useful. With GoDaddy, don't they stop mailbox access once the MX records change? So once the MX records change you can't pull anymore email because the migration tool won't be able to connect anymore?
 
So the correct thing is to add a smart host in between and use MigWiz or similar.

Since on GoDaddy you won't have any admin way to move mailboxes. You will have to pretty much request creds from user.

This isn't difficult. Pre planning and setting expectations is where it's at.

Remember many people on GoDaddy will use the contacts and calendar. That will be manual move.

Lmk if you want to discuss this off forums. We could do full project and provide white label service.

File storage setup can be done as well
 
The domain issue shouldn't be an issue here since they are using IMAP rather than O365, but that is a very important point to keep in mind.

I wasn't referring to the domain being migrated, I was referring to the domain O365 is pulling from. You don't want it pulling from the MX record, because once it changes you lose the ability to do the deltas after the DNS cut over.

This process isn't hard, but goodness it can bury you in details. Stonecat, has a pretty solid list of suggestions there too.

And Marley1 is also correct, you're only getting email if you want to migrate the rest because the client is using Outlook, you get to manually import the PST files from all those stations as well.
 
I'm skimming this thread...short on time this weekend, but hopefully you're moving them to vanilla O365? And they're not going to use GoDaddys O365?

I've taken lots of o365 accounts from GoDaddy before, and moved them to our own o365 through our CSP.
GoDaddys o365 has a neutered admin panel...basically you can't effectively manage your client, you're stuck having to call GoDaddy eacy time Plus you don't get your own recurring revenue via your CSP.

In those cases we pull all mailboxes down to local PST (don't forget to slide the bar over to "ALL MAIL" on the time line in Outlooks cache mode setting)..so you download the entire mailbox.
In the meantime you're already prepped your clients tenant under your CSP, all the mailboxes there. And then you call GoDaddy support and tell them you're moving the client to a tenant under your CSP...and GoDaddy support has to delete the (ensure you're backed EVERYTHING all up before making this call).
You wait like..5 minutes..and then you can add the clients proper domain to the tenant under your CSP.

That's for GoDatto O365 to your own O365.
Probably easier with IMAP...guessing the regular import tools can do that just fine.
 
@neotechnet I'm going to suggest also talking with Adam (@Slaters Kustum Machines ) offline and perhaps arranging for him to backstop you or be available for consulting - pretty sure this is a big chunk of what he does day-to-day working with Lisa (@callthatgirl ). If you're charging enough, you should be able to cover whatever he might charge you; if you're not able to cover what he might charge you then you might be best off going back to the client and saying "I've consulted with some experts on doing migrations like this and been informed that I've quoted this far too low and am likely to run into problems. I'm going to have to revise that quote, in part so I can cover having those migration experts on call for assistance if anything goes wrong with these 200 mail migrations."
 
You can move the MX records and still access the old Go Daddy mailbox it just won't receive any new email once the records are pointed elsewhere.

I just did 45 mailboxes from GoDaddy to O365 I was able to get all user creds and use the built in migration tool. Once the majority was cut over we switch the MX records and move them from on Microsoft
Com domain to their final domain and run the migration once more to pick up anything that came in since the initial migration.

I also use another tool to make a local copy of each mailbox for safe keeping for 60 days but that is just because I am paranoid like that.

Sent from my SM-G870W using Tapatalk
 
@neotechnet I'm going to suggest also talking with Adam (@Slaters Kustum Machines ) offline and perhaps arranging for him to backstop you or be available for consulting - pretty sure this is a big chunk of what he does day-to-day working with Lisa (@callthatgirl ). If you're charging enough, you should be able to cover whatever he might charge you; if you're not able to cover what he might charge you then you might be best off going back to the client and saying "I've consulted with some experts on doing migrations like this and been informed that I've quoted this far too low and am likely to run into problems. I'm going to have to revise that quote, in part so I can cover having those migration experts on call for assistance if anything goes wrong with these 200 mail migrations."
He's_right_you_know.jpg
 
Thanks Putz that article is super helpful. If I'm reading those steps correctly the Microsoft tool will actually sync the mailboxes to 365 instead of just ingest and stop? If that's the case then a forward isn't needed since it will pull in email until the snyc it's stopped, according to what I'm reading.
Thats how I read it, it seems some of these functions work differently every time I perform one of these migrations. I've never done an IMAP Migration though. Doing a cutover Exchange 2007 - Office 365 Migration as we speak with about 30 mailboxes. Nevertheless data isnt lost, you still have the old IMAP accounts if someone claims they didnt receive something you can log in and check the old mailboxes.
 
Yes, the Microsoft tool will sync IMAP to the local mailboxes, it just needs a file with all the logins to do it. And you can have it sync on demand, or a schedule, all up to the admin.
 
To circle back on this I decided to Use BitTitan so it came so highly recommended but here is the hurdle.

It's cpanal imap mailboxes, pointing it to imap.secureserver.net won't work because that's only for workspace email. BT migration tool only works when I use the MX record which is mail.domain.com

Once the MX records change no more imap access which means I need to grab all the mailboxes before changing over the MX records.

Anyone have a workaround for this? That means I'll have to put in a mail forward on each mailbox to capture any email that comes in after the MX record change since the tool won't be able to connect.
 
Make an A record that points at the appropriate IP address, and use that. There's an IP out there somewhere with IMAP on it and those mailboxes, aim your DNS at it.
 
@Sky-Knight What about the IP address of the current mail record? I asked the GoDaddy tech this and he said that probably won't work, once it sees the mail record change it stops access to the imap mailboxes regardless if I'm using a DNS record or IP address of the godaddy cpanel server.
 
You got a Godaddy tech that's an utter idiot.

This really isn't that complicated. You have an email server online right now. It has an IP address, that IP address has services running on it. Those services operating on that address have nothing to do with the DNS records that tell the world where they are, nor do they have anything to do with the DNS records you'd need to point a domain at O365.

The only thing you do need, is the IP address that's got TCP 993 open on it (or TCP 143 if you're unencrypted). Those mailboxes are configured to be there based on the users listed in the CPanel. They won't go away until you remove them. CPanel isn't magic, it doesn't just turn things off. However, imap.whatever.com probably won't resolve to the correct place anymore. But that's not the same as the mailboxes and the associated service being disabled.
 
Back
Top