How did I move my mother’s email and my wife’s web site to Office365, and didn’t get killed in the process // Part 2: Planning

In my previous post, I have described the motives which have pushed me into moving my proven, long-standing Linux/cPanel/IMAP setup towards Microsoft Office365. I needed to make sure that it could be done, and that it could be done without spending nights behind the monitor with configuring the details (I simply didn’t have time for that).

But, the decision has been made, and there was no way back. And since I am a cautious person by nature, I needed to figure out a plan, which would ensure that everything was really working as I wanted it to.

The starting point was my Linux server. It has a WHM/cPanel based interface for all different kind of management and configuration tasks. Nothing has ever been manually configured there, cPanel was used for configuration. Not everything will be migrated – there are all kind of legacy webs, scripts, files and repositories there, which will remain on the Linux server. This blog, for example. No sense in moving that to Office365. Furthermore, there are email accounts set up on various domains, which are used just for specific purposes, and they will remain IMAP. For example, we are organizing a SharePoint and Project Conference Adriatics in Zagreb, Croatia in November, and the members of organization committee have email accounts on spcadriatics.com domain, which is hosted on my Linux server. That will not be moved, that stays.

Now, having said what remains on the Linux server, let’s see what is being moved:

• All email accounts, with aliases and forwarders on my “primary” domain
• All email accounts, with aliases and forwarders on an additional domain, which I use for “semi-business” purposes (correspondence with magazines, MVP colleagues etc.)
• A good friend of mine is a well know Croatian photograph, she has two mails accounts and a small web site on my Linux server. Her mail accounts will be migrated to Office 365 as well, web stays.
• The most famous Bosnian rock band, rocking stages since 30 years, have their web site and email addresses on my Linux Server. Their email accounts will be also moved to Office 365, but to their own Office365 account, after I am done with migrating my stuff.
• My wife’s web site goes to SharePoint Online – public site. It is hosted on a subdomain of my “primary” domain.  She has an old, plain HTML based web site, that she updates manually, and she really deserves some decent content management tool. So it’s SharePoint online. All the other web sites will remain on the Linux server.
• My test domain, “progressive.ba”. That’s my playground. Email accounts and aliases on that domain will be migrated, and, as I said, that will be the first thing that goes to Office 365.

Although this is a purely private setup, when I look at it, it actually might be a setup of a small company… That’s why planning is needed, loosing emails or data is actually not an option here

Having said that, an important tip from my side, not specific to Office 365, but related to all email migrations:

Before you migrate your email accounts, do the backup (obviously), and then make a redirection of all important accounts to outside account(s), at least for 72 hours. Why? Not all DNS servers accept propagated DNS changes at the same time. So it can happen, even 2-3 days after mailbox migration, that some emails arrive to the “old”, inactive mailbox. You can fetch those mails there, but it is easier if you forward them to some “neutral” outside address, and look there for time to time. During migration, I am forwarding all my mails to my Hotmail address (which I don’t use otherwise). You never know…  

So, having that in mind, my migration plan looked like this :

1. Verify and register all the domains mentioned above with Office365. This is a pure validation step, so that Office365 knows that the domains really belong to me.
2. Create all necessary email accounts on Office 365, with aliases. They will be inactive, all right, all MX records for all my domains are still pointing to the old Linux server. But, once I switch, incoming mails need to be delivered somewhere.
3. Change MX and DNS records for the test domain, to point mail delivery to Office 365.
4. Fine tune exchange and lync, make sure everything is working.
5. Create a subdomain of the test domain, and point it to Office 365 – SharePoint Online public site, to make sure that SharePoint Online web hosting works properly
6. After I am sure that everything works with the test domain, do the same thing for two production / live domains.
7. Create new web site for my wife on SharePoint online, and point her subdomain to that new site.

So far so good. For the end of today’s Office 365 journey, let’s verify the domains with Office 365 (#1 in the list above).

Login to your Office 365 site, and click on the “Domains” link. Click on “Add new domain”, and enter a domain name. In my case, it’s my test domain “progressive.ba”.

When prompted to verify the domain, choose the “General instructions” from drop-down box, and then “Add a TXT record (preferred method)” as a verification method.

A message will appear, telling you that you need to enter a TXT record for this domain in the DNS. The TXT record will be in format MS=msXXXXXXXXX, where XXXXXXX is a random generated number, which Office365 will search for in the DNS record for the domain. Please copy that string into clipboard, we will need it in the next step.

Now, switch to your cPanel interface, and go to the Advanced DNS editor in cPanel. Choose your domain from drop-down box, tand hen click on the “Add a record” icon.

Enter the domain name, 3600 seconds as Time to Live (TTL – 1 hour), type is TXT, and TXT Data is whatever you have copied from the previous step (MS=msXXXXXXX – string copied from Office365 domain verification step).

Click on “Add Record” button,.

Now, go to some DNS lookup web site, such as www.centralops.net. Enter your domain, select “DNS Records” and click on “Go”, and look if TXT record you have entered is already there. You might need to wait few minutes, before it propagates (becomes “Active”). Supposedly, up to 72 hours, even if that has never happened to me. 10-15 minutes, from my experience, is more realistic.

After it appears, switch back to Office365 admin panel, and click on the “Verify domain” button. Usually, if CentralOps sees the DNS record, Office365 should see it, too, but sometimes there is a short delay – not all DNS servers accept newly propagated DNS records equally fast. If the verification doesn’t work, wait few minutes, and try again – it will be recognized eventually.

When you are asked to specify domain services you want to use, please choose Exchange Online and Lync Online. Don’t select SharePoint Online yet.

And that would be all concerning domain verification. Wizard will ask you now to configure your domain, but don’t do that yet. Rather, repeat the verification steps for all the domains you want to use with Office365.

And don’t worry – nothing is on Office365 yet. With this step, we have just convinced Office365 that we really own these domains. Everything is still on the old, Linux machine.

The next step will be to configure the domains, and move the mailboxes to Exchange Online, but more about it tomorrow.

Until then…