How to Migrate the Department of Defense to Office 365

Learn how to meet your agency’s compliance requirements with our free Nara Resource Kit. Claim yours here!

---

This is the 8th installment in a series addressing the challenges facing the DOD as they move into Microsoft 365. The others are here:

• The DOD’s Cross-Command Telework Platform (CVR) Expires Soon: What’s Next?
• Considerations for Governance in DOD365
• Is Zero Trust Enough to Secure Your Data?
• How Teleworking and the CVR Affect Records Management for the DoD/IC
• How to Prepare for Unified Labeling in Microsoft 365 DoD
• Backup & Retention Policies for Microsoft 365: Why the DOD Needs Both
• Smart Data Governance Lessons Worth Learning From the CMMC
• What to Use When for Secure Microsoft 365 Collaboration

It goes without saying that the logistics of merging or breaking up two organizations can be tricky. A simple merger/acquisition in the commercial space can span years of coordinating systems, data discovery, and migration. It’s easy for data and users to get lost in the shuffle if the proper planning and validation procedures aren’t put in place at the beginning.

In that same vein, the Department of Defense has two big challenges on its hands:

1. The divesture of the million cross-command users in the CVR environment, and
2. The continued merger of command collaboration environments across each branch of the DOD into centralized tenants for each branch.

An effort to merge multiple commands into a single collaboration environment poses its own challenges such as information architecture, bad or stale data, ownership, and identification of authoritative sources, throttling, etc. In CVR especially, dozens of commands and agencies across the DOD have their data intermingled into a single temporary Office 365 tenant, and divesting these into their own branch-specific tenants will be a daunting challenge for those that want their data out to coordinate A) which data is whose, B) where their data is, and C) where it needs to go.

With that in mind, CVR has been labeled as temporary and the government’s official position is that the environment and data that resides within will be deleted in June 2021. Some commands may accept this fate while others may want to take steps to retain their collaboration data that’s been created through the life of the environment.

Now, be it divesting from CVR or merging into a centralized tenant, you must consider two things:

1. How do you approach migrating your data?
2. What technology do you use?

The Approach

Whether you migrate using custom scripts, a database detach/reattach, or a third party tool, the first step in migration is to figure out your approach. Below is the approach AvePoint takes for our customers using 20 years of migration and double-digit petabytes of data transferred.

Discovery

In the case of tenant to tenant migrations, the first thing an admin has to consider is which tenant is moving where. Work through your Enterprise Agreement and licensing with Microsoft. Ask yourself the following:

• Which licenses do your users have?
• What Microsoft workloads are your users using?
  • While CVR users are using Teams, the migrating data is coming out of SharePoint. A CVR Team’s data would migrate into a SharePoint on-premises or IaaS SharePoint instance

• Does your destination tenant have the same workloads set up and proper licenses?
  • CVR only has Teams turned on, while your new tenants may have Planner, SharePoint, Power Platform, and more turned on

In the case of on-premises to cloud migrations, the conversations are a little different:

• What content restrictions have our organization put on the cloud?
• Are all of our workloads in SharePoint on-premises supported in SharePoint Online?
• What workloads in the cloud should we consider in refactoring our solutions (Teams, Groups, Planner, Power Platform, etc.)?

One additional realization many organizations have is that the cloud may not be the ONLY solution they need–in which case creating a modern on-premises solution, such as SharePoint 2019, becomes a reality and hybrid considerations must be made.

The next step is to run pre-discovery, which will give you a sense of how much content you have, what type of content you’re working with, and how “fresh” your data is. Based on that, you can review your environment and determine what you’re going to move, how much you’re going to move, and where it’s going to be moved to.

NOTE: If you are in a shared environment like CVR, make sure your discovery tool can run with the permissions you have (e.g. AvePoint’s discovery capabilities only need Site Collection Administrator and can be run against just the Site Collections you have control over).

Planning an O365 migration for the DoD? This post should help: Click To Tweet

Plan

Now it’s time to put together a plan for transitioning users and moving the content. Naturally, there’s some change management that needs to happen; you don’t want your users to wake up one day and see all their documents shifted to a new solution and be missing or have new workloads enabled.

The main goal of migration planning is to help mitigate any disruption to your end users and allow them to feel prepared for the switch.

Once you have laid out the beginnings of your change management plan (this will probably change as your migration continues), we suggest a multi-step approach; first moving the majority of user content over to the destination using a full migration, then allowing a transition period when there’s some overlap and users have access to both tenants. During this transition period, you can perform an incremental migration to carefully bring over any loose ends or changes before a user is fully cut over to the new tenant.

This is usually a gradual process that’s often performed in groups. Depending on the size of the migration (department, command, unit, etc), we recommend bringing like groups over together (e.g. the J-6-2 or a particular unit in the field) based on how they use the solutions.

Lastly, we highly recommend performing a pilot first with people who are technologically inclined and willing to test things out with you. Not only does a pilot enable you to validate the design of your destination, but it allows you to validate assumptions in your planning such as what throttling will look like, how the command infrastructure affects the migration speed, and if your user or content mappings work as expected.

Move the Data

Migration jobs often require multiple iterations to migrate everything (e.g., locked files, no destination user, etc.), so it’s vital to do analyses on all jobs that do not fully complete (i.e. jobs that complete with exceptions or just plain fail). These exceptions and failures can be due to a multitude of factors such as:

• Connection problems
• File types
• Size limits
• API limitations (likely on the source side)
• And more

