Help me move email accounts from Godaddy to our own server!
March 22, 2012 11:48 AM Subscribe
How do I move 100 or so GoDaddy email accounts to our server and not lose email and have minimal downtime?
A recent company policy requires that all email be archived. Unfortunately an affiliate branch of our company set up their email with their own domain name (don't ask) on GoDaddy.com years ago. This email and domain now needs to be on our servers so that it can be archived and managed better. (by the way, I'm the only IT person for this company, so give me some slack)
Details:
There are approximately 100 accounts and maybe 20 of them use Outlook (pop) and the rest all log in via godaddy's webmail client. Godaddy has no export function except for contacts/address books. Current email server is CommuniGate .
They are a sort-of important branch and can't afford a long downtime in regards to email, however I'm thinking it will take at least a couple of days.
My plan is to
1) Cut off their access to the existing godaddy accounts by changing the passwords
2) Move the email to the new accounts via IMAP (one client - 100 accounts..this will take time)
3) Change DNS / MX records to point to new server(s)
4) Provide access by pointing Outlook users to new server, and webmail users to new webmail page.
Downside: yes some email will be lost in between moving email with IMAP and opening it back up. I don't see a way around this.
I'd love to just make them use the existing company domain and give them all new email accounts and let them be responsible for moving their own data, but I don't see them either being agreeable to this, or even if I could force them to, see them moving their email themselves. If I could though, then I'd just cut off that domain at some point in the future.
Better solutions welcomed!
Cheers
A recent company policy requires that all email be archived. Unfortunately an affiliate branch of our company set up their email with their own domain name (don't ask) on GoDaddy.com years ago. This email and domain now needs to be on our servers so that it can be archived and managed better. (by the way, I'm the only IT person for this company, so give me some slack)
Details:
There are approximately 100 accounts and maybe 20 of them use Outlook (pop) and the rest all log in via godaddy's webmail client. Godaddy has no export function except for contacts/address books. Current email server is CommuniGate .
They are a sort-of important branch and can't afford a long downtime in regards to email, however I'm thinking it will take at least a couple of days.
My plan is to
1) Cut off their access to the existing godaddy accounts by changing the passwords
2) Move the email to the new accounts via IMAP (one client - 100 accounts..this will take time)
3) Change DNS / MX records to point to new server(s)
4) Provide access by pointing Outlook users to new server, and webmail users to new webmail page.
Downside: yes some email will be lost in between moving email with IMAP and opening it back up. I don't see a way around this.
I'd love to just make them use the existing company domain and give them all new email accounts and let them be responsible for moving their own data, but I don't see them either being agreeable to this, or even if I could force them to, see them moving their email themselves. If I could though, then I'd just cut off that domain at some point in the future.
Better solutions welcomed!
Cheers
Why do you have to start by shutting off passwords?
I'd do something like this:
1) Create new email accounts
2) Migrate existing email archives over
3) Change DNS / MX records to point to new servers
4) Send users login/access info for new email accounts
5) Cut off old accounts only when everything is known to be migrated successfully
In other words, you may have a (brief) period, presumably late at night on a weekend, when nobody can access their email, because the DNS change is underway, but they don't have login info yet. But you won't have any emails lost, because all email will either hit the old accounts (which you will let them keep access to until you're 100% done with the migration), or the new ones.
posted by Tomorrowful at 11:56 AM on March 22, 2012
I'd do something like this:
1) Create new email accounts
2) Migrate existing email archives over
3) Change DNS / MX records to point to new servers
4) Send users login/access info for new email accounts
5) Cut off old accounts only when everything is known to be migrated successfully
In other words, you may have a (brief) period, presumably late at night on a weekend, when nobody can access their email, because the DNS change is underway, but they don't have login info yet. But you won't have any emails lost, because all email will either hit the old accounts (which you will let them keep access to until you're 100% done with the migration), or the new ones.
posted by Tomorrowful at 11:56 AM on March 22, 2012
MX records might take a while to propagate, so for some time after changing those mails might still arrive at the old host instead of the new one.
If Godaddy allows you to set up forwarding, this might work:
- Change the TTL on your MX record to something lowish (1h?)
- Set up the new mail server, with some secondary MX record (@temp.yourcompany.com)
- Set up forwards from the old account to the temp email
- While doing the forwards, tell users to login at the new server for new mails, though they still have access to the old account for old mails
- Change main MX record
- Copy (not move) over old mails
- Once done with one account tell the user and change his old account password if you want
- Wait a week or so for the MX record to update everywhere
This way you won't lose any mails, and the users will have full access to their current and old mails at any point in the process.
posted by Cironian at 12:00 PM on March 22, 2012
If Godaddy allows you to set up forwarding, this might work:
- Change the TTL on your MX record to something lowish (1h?)
- Set up the new mail server, with some secondary MX record (@temp.yourcompany.com)
- Set up forwards from the old account to the temp email
- While doing the forwards, tell users to login at the new server for new mails, though they still have access to the old account for old mails
- Change main MX record
- Copy (not move) over old mails
- Once done with one account tell the user and change his old account password if you want
- Wait a week or so for the MX record to update everywhere
This way you won't lose any mails, and the users will have full access to their current and old mails at any point in the process.
posted by Cironian at 12:00 PM on March 22, 2012
Replace "secondary MX" with "temporary MX" in my reply. Secondary MX has a specific meaning which has nothing to do with what I was talking about.
posted by Cironian at 12:04 PM on March 22, 2012
posted by Cironian at 12:04 PM on March 22, 2012
Response by poster: @Cironian: They don't have forwarding, unless the account is a forwarder by itself. (So they couldn't have access to their Godaddy acount AND have a forwarder account).
@straw: How do I have them switch to the new servers before the DNS/MX is changed?
posted by bellastarr at 12:15 PM on March 22, 2012
@straw: How do I have them switch to the new servers before the DNS/MX is changed?
posted by bellastarr at 12:15 PM on March 22, 2012
I thought that one of the cardinal rules in doing these migrations was to never lose email ever.
Can the users deal with not having 100% of their email in one place for a short time?
If so, I'd consider doing a first IMAP migration, then switching the MX record, then doing a second IMAP migration that would just be the diff that would cover any mail that came in while the first migration was ongoing (and would, of course, be a hugely lower volume of mail than the first migration).
Standard disclaimer: IANASystemAdministrator, so there may be something fundamentally flawed about this, so take this with a grain of salt.
posted by Betelgeuse at 12:15 PM on March 22, 2012
Can the users deal with not having 100% of their email in one place for a short time?
If so, I'd consider doing a first IMAP migration, then switching the MX record, then doing a second IMAP migration that would just be the diff that would cover any mail that came in while the first migration was ongoing (and would, of course, be a hugely lower volume of mail than the first migration).
Standard disclaimer: IANASystemAdministrator, so there may be something fundamentally flawed about this, so take this with a grain of salt.
posted by Betelgeuse at 12:15 PM on March 22, 2012
Are you handy with the command line? I've used the tools on this page to migrate multiple large mail accounts, and it's worked very well. Specifically, look at imapcopy.pl, migrateIMAP.pl (like imapcopy.pl, but for moving multiple users all at once), and pop3toimap.pl.
posted by zsazsa at 12:18 PM on March 22, 2012
posted by zsazsa at 12:18 PM on March 22, 2012
Response by poster: @Betelgeuse: Once the domain name points to the new server, any IMAP/POP off the Godaddy server will no longer work because the @branchcompany.com account names would not be valid on Godaddy.
posted by bellastarr at 12:20 PM on March 22, 2012
posted by bellastarr at 12:20 PM on March 22, 2012
To have them switch before you change the MX records for the domain, just have them use alternate servers for their config (newsmtp..com, newpop..com). I'm assuming you'll have to issue new passwords anyway.
On the other hand, if you've got grabbing mail from their old account to the new account set up, and you can get their old passwords, then you don't really need to have the users do anything: Just switch the DNS and let the mail catch up with them.
posted by straw at 12:25 PM on March 22, 2012
On the other hand, if you've got grabbing mail from their old account to the new account set up, and you can get their old passwords, then you don't really need to have the users do anything: Just switch the DNS and let the mail catch up with them.
posted by straw at 12:25 PM on March 22, 2012
Once the domain name points to the new server, any IMAP/POP off the Godaddy server will no longer work because the @branchcompany.com account names would not be valid on Godaddy
Unless I'm badly mistaken, IMAP and POP clients use A records, not MX records, to figure out where branchcompany.com is; only SMTP uses MX records. So provided you leave the A records in place until you've finished migrating the MX records, you should be able to pull in all your old mails with no downtime.
posted by flabdablet at 4:47 PM on March 22, 2012
Unless I'm badly mistaken, IMAP and POP clients use A records, not MX records, to figure out where branchcompany.com is; only SMTP uses MX records. So provided you leave the A records in place until you've finished migrating the MX records, you should be able to pull in all your old mails with no downtime.
posted by flabdablet at 4:47 PM on March 22, 2012
Response by poster: @flabdablet: That is correct they use A records, however a kink in creating the domain and accounts on our server first is that any email from within the company domain will route to the same server before going outside to their current server - so they won't receive email from people within the company until after the move.
posted by bellastarr at 6:32 AM on March 23, 2012
posted by bellastarr at 6:32 AM on March 23, 2012
OK then, how about doing it this way:
Your most important priority is to get all the mails properly archived on your own equipment per company policy, yes? So the first thing to do is set up a script that just goes round and round forever in a big 100-account loop, slurping up mails from GoDaddy's IMAP server and copying them to yours.
That script should connect to the GoDaddy IMAP server via a raw IP address or via a special domain name you set up just for that job, so that it will continue to function regardless of what you do with the rest of your DNS arrangements.
After the bulk of the accounts are in sync and the only thing the script is doing is propagating current mail, change the affiliate branch's DNS A records that currently point to GoDaddy's webmail, POP3 and SMTP servers so they point to yours instead. Your POP3 users won't notice any difference. Your webmail users will, but provided your webmail server isn't too different from what they're used to from GoDaddy they shouldn't kick up too much of a fuss.
During this part of the cutover, there may be some delays on incoming mail; exactly how much will depend on how the mail sync script is constructed and how much grunt you throw at it. But all the mails will still get through.
Once you're convinced it's working, cut over the MX records so that mail sent to your affiliate branch goes directly to your own mailboxes instead of GoDaddy's. All that should happen then is that the delays go away, and your script runs out of things to copy as the MX record change propagates through the DNS hierarchy.
That should work, shoudln't it?
posted by flabdablet at 4:23 AM on March 24, 2012
Your most important priority is to get all the mails properly archived on your own equipment per company policy, yes? So the first thing to do is set up a script that just goes round and round forever in a big 100-account loop, slurping up mails from GoDaddy's IMAP server and copying them to yours.
That script should connect to the GoDaddy IMAP server via a raw IP address or via a special domain name you set up just for that job, so that it will continue to function regardless of what you do with the rest of your DNS arrangements.
After the bulk of the accounts are in sync and the only thing the script is doing is propagating current mail, change the affiliate branch's DNS A records that currently point to GoDaddy's webmail, POP3 and SMTP servers so they point to yours instead. Your POP3 users won't notice any difference. Your webmail users will, but provided your webmail server isn't too different from what they're used to from GoDaddy they shouldn't kick up too much of a fuss.
During this part of the cutover, there may be some delays on incoming mail; exactly how much will depend on how the mail sync script is constructed and how much grunt you throw at it. But all the mails will still get through.
Once you're convinced it's working, cut over the MX records so that mail sent to your affiliate branch goes directly to your own mailboxes instead of GoDaddy's. All that should happen then is that the delays go away, and your script runs out of things to copy as the MX record change propagates through the DNS hierarchy.
That should work, shoudln't it?
posted by flabdablet at 4:23 AM on March 24, 2012
« Older How to love when love can be taken away from you... | Recommend a tailor in Richmond, VA for a student Newer »
This thread is closed to new comments.
posted by straw at 11:56 AM on March 22, 2012