The Keys to Our Own Kingdom: Inside the CMS Email Migration
There’s a famous proverb, sometimes ascribed to Desmond Tutu, that the best way to eat an elephant is one bite at a time. Well, what if you only have a three-day weekend? And instead of eating an elephant, you are migrating an entire federal agency’s email system?
We asked Martin Wilson, the Information Systems Specialist and Technical Advisor in OIT’s Infrastructure and User Services Group (IUSG) how he, along with his Leidos support partner, pulled off the monumental feat of managing the CMS migration to its own Microsoft 365 email tenant over Labor Day weekend.
Below you’ll find some of his reflections on how the migration came about, what benefits it will bring to the CMS end-user community, and how his team coordinated with partners across the agency.
Reasons for the Migration: In 2005, we migrated to Outlook, and that’s when we consolidated our system with HHS. The hope was if we all got together in a federated arrangement with other agencies, we could reduce the financial impact of deploying different Microsoft products. As it turned out, CMS was the only one that made that jump – all the other agencies decided to keep their email in-house.
By sharing a tenant with HHS, we were tied to their decisions about Microsoft features and functionality. Our agencies had different concerns and priorities, and CMS often couldn’t implement features we believed would add value in our environment. About two years ago, Mark Oh, the IUSG Group Director, brought it to my attention and said, “I think it’s time to migrate.” We were coming up on the end of our ELA (Enterprise License Agreement), and we saw that as a good opportunity to make it happen.
Size and Scope: The migration transferred 17,000 mailboxes - including those belonging to 6,500 employees and 3,800 contractors – from a Microsoft 365 shared email system with HHS to CMS’s own tenant for the first time since 2005.
Challenges Overcome: We had never attempted a “one-and-done” approach. Previous migrations had all been phased in over time. So the logistical planning that went into this started two years ago and was quite extensive. We needed to be sure we accounted for the needs and expectations of all our customers. With emails as the lifeline of CMS communications with beneficiaries, providers, and stakeholders, there was little room for error, and we wanted to be sure we didn’t encounter any surprises. Timing as to when to do it was also a big challenge. We needed an extended weekend period to make this happen. Everything else was a matter of finding an additional partner that had experience with such a migration to help us implement it.
Who was Involved: Once CMS and Leidos had settled on an approach, we started interviewing third-party vendors to assist us in the migration prep and ultimately the migration itself. We settled on Planet Technologies, who we had worked with in 2016 on a previous Cloud migration project with HHS. They came on board as a partner, and we started the planning phase.
We worked along with HHS as one big team to figure out how involved this would be and during that process, we developed our plan forward. We also had Microsoft, FireEye and several other vendors we worked with along the way, as well as the CMS email team and Desktop Support, among others.
Benefits of a Non-Shared Tenant: Moving to our own tenant gives CMS the autonomy to offer our customers the tools we’ve purchased from Microsoft in a way that fits our end-user environment. Those tools include Teams, OneDrive and the Power Suite to name a few. On the back end, the main benefit is that we can now control our own environment and implement several of Microsoft’s security tools to help us mitigate cyber threats and risks to our environment firsthand.
Putting the End-User First: We didn’t want anyone to feel any major impacts, and our goal from the start was to put customers first. I was adamant about doing roadshows and getting out in front of people face-to-face, communicating to the agency as a whole, and putting minds at ease by saying, “Here’s what we’re doing, here is how it will impact you, and here are some things we need you to do along the way.” We did that prior to the migration to level-set the expectations.
Biggest Fear: One of the biggest fears for the agency, particularly senior leadership, was: What would happen if we did this one-and-done approach, and something didn’t work? The 2016 Cloud migration was a phased approach that allowed us to migrate a section of employees at a time. We decided this time to do a one-and-done kind of thing so that on Day 1 everybody would have access to their mailbox and other resources.
We did develop a backout plan and included a point of no-return in the migration schedule so that we could revert back to the HHS tenant if necessary. Things worked out pretty well and we never had to use it.
User Feedback: I’ve heard a lot of positive feedback. Everyone has been very excited about the fact that we migrated. The end user had some things to do on their end on Day 1 like logging into their mailbox for the first time and setting up their account on the new tenant. We made the process user-friendly, kept everybody informed, and provided detailed instructions. I appreciate everyone’s patience and support throughout the process.
One-and-done: Although the migration is finished, there are some clean-up activities we are doing. But aside from that, we are on our own tenant and operating in our own space. We have our own connection to the border directory, and we now hold the keys to our own kingdom.