Showing results for 
Search instead for 
Did you mean: 
Create Post

Out Of Office: Planning the Migration to Office 365

Level 9

Back in the first post of this series we covered off the planning portion with regards to implementing Office 365. Knowing what you are aiming to achieve is critical to measuring the value and success of a project. Assuming the math checks out, now it is time to pull the trigger and start migrating to Office 365. A botched migration can easily compromise the value of a project, so planning should be done with care.


Office 365 offers multiple options for deployment. You can run fully in the cloud, which means you'll be able to remove large parts of your infrastructure. This can be especially appealing if you are nearing the end of life for some equipment. Saving on a large capital expenditure and moving it to an operating expense can be ideal at times.

Another option might be a hybrid approach. This approach is a mix of using your on-premises infrastructure and Office 365's infrastructure. This is commonly used as a way to get your mailboxes and data up to the cloud. It allows for administrators to choose which mailboxes run where. It can also be used for security or compliance measures: maybe you want all C-level executives to keep their mailboxes on-premises.


Have you opted to roll out any other Office 365 / Azure services into the mix? Maybe you are interested in using Azure Multifactor Authentication (MFA), or maybe Azure Active Directory to allow for single sign-on (SSO). How does that fit into the process? You'll need to see how any new service fits into your current environment. Using MFA as an example, will this be displacing an existing service, or is it a new offering for the environment? Either way, there will be additional work to be done.


As with any IT project, what will you do if you have a failure along the way? This isn't to say that Office 365 as a whole isn't working out but think about the smaller things. What if you move your CEO's mailbox and then something goes awry? How do you move it back? Identifying what needs to be migrated, upgraded, or installed based on the above gives you a list. You can use that list to start forming failback planning for each of those components.

A good tip for planning failback is don't just focus on the tech. Make sure you know what people need to be involved. Do you need specific folks from your team or from other teams? Make sure that is part of the plan so if you do need rollback, those folks can be available, just in case.


When it comes time to start moving data, make sure you don't blindside your users. You'll want to identify key individuals within your organization to liaise with (e.g. department managers). The goal here is to ensure that you minimize disruptions. The last thing you want to do is have an outage period overlap with the closing of a large sales deal.

Kicking off a platform migration can be a stressful event, but proper planning and communication can go a long way. I would love to hear any comments or experiences others have had when migrating to a cloud service such as Office 365. Did everything go smooth? If there were hiccups, what were they, and how were they handled?


Remember to define your expectations.  If your users have been accustomed to the performance of running Office on their own computers, and now you'll be moving them to the cloud, definitely do a proof of concept that includes your biggest critics.  If you can get them on board, if they're satisfied with the speed and availability, you've taken the first step in the right direction.

Do NOT forget that this is a service that will scale to the entire company.  Setting up a POC for five people is one thing.  Scaling your systems' performance through your firewall and out through your internet pipe to support thousands of users may result in unexpected latency--and many complaints.  Don't be bitten--be aware of the ways to prevent this.

If your firewall and threat detection/defense is already scaled large enough to do the work in hardware instead of in software, maybe you won't have too bad a migration experience.  If your firewall isn't big enough to move millions of files to / from the cloud without turning off inspection, get a bigger firewall before going down this path.

Consider the costs and benefits of SD-WAN if you're an enterprise with many remote sites.  If those sites only relied on their WAN for access to stored files in the data center and for Internet access and perhaps VoIP, you'll find that the pipes will spend more time passing normal daily document traffic than you expect.  Maybe it makes sense for all of those sites to have an additional pipe that goes to the Internet, and thereby bypasses using up your WAN pipes.

Moving to the clouds is not all pro's and benefits and lowered MS Office costs.  Learn what challenges others have discovered on their way to the cloud, and do what it takes to ensure your customers understand the performance differences that may accompany your move.

  1. Base Line your performance now, and compare it to the cloud performance.
  2. Compare it again after all of your company is using the cloud.
  3. Obtain budget AHEAD of the POC or main go-live for proper cloud monitoring, so you can do the troubleshooting instead of trusting the ISP or CSP, who will blame problems on your network, not theirs.
  4. Build in some guarantees with the cloud provider and ISP, if they'll let you.
Level 13

and a plan C


Nice write up


O365 is a mish mash collection of tools that sometimes work together.

