diff --git a/clients/birth-biologic/docs/migration/google-to-m365-scope.md b/clients/birth-biologic/docs/migration/google-to-m365-scope.md new file mode 100644 index 00000000..1915c917 --- /dev/null +++ b/clients/birth-biologic/docs/migration/google-to-m365-scope.md @@ -0,0 +1,72 @@ +# Birth Biologic — Google Workspace → Microsoft 365 mail migration (scope) + +Scoping doc for moving Birth Biologic's live mail off Google Workspace onto their existing M365 +tenant. Started 2026-06-25. Process reference: `projects/msp-tools/runbooks/google-workspace-to-m365-migration.md`. + +## Why now / current state + +Birth Biologic has an **M365 Business Premium** tenant (`birthbiologic.com`) with **mailboxes +already provisioned**, but **mail still flows to Google Workspace** — i.e. they're half-staged for a +cutover that was never finished. Confirmed 2026-06-25: + +- **M365 tenant:** `birthbiologic.com` (Business Premium). 13 licensed EXO mailboxes provisioned. +- **MX:** → **Google Workspace** (`aspmx.l.google.com` + alts) — **live mail is on Google, not M365.** +- **DNS host:** **SiteGround** (`ns1/ns2.us92.siteground.us`). **Registrar:** **Name.com.** +- **Web:** `www` → Google Cloud `35.215.115.203` (separate from mail; not in scope). + +## Prerequisite status (gates) + +| Prereq | Status | Notes | +|---|---|---| +| **Google super-admin on source tenant** | **MISSING — must obtain** | No Birth Biologic Google creds in the vault (only RMM enrollment). ACG's `acg-msp-access` SA is **not** delegated to `birthbiologic.com`. **This is the #1 blocker.** | +| M365 target mailboxes provisioned | **Mostly done** | 13 mailboxes exist; verify licensing covers everyone who needs mail (see the 2 enabled-no-mailbox accounts below). | +| Domain verified in M365 | Assumed (tenant uses `birthbiologic.com`) | Confirm the domain is verified and ready to receive (don't cut MX yet). | +| DNS edit access for MX cutover | **Pending** | SiteGround DNS — Mike accepting the SiteGround **collaborator invite** (released from EOP quarantine 2026-06-25). Registrar Name.com (for NS only; MX lives in SiteGround zone). | + +## Target (M365) mailbox inventory — known + +**13 provisioned EXO mailboxes:** Alicia Meneely, Ashley Williams, Brandy Burgess, Christina Cox, +Julie Beck, Kristin Steen, Lastashia May, Mary Ster, Mindi Maher, Savanna Abron, Vicki Fountain, +plus `operations@` and `sysadmin@` (Computer Guru). + +**2 enabled accounts WITHOUT a mailbox** (decide before migration): **Mei Mei Senthavy** +(`msenthavy@`), **Valerie VanEaton** (`vvaneaton@`) — enabled, no license/mailbox. If they're active +mail users on Google, they need a license + mailbox provisioned as migration targets. + +**Disabled / former staff** (no migration): Ally Boutte, Anica Raso, Phim Nelson, Kaileigh Hoffman. +**Guests (external, not migrated):** `christyrogers@trainingumbrella.com`, `clients@calm-ops.com`. + +## Source (Google) inventory — TODO (needs Google admin) + +Once super-admin access is obtained, pull from the Google Admin console: +- Full user/mailbox list + **sizes** (drives migration time), and reconcile against the M365 target list. +- **Shared/delegated mailboxes**, **groups/distribution lists**, **aliases**, **calendars/resources** — + recreate in M365 deliberately (don't assume they come across as user mailboxes). +- Who is actually active (esp. Mei Mei / Valerie). +- Any retention/legal need before Google decommission (no PHI noted, but confirm). + +## Proposed method + +**MS native "Migration from Google Workspace"** (free, mail + calendar + contacts, delta sync) — the +default per the runbook. Birth Biologic is a small org with target mailboxes already in place, so the +native path fits cleanly. Reuse the `acg-msp-access` SA by adding its client_id + the migration scopes +to Birth Biologic's domain-wide delegation (needs their Google super-admin), or create a per-job SA. + +## Cutover sequence (planned) + +1. Obtain Google super-admin; vault it (`clients/birth-biologic/google-workspace.sops.yaml`). +2. Enable Gmail/Calendar/Contacts/Directory APIs; add SA domain-wide delegation w/ migration scopes in Birth Biologic's Google Admin. +3. Provision/license any missing target mailboxes (Mei Mei, Valerie if active); recreate shared mailboxes/groups. +4. Confirm `birthbiologic.com` verified in M365 (no MX change yet). +5. EAC → migration batch (Google Workspace) → CSV of mailboxes → initial + incremental sync; validate. +6. Lower MX/autodiscover TTL in **SiteGround** DNS. +7. **Cutover:** flip MX → M365, update SPF (`include:spf.protection.outlook.com`), enable/publish DKIM (2 CNAMEs), autodiscover CNAME → `autodiscover.outlook.com`, review DMARC. Final delta sync. Finalize batch. +8. Reconfigure clients to M365; remove Google licenses; remove SA delegation; cancel Workspace. + +## Open questions for Mike / client + +- **Can we get Google super-admin** on Birth Biologic's Workspace tenant (from the client / Annise)? Without it the native + IMAP paths are blocked. +- Are **Mei Mei Senthavy** and **Valerie VanEaton** active mail users (need mailboxes), or dormant? +- Any **shared mailboxes / groups / aliases** on the Google side to recreate? +- Desired **cutover window** / acceptable brief mail-delivery delay during MX propagation. +- Migrate **calendar + contacts** too (native does), or **mail only**? diff --git a/errorlog.md b/errorlog.md index 5a0f73a2..e65e275a 100644 --- a/errorlog.md +++ b/errorlog.md @@ -17,6 +17,8 @@ Categories (the `[type]` tag): _(none)_ = skill/command execution failure · +2026-06-25 | GURU-5070 | vault/display | [friction] echoing a vault entry, sed line-redaction missed the multi-line JSON private_key (matched 'key:' not 'private_key": "') and printed the full SA private key; when displaying vault entries use vault.sh get-field for named fields or drop the entire credentials: block, never a line-regex over JSON credential blobs + 2026-06-26 | GURU-BEAST-ROG | email-investigation | [correction] assumed tedards.net also uses GuruProtect/Inky; correct: only ACG uses Inky for inbound. Tedards routes directly to Exchange Online. 2026-06-25 | Howard-Home | wiki-compile | [friction] Sonnet subagent hit 32k output-token cap regenerating full ~600-line article via Write; wrote nothing [ctx: fix=targeted staged edits of deltas for large existing articles, not full regen] diff --git a/projects/msp-tools/runbooks/google-workspace-to-m365-migration.md b/projects/msp-tools/runbooks/google-workspace-to-m365-migration.md new file mode 100644 index 00000000..9b02def3 --- /dev/null +++ b/projects/msp-tools/runbooks/google-workspace-to-m365-migration.md @@ -0,0 +1,110 @@ +# Runbook: Google Workspace (Gmail) → Microsoft 365 mail migration + +Reusable ACG process for moving a client's mail (and optionally calendar/contacts) from Google +Workspace to Exchange Online. Covers method selection, prerequisites, the native Microsoft path +end-to-end, the MX cutover, and gotchas. Author: 2026-06-25 (first written while scoping Birth +Biologic). Status: working draft — refine after the first real run. + +--- + +## 1. Pick the method + +| Method | Moves | Cost | When to use | +|---|---|---|---| +| **MS native "Migration from Google Workspace"** (EAC) | mail + calendar + contacts, with incremental/delta sync | **Free** | **Default.** Need Google super-admin to set up a service account + domain-wide delegation on the source tenant. | +| **IMAP migration** (EAC) | **mail only** | Free | Fallback when you can't get domain-wide delegation. Gmail labels→folders get messy; no calendar/contacts. | +| **BitTitan MigrationWiz** (3rd-party) | mail + cal + contacts + Drive, coexistence, best throttling/reporting | ~$12–15/mailbox | Larger/complex jobs, strict cutover windows, or to make this a repeatable productized service. **ACG has no BitTitan account yet.** | +| **Takeout MBOX / Gmail→PST → 365 PST Import** | mail only, one-shot | Free | Last resort / archival only. Manual, per-mailbox, no delta, fidelity loss. Avoid for live cutovers. | + +Default to the **MS native** path below. + +--- + +## 2. Prerequisites (all methods) + +- **Google super-admin** on the SOURCE Workspace tenant (for the SA + domain-wide delegation, or an app password for IMAP). **This is the #1 gate — confirm it before quoting timelines.** +- **M365 target tenant** with the client's domain **added and verified** (do NOT cut MX yet), and **licensed mailboxes provisioned** for every user being migrated. +- **DNS control** for the MX/autodiscover/SPF/DKIM cutover — know the registrar AND the DNS host (often different). Get edit access ahead of time. +- **Inventory** (from the Google Admin console): user list + mailbox sizes, shared mailboxes / delegated mailboxes, groups/distribution lists, aliases, calendars/resources, and who's actually active. +- **Vault** the source Google admin creds / SA per the ACG pattern (see §6). + +--- + +## 3. ACG reusable asset — the Google domain-wide-delegation SA + +ACG already has a Google service account for Workspace access: +`msp-tools/acg-msp-access-google-workspace.sops.yaml` → +`acg-msp-access@acg-msp-access.iam.gserviceaccount.com` (GCP project `acg-msp-access`). +- Currently scoped for the **security-assessment** read path (`gmail.readonly`, `drive.readonly`, + `admin.directory.user`, `reports.audit`, etc.) and **onboarded only to lonestarelectrical.net**. +- For a **migration** you can reuse this SA (or create a per-job one) — but the migration needs the + **migration scopes** added to the SA's **domain-wide delegation in the SOURCE client's Google Admin + console**, not just ACG's project. Microsoft specifies the exact scopes (see §4 step 1). +- Reusing the same SA across clients is fine; each source tenant separately authorizes the SA's + `client_id` in *their* Admin console. Keep the key in the vault; rotate per the entry's notes. + +--- + +## 4. MS native migration — end to end + +**Step 1 — Source (Google) prep** +1. In **GCP** (project `acg-msp-access` or a new one): ensure the service account exists and a JSON key is in the vault. Enable APIs: **Gmail, Google Calendar, Google People (Contacts), Admin SDK (Directory)**. +2. In the SOURCE **Google Admin console** → Security → API controls → **Domain-wide delegation** → add the SA **Client ID** with the Microsoft-required OAuth scopes (Gmail/Calendar/Contacts/Directory — copy the exact scope list from the EAC migration wizard so they match). +3. Confirm a Google super-admin mailbox exists for the migration to impersonate. + +**Step 2 — Target (M365) prep** +1. Add + **verify the client domain** in M365 (TXT). Do **not** change MX yet. +2. **Provision + license** every target mailbox (match Google addresses). Create any missing ones. +3. (Optional) pre-create shared mailboxes / distribution groups to mirror Google. + +**Step 3 — Create + run the migration batch** +1. EAC → **Migration → Add migration batch → "Migration from Google Workspace."** +2. Provide the **SA JSON key** + the super-admin to impersonate; upload a **CSV** of mailboxes + (`EmailAddress` of each source/target — they match on the verified domain). +3. Start the batch → **initial sync**, then it keeps doing **incremental/delta** passes. Leave it + running (days for large mailboxes). Monitor the batch report for skipped items. + +**Step 4 — Validate** +- Spot-check a few migrated mailboxes (mail counts, folders, calendar, contacts). Resolve large + skipped-item counts before cutover. + +**Step 5 — MX cutover (the go-live)** +1. **Lower TTL** on MX (and autodiscover) at the DNS host 24–48h ahead. +2. Flip **MX** → M365 (`-com.mail.protection.outlook.com`), update **SPF** + (`include:spf.protection.outlook.com`), republish **DKIM** (enable in Defender, add the 2 CNAMEs), + set **autodiscover** CNAME → `autodiscover.outlook.com`, review **DMARC**. +3. Run a final **incremental** sync after cutover to catch mail delivered to Google during propagation. +4. **Complete/finalize** the batch. + +**Step 6 — Decommission** +- After a validation window: reconfigure clients (Outlook/mobile to M365), remove Google licenses, + remove the SA's domain-wide delegation from the client's Admin console, cancel Workspace. + +--- + +## 5. Gotchas + +- **Labels → folders:** Gmail labels become folders; a message with multiple labels can duplicate. The + native tool handles the primary label; expect minor structure differences. +- **Shared / delegated mailboxes, groups, aliases, calendars/resources** don't all come across as + "mailboxes" — inventory and recreate them in M365 deliberately. +- **Throttling:** Google + EXO both throttle; large tenants take days. Don't promise same-day. +- **SPF/DKIM/DMARC:** must be updated at cutover or outbound mail fails auth / inbound double-delivers. +- **Don't cut MX early** — mail in flight to Google after an early MX flip is missed until the final delta. +- **Calendar/contacts** only migrate via the native tool or BitTitan, NOT via IMAP. +- **Retention/litigation hold:** if the client needs Google data retained, export before decommission. + +## 6. Credentials & vault + +- Source Google admin / SA: vault under `clients//google-workspace.sops.yaml` (see + `clients/lonestar-electrical/google-workspace.sops.yaml` for the shape) or reuse + `msp-tools/acg-msp-access-google-workspace.sops.yaml` (note which clients it's delegated to). +- **Never echo the SA JSON / private key in chat** — read named fields with `vault.sh get-field`, + not a regex over the whole blob (a line-redaction missed a `private_key` once — errorlog 2026-06-25). +- Target M365: the client's tenant-admin path (CIPP / remediation-tool / GA). + +## 7. Make it a service (future) + +If Google→365 jobs recur, decide: standardize on the **native** path (free, this runbook) vs. buy +**BitTitan** (productized, per-mailbox, coexistence). Promote this runbook to a wiki pattern via +`/wiki-compile` once proven on the first real migration.