Email migration best practices

Transcript

1. Email migration best practices Viktor Petersson | vpetersson@wireload.net | @vpetersson

2. About us • Launched YippieMove in 2008 • Email migration

   experts • Worked with many well-known clients

3. About YippieMove • The most powerful email migration tool •

   Support most email providers / servers on the market • Cost effective and scalable YippieMove offers (in addition to consulting) • Single-user migrations • Batch migrations • Self-service portals • API

4. The basics

5. Email Protocols Inbound • IMAP • POP3 • MAPI Outbound

   • SMTP Image from Apple.com

6. DNS for email DNS • A-record • CNAME • MX-record

   • Priorities • Time To Live (TTL) • PTR, TXT, SPF... Image from sxc.hu

7. DNS example google.com 74.125.224.36 [...] mail.google.com googlemail.l.google.com [...] google.com aspmx.l.google.com

   [...] A-record CNAME MX-record

8. Big picture Recipient’s Server Recipient Sender MX-record SMTP CNAME A-record

   IMAP MAPI POP3 Sender’s Server SMTP DNS-lookup

9. Best practices

10. Objectives •Minimize impact on users • Before, during and after

    the migration • Ensure data integrity

11. Pre-email migration checklist • Are you dealing with a single

    or multiple domains? • If large migration, can it be broken down into groups? • Do you have access to make DNS changes? • What is the TTL for the relevant DNS-records? • Do you have access to email administration? • Both source and destination

12. Pre-email migration checklist • How are the clients accessing their

    email today? • Where are the messages stored (remote or locally)? • How can we access the messages? • What authentication methods are supported? • When is the lowest email transaction volume? • What about contacts and calendar?

13. What are your options? • “Drag and drop”* • GAMME*

    • Google Apps sync for Outlook* • POP3-fetcher • Server-side scripting / tools (imapsync etc) • Email Migration-as-a-Service (such as YippieMove) • No migration * Limited by local bandwidth

14. Email migration workflow The week before the migration • Drop

    the TTLs to the lowest value (usually 3600s/1h) • Prepare a list of all users, domains and aliases The week of the migration • Setup all accounts on the destination • Configure all domain and user aliases • Send out provisioned destination passwords to users

15. Email migration workflow The day of the email migration (after

    business hours) • Change the DNS-records (MX and others) • Provision new source passwords • Assuming no other method is supported A few hours later (4xTTL is a good rule of thumb) • Begin the email migration

16. Tips and tricks

17. Tips and tricks for the email migration • Use OAuth

    for authentication when possible • Use application-specific password as fallback • TTLs can’t be trusted • Don’t provide users with the reseted password • They will change the password • It will lead to interruptions in the migration

18. Tips and tricks for the email migration • Use “Live

    CDs” if you need to access customer data • MX-records does not affect access to the emails • mail.example.com => someserver.provider.com

19. Tips and tricks for IMAP Open a connection • $

    telnet mail.example.com 143 • $ openssl s_client -crlf -connect mail.example.com:993 Login • . LOGIN username@example.com password Logout • . LOGOUT

20. Tips and tricks for DNS Verify MX records • $

    dig example.com mx @8.8.8.8 Verify DNS records • $ dig example.com @8.8.8.8 • $ dig mail.example.com @8.8.8.8 Web-based alternatives: • MX-toolbox (mxtoolbox.com) • Your favorite domain registrar

21. Tips and tricks for DNS

22. www.YippieMove.com Viktor Petersson | vpetersson@wireload.net | @vpetersson The deck will

    be available at wireload.net/news

23. Demo