Case Studies / Tooling & Infrastructure
Google Workspace Tenant Consolidation Orchestrator
When companies acquire, merge, or reorganize, their Google Workspace tenants rarely do. This platform provides the operational infrastructure to plan, discover, and execute tenant consolidations properly.
The Problem
When an MSP's client acquires another company, spins off a division, or reorganizes its business, the Google Workspace tenants involved rarely consolidate themselves. Users, groups, shared drives, delegated access, and email routing all need to be inventoried, mapped, and moved across tenant boundaries.
The actual data movement tools — CloudM and similar platforms — handle the transfer once a project is properly configured. What they do not provide is the operational layer before and around that work: Who has been discovered in the source tenant? Which accounts are mapped to the target? What is the state of each consolidation project? What needs to be resolved before the migration tool can run cleanly?
For MSPs managing several tenant consolidations at once, the answers to those questions typically live in spreadsheets, email threads, and the memory of whoever ran the last project. There is no repeatable workflow, no audit trail, and no structured handoff between discovery, planning, and execution.
Our Approach
Rather than solving this once for a single engagement, we identified the operational patterns common across Google Workspace consolidation projects and built structured tooling around them.
The Consolidation Orchestrator provides a purpose-built environment for tenant consolidation projects. It connects to source and target Google Workspace tenants, performs read-only discovery and inventory, tracks project state, and establishes the structured workflow that consolidation work requires before any migration tool is run.
This was built from direct experience running consolidations, not adapted from a generic project management platform. The data model, the connection architecture, and the execution model all reflect how Google Workspace tenants actually need to be handled during a consolidation.
Discovery before action. Inventory before execution.
The platform enforces read-only discovery as the first phase of every project. Nothing is written to a tenant until inventory is complete and the project state is explicitly advanced. This is not a UI convention — it is enforced at the API level.
Architecture
The platform is a modular monolith (.NET) with a React frontend, PostgreSQL for project state and audit records, and a separate Windows Runner for operations that require a Windows execution boundary.
Project Overview
The Project Overview shows readiness across tenants, directory discovery, and identity mapping before any migration tooling is involved.
Capabilities
Current capabilities reflect the project setup and discovery phase. Migration execution capabilities are in development.
Tenant Inventory (after Discovery)
Inventory is collected by read-only discovery against the connected tenant. Nothing is written during this phase. All figures above are illustrative.
Identity Mapping
| Source user | Destination user | Status |
|---|---|---|
| alice@legacyco.com | alice.chen@northfield.com | Mapped |
| bob@legacyco.com | bob.harrison@northfield.com | Mapped |
| carol@legacyco.com | No match found | Collision |
| david@legacyco.com | david.park@northfield.com | Mapped |
Identity Mapping resolves source users to destination accounts before any migration tool runs. Collisions surface ambiguous mappings for human review.
Current Status
The platform is in active development. Google Workspace tenant connection, discovery, and inventory are operational. Microsoft 365 tenant support, execution workflows, access remapping, and post-consolidation validation are planned next phases.
This was built from direct consolidation experience rather than for a single client engagement. The architecture is designed to support multiple concurrent projects or, potentially, to be offered as a standalone product for MSPs running consolidations as a service.
Design Philosophy
Migration projects carry real risk. The data being moved belongs to the client's customers. An error in a migration is not a billing adjustment — it is a data integrity problem or an access failure that affects end users.
The platform is designed with that risk in mind. Read-only discovery cannot accidentally modify a tenant. OAuth scopes are explicit and minimal. The Windows Runner runs in a separate boundary so a failure there cannot affect the core API. Every action is logged so a project can be reconstructed from state history.
This is the same control philosophy applied in the MSP billing platform. Automate the repeatable work. Keep consequential actions staged and auditable. Build the structure that makes it safe to move fast later.
Your Migrations
Running tenant consolidations without structured tooling costs more than you think.
If your Google Workspace consolidation workflow still relies on spreadsheets, manual checklists, or tribal knowledge, let's talk about what purpose-built tooling would look like for your team.