Many of the things you take for granted simply don't exist in O365.

File retention is best described as an eyeopener, followed by concerns that this is supposed to be an enterprise system.

Active employee data retention is pretty simple  - but it all falls apart when the employee leaves.

O365 is also geared for user self support. Much of its operation is setup to have the user fix their own stuff.

This great for the right userbase, but for the none technical users who are used to the helpdesk fixing stuff for them it can be a bit of a shock.

I would describe O365 as just OK, not great but not terrible either.

It has a thin veneer of simplicity that means every other required admin task requires powershell to unlock most of the real administration - which of course means that everything takes a really long time.

We are talking several hours to complete some tasks that used to take seconds locally.

In the end, while it will not decrease your admin staff workload, it will take much of the stress away.

Level 13

There is always a "got you moment"  plan plan and more planning.

Level 14

We have a hybrid solution with 50,000 students on Office365 and 5000 staff on prem Exchange 2010.  The student migration went well.  We are now planning the staff one.  That will be much more complex with all the distribution lists, public folders etc.  Once they are gone we will upgrade the on prem to Exchange 2016 and keep high volume mailboxes on these.  We have also rolled out Yammer and OneDrive to students and Teams to some staff who have already been moved.  Skype will follow for staff.  All the licences are free at present but I suspect that won't last and the invoice will be large and unexpected for management.  I also expect the staff will be much more critical of speed and it will be interesting when they ask for an e-mail they have deleted to be restored (an all too frequent request  -  you know the one  -  I need to get back an e-mail, I don't remember when it was sent, what the subject was or who sent it but I need it NOW). 

Your concern about "deleted email" in O365 is also one of the things I stress when talking to clients who think about moving to O365. There are some backup solutions out there that provide longer retention periods than Microsoft but you need to take those into the budget planning as well.

"All the licences are free at present" is typical for Microsoft (excuse me Cloud-providers in general). We initially had 250 seats of BPOS (some of you might still remember this) for free as a "starter" for selling Microsoft online services. with a 10 ppl company we didn't use more than 15 seats for this (we set up some shared mailboxes as regular users to be able to sync those to mobile devices). Gladly we didn't go nuts on Mailboxes as the count of the freebies was reduced to 10 and then to 0.

I don't want to complain about this, I am happy with O365 now and we are adopting the broad variety of O365 Services, but don't fall for the "it's free" mentality. Calculate your costs and decide.

Level 20

I think Rick aka rschroeder​ sums it up pretty well since he has a HUGE healthcare network with most or many moved to O365.  His experience with what the users have said pretty much sums it all up.  Yes it's cheaper... but there's a big price you pay that's hard to quantify in it's negatives.

In a word:  "Yes."


Nice write up and comments; we have been toying with o365; it is FIPS compliant, so it does meet our organization security requirements.

I do like taking a little stress out of the mix; I really don't care to be hosting exchange inside my house!

One important detail we overlooked during our migration was the implementation of a security hierarchy. When the migration was done we found that we had way too many people with Admin privileges. And people who had no business having admin privileges. It took over a year to roll them back.


Wow - I ran into that same issue when I created my DR Site (private cloud)!   Found out that my "company" users owned the world.  I have since fixed.  Even my DBA and Application Managers now have a service account and a user account. 

I have been cautioned about 2012 R2 and administrative accounts; AD tends to shut down those administrative accounts.

Here is a link about implementing least-privilege admin models

Implementing Least-Privilege Administrative Models | Microsoft Docs

I just love this part:

The Privilege Problem

The principles described in the preceding excerpts have not changed, but in assessing Active Directory installations, we invariably find excessive numbers of accounts that have been granted rights and permissions far beyond those required to perform day-to-day work. The size of the environment affects the raw numbers of overly privileged accounts, but not the proportion mid sized directories may have dozens of accounts in the most highly privileged groups, while large installations may have hundreds or even thousands. With few exceptions, regardless of the sophistication of an attacker's skills and arsenal, attackers typically follow the path of least resistance. They increase the complexity of their tooling and approach only if and when simpler mechanisms fail or are thwarted by defenders.

Unfortunately, the path of least resistance in many environments has proven to be the overuse of accounts with broad and deep privilege. Broad privileges are rights and permissions that allow an account to perform specific activities across a large cross-section of the environment- for example, Help Desk staff may be granted permissions that allow them to reset the passwords on many user accounts.