It’s highly recommended to fully understand any limitations that are published on both the source and destination side. Oftentimes these are out of your control or that of your tool vendor, so this will help set the expectation with leadership at the onset of your migration project.

Consider the “move” a continuous loop until the project is complete and ensure that you plan for some content requiring a few passes before everything gets fully moved. Content is always going to change if users are active, and that’s okay!

Before you declare that you’re fully migrated, make sure you confirm that all the content that can be moved has gone through successfully. Third-party reporting tools can be helpful by directly telling you what’s moved and why something hasn’t moved.

Validate

Finally, you always want to validate that everything came over and review any errors that might’ve occurred during the move. This validation process will help you catch and manage anything that might’ve slipped through the cracks and carry out any lingering incremental migrations that need to be taken care of.

Note: This process will go more smoothly if users are trained to validate their own data post-migration. This is especially true if any kind of data transformation has occurred.

Common Pitfalls to Avoid

Not planning change management with your users.

DISA supports over 3.5 million defense and civilian workers, and the CVR alone is nearly 1 million. While a workforce of this size will be hard to coordinate, you can’t just move your users overnight without them knowing about it. Expecting CVR users to magically know how to use Power Automate and the SharePoint Online native interface will lead to confusion, and users coming from SharePoint 2010 or 2013 into Office 365 will find even more confusion when added to their first Microsoft Team.

A key success factor in any migration is ensuring minimal disruption to your users’ workday, and it can make things much smoother if they know that their technical team is respecting that!

This means not only training but defining the “What’s In It For Me?” factor. How will the new environment better support mission success? How do new tools increase efficiency? How do I create a collaboration space that enables collaboration with other commands or with outside mission partners? Answering these questions early will not only aid in the setup of your environment but in easing the frustration a new tool often brings.

Not giving yourself enough time to migrate everything.

Migrating content should never happen during working hours, however, the CVR environment is expiring in 7 months. The time is now to plan fast, execute, and adjust as you go.

Ideally, schedule the jobs so they run overnight or over the weekend. This not only aligns with best practices from Microsoft but keeps your users’ tenants running at full capacity during the workday. Trying to squeeze a substantial migration into a short period of time will only have negative effects, such as:

• Disrupted users
• A slower tenant if too much throttling occurs
• Potential for “missing” content if there’s not enough time to remediate errors or perform validation
• Not enough runway to prepare users for what’s new or coming soon
• And so on

Given the short runway with CVR’s expiration, try migrating priority content first and only very necessary data (i.e. content that is considered “active”).

Though migrating Office 365 data can be tricky, I hope this article helps make the process go a bit smoother. And while you’re planning your migration, have you thought about how you’re going to manage the gradual influx of new users?

CVR was deployed full and open. There was no need for governance because it wasn’t a permanent system or one approved as a system of record. Moving out of CVR and into your command or agency’s permanent system means you now own the responsibility. Is there a governance plan in place for the long-term management of Teams, records, and data retention?

The Migration Toolset

Ever wind up naming a Microsoft Teams channel and needing to change it later? Or have you needed to be part of a Team that has a structure that needs to adapt to better match a business process or departmental structure? It’s possible to restructure Microsoft Teams and channel chats to change the way a Team is organized AND to make sure that the “Files” folder in SharePoint has a name to match the channel in question.

Whether you are migrating from SharePoint on-premises or SharePoint Online in the CVR, a solid third-party tool like FLY provides years of best practices with a User Interface designed to make this easy.

Connecting to your Environment with AvePoint FLY Migrator

AvePoint’s tools use the App Profile mode, wherever possible. For on-premises to cloud migrations, this model covers most of what a command migration will include. However, how does a command migrate data out of an environment they do not own, such as the CVR or an environment like IntelLink?

FLY Migrator has been specially built to support multiple connection capabilities, but also with different permissions. In the case that your command is using a shared environment, you may be a Site Collection Administrator (SCA), but not a Farm or Service administrator. To handle this, FLY only requires SCA to pull your content out of an environment. Thanks to our partnership with existing DOD customers, FLY is also built to pause a migration job when the authentication model times out your user account, and restarts when that connection is restored!

Microsoft Teams Migration with FLY

For example, let’s take a look at what this can actually look like with a migration from one Office 365 Microsoft Teams (e.g. CVR) to another tenant of Teams.

To visualize this, let’s first look at our source tenant with the user’s domain highlighted. Note the user and time stamp information for the Teams chats:

We set up the Team mapping in the FLY solution; in this scenario, FLY will automatically create the new Team in the destination:

Now we run the migration and check out our new Team in the destination!

Great! Now the text, times stamps, and information from the original post have been migrated into the destination Team!

AvePoint’s FLY solution can move information from SharePoint On-premises, SharePoint Online, Microsoft Teams channel chats, or Slack channels into another Team and into SharePoint Online.

FLY provides a comprehensive pre-scan to validate supported and unsupported elements, identify large files and problem structures, review permissions, and provide insight into what might be mapped.

It allows you to create filter policies so migration jobs can move SharePoint Online-approved content to one destination and not approved content to another destination. You can build schedules to avoid work hours or throttling issues, especially where multiple commands are migrating in over the same period of time. And FLY supports SharePoint 2010, 2013, 2016, and 2019 into SharePoint 2016, 2019, or SharePoint Online.

---

Keep up with all things Office 365 by subscribing to our blog!