We have recently been working with a client to upgrade their email service from IONOS email to Microsoft 365 for Business.
The process is usually quite straightforward, however, we hit a few stumbling blocks due to the use of POP protocols on some of the key desktop computers - in particular, one computer was using a version of Microsoft Outlook 2010 (that they wanted to retain).
We thought we would document some of the issues that cropped up to help others in the same situation. This kind of migration is usually straightforward for someone with a reasonable level of IT skills and experience of setting up email accounts. However, it can get quite complicated fairly quickly, so if you need help with migrating your email service, please get in touch to see how Studio JERO can help.
In this article
- Migrate IMAP email provider to Microsoft 365 for Business
- Migrate POP email to Microsoft 365 for Business?
- Using Microsoft 365 for Business with Outlook 2010?
- Don't forget the Outlook Contacts & Auto-Complete cache
- Conclusions on implementing Microsoft 365 from/to legacy systems
Migrate from IMAP email provider to Microsoft 365 for Business
For the devices using IMAP, the process is relatively straightforward to migrate to Microsoft 365 for Business. Once you have the existing username and password you can migrate the contents of the account using the Microsoft admin tools.
- Pick your pricing plan and create your Microsoft 365 for Business account
- Create the users in Microsoft 365 admin centre
- go to Setup > Data migration
- Select the existing data service provider, or select Other email sources to configure manually.
- Enter the various credentials required for each user
- Press Start migration
- Relax with a cup of tea and watch the process tick along happily
- Once everything has transferred you can then update your DNS settings to allow new emails to go to the new Microsoft 365 for Business accounts.
That all seems a little too easy…
What about migrating POP email accounts with Microsoft 365 for Business?
With this particular project we were concerned that the accounts had very small mailboxes on the IMAP server. We put this down to two possibilities
- They are super organised and operate a zero inbox system
- Or they were using POP email to download and store emails locally
It turned out that it was a combination of both. All users were super organised and kept pretty tidy mailboxes. Some IMAP users were filing emails locally in folders on their devices, some were close to an inbox zero system and others used POP to download emails locally on their desktop.
So what was a task to migrate a few 700MB IMAP mailbox accounts to Microsoft 365, became a task to identify and migrate several 4GB POP email accounts from and to a range of legacy systems.
At this point it requires a higher level of technical understanding and IT experience. Microsoft in particular make this kind of migration far more complicated than it needs to be due to multiple interfaces that all have different UI, far too many stages and an understanding of command line code.
Just to show how complicated it is, and to help anyone attempting the same process, here's a brief overview of the stages:
- Export the PST files from each Microsoft Outlook account using POP
- Assign the Mailbox Import Export role in Exchange Online
- Assign the Mail Recipients role in Exchange Online
- Goto a different website (different UI again) to create an import job and generate an SAS upload URL
- Download and install a new piece of software called AzCopy Tool
- Use the Command Prompt to run the software
- Write up the following command line:
AzCopy.exe /Source:<Location of PST files> /Dest:<SAS URL> /V:<Log file location> /Y
This may seem simple-ish, but it all reminded me of the kind of coding I had to do nearly 30 years ago at school in DOS. It took a fair bit of messing about to get this right, but you eventually end up with something like the below
AzCopy.exe /Source:"c:\Users\studioJERO\Documents\client-name\pst-files" /Dest:"https://xxxxxxx.blob.core.windows.net/ingestiondata?sv=20xx-04-05&sr=c&si=IngestionSasForAzCopy20xxxxxx2018485798&sig=1xxxxxx9OSIxUTnk12qLqYxxxscCFFf8MKxxxxxxxD&se=2021-01-21T20%3A18%3A50Z" /V:"C:\temp\log" /Y /NC:2
This should then upload the PST file, however we had lots of trouble at this stage and kept receiving error messages that the upload was timing out
“The client could not finish the operation within specified timeout" Eventually we found this tip on a blog to reduce the concurrent operations with the import services. This essentially means adding the /NC:2 at the end of the command.
- Once the PST file is uploaded, you then need to create a CSV mapping file in Excel to specify which user mailboxes the PST files will be imported to. Again this is another process that is made overly complicated. Other systems I have used can work all this out within a browser and you can just check that everything is correct (MailChimp has a great example of this).
- Then head back to the Microsoft Security & Compliance Centre to confirm you have uploaded the PST files and validate your mapping file. Finally, after this the process can begin to import your data.
Their alternative solution is to use drive shipping to physically send them a hard drive of your PST files for upload, like it is 1999!
Really in 2021, this is far too complicated. It should be possible to just drag and drop a file, like you would with a service like WeTransfer to move large files.
It appeared that throughout the process the stages were aimed at IT Specialists working with large migrations of data for large companies - The process was wholly unsuitable for small and medium businesses looking to utilise Microsoft 365 for their company email.
Didn't you say you were using Microsoft 365 for Business on Outlook 2010?
One of the key machines was an old PC using Outlook 2010 as their email client. For various reasons we needed to retain the machine and the version of Outlook it was currently running.
We successfully installed Microsoft 365 for Business on all the other machines and devices, including one running Outlook 2016 without any real issues. However, when it came to the machine with Outlook 2010 we hit several brick walls!
We eventually found this blog that outlines a process for configuring Outlook 2010 for Office 365. Essentially the stages were:
- Download a particular service pack
- Open the Control Panel > Mail > E-mail Accounts > New
- Select Manual setup > Microsoft Exchange Server
- Enter the following credentials Server: outlook.office365.comUser Name: (email address)
- Click More Settings
- Click the Security tab.
- Uncheck "Encrypt data between Microsoft Outlook and Microsoft Exchange".
- Choose Anonymous Authentication from the Logon network security drop-down menu.
- Click the Connection tab Check Connect to Microsoft Exchange using HTTP, then click Exchange Proxy Settings In the Use this URL to connect to my proxy server for Exchange field, enter outlook.office365.comCheck the Only connect to proxy servers that have this principal name on their certificate and enter msstd:outlook.com in the text field. Check the On fast networks, connect using HTTP first then connect using TCP/IP box.Select Basic Authentication from the Use this authentication when connecting to my proxy server for Exchange drop-down menu.
- Click On OK and Apply
- Click Check Name
- When the authentication prompt appears, enter your Microsoft 365 email address/password and check the Remember my credentials.
- Click OK
We found that this process didn't fully work on this particular copy of Outlook 2010 and we needed to do a couple of extra stages. In particular we believe the process hit a wall due to Outlook 2010 not being able to deal with the Multi Factor Authentication that defaults on with Microsoft 365 accounts.
1) Temporarily turned off Multi Factor Authentication
2) Rebooted the computer (always helps right!)
If this hadn't worked, our next stage would of been to Allow App Passwords to be created. I've had success with this on Google Workspace installs facing similar problems. We didn't need to do this in the end, but that would of been the next thing to try.
Don't forget the Outlook Contacts & Auto-Complete cache when migrating to Microsoft 365!
Something to consider when migrating email accounts to Microsoft 365 is the auto-complete cache and the user's saved contacts.
When you export the PST file from POP systems, or migrate IMAP data, it will include not just the emails, but also the user's contacts and calendar entries.
This is great, but the contacts don't automatically repopulate the auto-complete cache in Outlook. This means that Outlook doesn't automatically populate the To field when you start typing a name.
There is a hack for this. Essentially it involves sending a single email to all your contacts whilst the computer is offline:
- Place Outlook in Offline Mode by clicking on the Work Offline button on the Send/Receive tab.
- Create a new email.
- Click on the To button.
- Select all the addresses from your Contacts
- Click OK.
- Send the message.
- Move the message from your Outbox folder into your Draft folder.
- Place Outlook in Online Mode by clicking on the Work Offline button on the Send/Receive tab.
This works perfectly if the user has been saving their contacts. However, this doesn't work if the user had been purely using the auto complete to populate the To field, without saving contact's email addresses to their Outlook contacts.
In this case it is important to save a copy of the auto complete cache file before migrating to a new email provider.
Conclusions on implementing Microsoft 365 from/to legacy systems
Depending on the version of Outlook, this will either be a .nk2 or a .dat file and will be stored as a hidden data file. The file will have the same name as your current Outlook profile and will be found at Application Data/Microsoft/Outlook or something like Application Data/Roaming/Microsoft/Outlook (depending on your version of outlook).
To view the file you may need to navigate to View and check the box Hidden items to view the hidden folders/files.
Conclusions on implementing Microsoft 365 from/to legacy systems
I've put together this post together to help others facing similar problems to us when implementing Microsoft 365 for Business to small and medium sized businesses that are using legacy systems. Although this example was particularly complicated, I think on balance the product offers significant benefits to the client's business and workflow.
For businesses using more recent devices, processes and software the migration is relatively straightforward.
Microsoft 365 and Google's Workspace are the only two business email services we currently recommend, and even after this difficult install I would still recommend Microsoft 365 as a email and productivity product.