I85PREP
⌘ K
CC-CEM study materials
CC-CEM study resources

CC-CEM: Migration, Administration and Operational Governance

CC-CEM · Work through your exam, one topic at a time.

All guide sections

Migration, Administration and Operational Governance

This domain tests execution: choosing a migration method, sequencing the cutover, and running the tenant afterwards so it does not quietly decay. Questions are usually about ordering, prerequisites, and the hygiene tasks that prevent incidents.

Migration methods

  • Cutover - one batch, one MX switch; simplest, suitable for small organisations and short windows.
  • Staged - batches over time with coexistence routing; requires directory objects and connectors.
  • Hybrid - shared namespace with rich coexistence; preserves directory authority and mailbox moves.
  • IMAP or provider-to-provider - used when the source is not Exchange; slower, no rich coexistence.
  • PST or file import - for archives and leavers.

Every method depends on the same prerequisites: domain verification, licences assigned before provisioning, directory sync healthy, TTL lowered in advance, SPF/DKIM updated for the new egress, and a plan for shared mailboxes, distribution lists, and aliases.

Cutover mechanics

Lower the MX TTL to a few minutes at least 48–72 hours ahead so old cached values expire quickly. Provision users first, run a delta sync until the residual change set is small, then switch MX. Keep the source system read-only for a defined period and route the old domain as an accepted domain to catch stragglers.

Operational governance

  • Role assignments reviewed quarterly; no standing global admins beyond a documented break-glass pair.
  • Recurring hygiene reports: inactive mailboxes, external forwarding, connector inventory, DKIM key age, allow-list entries, mail-enabled security group membership.
  • Change management with a rollback path for MX, connector, and transport-rule changes.
  • Retention is not backup: define restore expectations separately.

Worked example

A 300-mailbox cutover from another cloud provider. Lower TTL 72 hours out; create users and assign licences; pre-stage mailboxes and set target addresses; run incremental syncs until the delta is under a few hundred items; update SPF to include the new egress and publish DKIM selectors; switch MX; verify inbound and outbound with test messages from external domains; leave the old provider read-only for 30 days. Reasoning: the delta sync run before the switch is what keeps final cutover downtime to minutes rather than hours.

Traps

  • Switching MX without lowering TTL, then waiting on cached records.
  • Forgetting to update SPF and DKIM for the new sending path.
  • Provisioning mailboxes before licences, losing soft-deleted content.
  • Treating native retention as a backup strategy.