Deep privileges are powerful privileges that are applied to a narrow segment of the population, such giving an engineer Administrator rights on a server so that they can perform repairs. Neither broad privilege nor deep privilege is necessarily dangerous, but when many accounts in the domain are permanently granted broad and deep privilege, if only one of the accounts is compromised, it can quickly be used to reconfigure the environment to the attacker's purposes or even to destroy large segments of the infrastructure.

Pass-the-hash attacks, which are a type of credential theft attack, are ubiquitous because the tooling to perform them is freely available and easy-to-use, and because many environments are vulnerable to the attacks. Pass-the-hash attacks, however, are not the real problem. The crux of the problem is twofold:

    1. It is usually easy for an attacker to obtain deep privilege on a single computer and then propagate that privilege broadly to other computers.
    2. There are usually too many permanent accounts with high levels of privilege across the computing landscape.

Even if pass-the-hash attacks are eliminated, attackers would simply use different tactics, not a different strategy. Rather than planting malware that contains credential theft tooling, they might plant malware that logs keystrokes, or leverage any number of other approaches to capture credentials that are powerful across the environment. Regardless of the tactics, the targets remain the same: accounts with broad and deep privilege.

Granting of excessive privilege isn't only found in Active Directory in compromised environments. When an organization has developed the habit of granting more privilege than is required, it is typically found throughout the infrastructure as discussed in the following sections.

OH... burn.....


Ah the joys of least privilege...

Then comes the fun annual audit of all service and elevated privilege accounts to make sure those privileges are still needed.

You do that don't you ?

Level 14

They did that here and decided that about 200 role based accounts should be deleted.  I urged caution (i.e. disable them for a while to see what broke but did they listen  -  NO).  Cue chaos as all sorts of scheduled tasks, scripts, backup jobs and applications failed.  We are still fixing problems.  Fortunately they did keep a list of what was deleted, just not what access rights they had. 


Ah...knee jerk reaction.

Account provisioning is like anything has to be documented and backout methods provided when changes are made.

I have seen that same thing bite hard at more than one company...sometimes they disable to see who screams and other times they just rip off the band-aid.

We went through a merger right around the same time we moved to O365. Not all of our affiliates, for business reasons, immediately moved over. So when I went to engage the infrastructure team for a DR test completely oblivious to the fact that we weren't all the way in the Cloud. Details. Dirty, dirty, details have kept us from fully going into the Cloud.


Absolutely!  Doesn't Everyone???   I can honestly say that I now know who has what, and whos on first!

It was not an easy task to take back control, .... but I work in a smaller environment than most of you all, and I was able to get the job done.

Level 14

We enlisted a third paarty (well known reseller) to assist as we were migrating from an on-prem non-exchange environment. All in all 95 out of 100.. Problem spots: calendars, contacts and large mail stores. 4 months in we are still dealing with 1-2 small issues, but a huge win for us. (as for accounts - as soon as the consultant left, I went through them top to bottom).

Level 9

Thanks! The topic as a whole could easily fill a book.

Level 9

There is one piece of advice I give on the topic of stress and SaaS solutions: although it may not be your problem to fix it if the service is down (e.g. you can't fix the provider's infrastructure), it is still your problem to deal with. Users typically don't care why a service is down. On the flip side, providers hopefully have more resources that they can throw at a problem then you would in-house.

Level 9

I had a similar experience - that vast majority of it went OK, but we ran into a few small issues. Things like shared calendars, or missing public folder permissions. Although none of them were huge problems, the time spent fixing small problems adds up.

What I have found helped us was identifying the common issues (e.g. missing permissions) and writing a PowerShell script to remediate. We would pop the relevant info into variables and then run the script. Although we weren't being proactive in finding these things, we at least quickly, and consistently fixed the issues as they popped up.

Level 21

We use O365 and have helped to deploy it for clients as well.  I can personally say I have had a positive experience with it with one exception; running mail in a hybrid mode, I would strongly recommend against this as it causes an administrative nightmare.

Level 9

Interesting insight - could you elaborate? Was it just hard to keep track of what account was where? Or was there more to it than that (e.g. separate policies, etc.). I'd love to hear more.