Deprecated: YoastSEO_Vendor\Symfony\Component\DependencyInjection\Container::__construct(): Implicitly marking parameter $parameterBag as nullable is deprecated, the explicit nullable type must be used instead in /home/nubelus/sharedove/adisjugo/wp-content/plugins/wordpress-seo/vendor_prefixed/symfony/dependency-injection/Container.php on line 60

Deprecated: YoastSEO_Vendor\League\OAuth2\Client\Provider\AbstractProvider::authorize(): Implicitly marking parameter $redirectHandler as nullable is deprecated, the explicit nullable type must be used instead in /home/nubelus/sharedove/adisjugo/wp-content/plugins/wordpress-seo/vendor_prefixed/league/oauth2-client/src/Provider/AbstractProvider.php on line 416

Deprecated: YoastSEO_Vendor\GuzzleHttp\Client::getConfig(): Implicitly marking parameter $option as nullable is deprecated, the explicit nullable type must be used instead in /home/nubelus/sharedove/adisjugo/wp-content/plugins/wordpress-seo/vendor_prefixed/guzzlehttp/guzzle/src/Client.php on line 181

Deprecated: YoastSEO_Vendor\GuzzleHttp\ClientInterface::getConfig(): Implicitly marking parameter $option as nullable is deprecated, the explicit nullable type must be used instead in /home/nubelus/sharedove/adisjugo/wp-content/plugins/wordpress-seo/vendor_prefixed/guzzlehttp/guzzle/src/ClientInterface.php on line 77
{"id":1157,"date":"2012-08-19T22:24:26","date_gmt":"2012-08-19T20:24:26","guid":{"rendered":"https:\/\/blog.sharedove.com\/adisjugo\/?p=1157"},"modified":"2012-08-19T22:24:26","modified_gmt":"2012-08-19T20:24:26","slug":"how-did-i-move-my-mothers-email-and-my-wifes-web-site-to-office365-and-didnt-get-killed-in-the-process-part-2-planning","status":"publish","type":"post","link":"https:\/\/blog.sharedove.com\/adisjugo\/index.php\/2012\/08\/19\/how-did-i-move-my-mothers-email-and-my-wifes-web-site-to-office365-and-didnt-get-killed-in-the-process-part-2-planning\/","title":{"rendered":"How did I move my mother\u2019s email and my wife\u2019s web site to Office365, and didn\u2019t get killed in the process \/\/ Part 2: Planning"},"content":{"rendered":"

In my previous post<\/a>, 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 <\/strong>be done, and that it could be done without spending nights behind the monitor with configuring the details (I simply didn\u2019t have time for that).<\/p>\n

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.<\/p>\n

The starting point was my Linux server. It has a WHM\/cPanel<\/a> 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 \u2013 there are all kind of legacy webs<\/a>, 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<\/a> 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.<\/p>\n

Now, having said what remains on the Linux server, let\u2019s see what is being moved:<\/p>\n

\n
All email accounts, with aliases and forwarders on my \u201cprimary\u201d domain<\/li>\n
All email accounts, with aliases and forwarders on an additional domain, which I use for \u201csemi-business\u201d purposes (correspondence with magazines, MVP colleagues etc.)<\/li>\n
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.<\/li>\n
The most famous Bosnian rock band<\/a>, rocking stages since 30 years<\/a>, 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.<\/li>\n
My wife\u2019s web site goes to SharePoint Online \u2013 public site. It is hosted on a subdomain of my \u201cprimary\u201d domain.\u00a0 She has an old, plain HTML based web site, that she updates manually, and she really deserves some decent content management tool. So it\u2019s SharePoint online. All the other web sites will remain on the Linux server.<\/li>\n
My test domain, \u201cprogressive.ba\u201d. That\u2019s 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.<\/li>\n<\/ul>\n
Although this is a purely private setup, when I look at it, it actually might be a setup of a small company\u2026 That\u2019s why planning is needed, loosing emails or data is actually not an option here $\"Smile\"$ <\/p>\n
Having said that, an important tip from my side, not specific to Office 365, but related to all email migrations:<\/p>\n
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 \u201cold\u201d, inactive mailbox. You can fetch those mails there, but it is easier if you forward them to some \u201cneutral\u201d outside address, and look there for time to time. During migration, I am forwarding all my mails to my Hotmail address (which I don\u2019t use otherwise). You never know\u2026\u00a0\u00a0 <\/span><\/p><\/blockquote>\n
So, having that in mind, my migration plan looked like this :<\/p>\n
\n
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.<\/li>\n
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.<\/li>\n
Change MX and DNS records for the test domain, to point mail delivery to Office 365.<\/li>\n
Fine tune exchange and lync, make sure everything is working.<\/li>\n
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<\/li>\n
After I am sure that everything works with the test domain, do the same thing for two production \/ live domains.<\/li>\n
Create new web site for my wife on SharePoint online, and point her subdomain to that new site.<\/li>\n<\/ol>\n
So far so good. For the end of today\u2019s Office 365 journey, let\u2019s verify the domains with Office 365 (#1 in the list above).<\/p>\n
Login to your Office 365 site, and click on the \u201cDomains\u201d link. Click on \u201cAdd new domain\u201d, and enter a domain name. In my case, it\u2019s my test domain \u201cprogressive.ba\u201d.<\/p>\n
$\"001$ <\/a><\/p>\n
When prompted to verify the domain, choose the \u201cGeneral instructions\u201d from drop-down box, and then \u201cAdd a TXT record (preferred method)\u201d as a verification method.<\/p>\n
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.<\/p>\n
$\"003$ <\/a><\/p>\n
$\"004$ <\/a><\/p>\n
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 \u201cAdd a record\u201d icon.<\/p>\n
Enter the domain name, 3600 seconds as Time to Live (TTL \u2013 1 hour), type is TXT, and TXT Data is whatever you have copied from the previous step (MS=msXXXXXXX \u2013 string copied from Office365 domain verification step).<\/p>\n
$\"005$ <\/a><\/p>\n
Click on \u201cAdd Record\u201d button,.<\/p>\n
Now, go to some DNS lookup web site, such as www.centralops.net<\/a>. Enter your domain, select \u201cDNS Records\u201d and click on \u201cGo\u201d, and look if TXT record you have entered is already there. You might need to wait few minutes, before it propagates (becomes \u201cActive\u201d). Supposedly, up to 72 hours, even if that has never happened to me. 10-15 minutes, from my experience, is more realistic.<\/p>\n
$\"005-06\"$ <\/a><\/p>\n
After it appears, switch back to Office365 admin panel, and click on the \u201cVerify domain\u201d button. Usually, if CentralOps<\/a> 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\u2019t work, wait few minutes, and try again \u2013 it will be recognized eventually.<\/p>\n
When you are asked to specify domain services you want to use, please choose Exchange Online and Lync Online. Don\u2019t select SharePoint Online yet.<\/p>\n
$\"006_verify_03\"$ <\/a><\/p>\n
And that would be all concerning domain verification. Wizard will ask you now to configure your domain, but don\u2019t do that yet. Rather, repeat the verification steps for all the domains you want to use with Office365.<\/p>\n
$\"007$ <\/a><\/p>\n
And don\u2019t worry \u2013 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.<\/p>\n
The next step will be to configure the domains, and move the mailboxes to Exchange Online, but more about it tomorrow.<\/p>\n
Until then\u2026<\/p>\n
\n\t\t\t
\n\t\t\t <\/div><\/div>\n\t\t