> For the complete documentation index, see [llms.txt](https://oten.gitbook.io/kms-support/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://oten.gitbook.io/kms-support/google-cse-integration/google-cse-backup-and-re-wrap.md).
# Google CSE Backup & Re-wrap
### 1. What Problem Does This Solve?
You're using Google Workspace Client-Side Encryption (CSE) with **Key Service A** (e.g., Oten KMS). Now you need to switch to **Key Service B** (maybe upgrading to a new version, changing vendors, or consolidating services).
**The challenge:** Thousands of files are already encrypted with Key Service A. How do you switch without:
* Breaking access to existing files?
* Requiring users to re-encrypt everything manually?
* Causing downtime?
**The solution:** Google's **Rewrap** feature coordinates with your KMS providers to automatically re-encrypt all Data Encryption Keys (DEKs) in the background while users continue working normally.
***
#### Architecture Overview
Understanding the architecture helps clarify who does what during migration.
**The Three Players**
***
#### What "Backup" Really Means
> **Your Old Key Service remains connected so the New one can call it** to unwrap old DEKs during migration.
The "Backup" configuration does TWO things:
1. **For Rewrap:** Tells the New Key Service where to send `/unwrap` requests for old DEKs
2. **For User Access:** Allows Google to route decryption requests to Old Key Service for files not yet migrated
**The "Backup" is NOT:**
* A copy of your data
* A snapshot of your keys
* A disaster recovery mechanism
* Managed by Google
**The "Backup" IS:**
* Your Old Key Service that must stay running
* A configuration that enables Key Service-to-Key Service communication
* Your responsibility to maintain
### 2. Step-by-Step Migration Guide
#### Prerequisites
* Super Administrator account for Google Workspace
* Old Key Service running and accessible
* New Key Service deployed with `/rewrap` implemented
* New Key Service configured with Old Key Service credentials
#### Step 1: Add New Key Service with Backup Configuration
1. Go to **Google Admin Console**
2. Navigate to **Data > Compliance > Client-side encryption**
3. Click **Add new service**
4. Enter New Key Service details:
* **Name:** Your new service name
* **URL:** `https://new-key-service.example.com`
5. **Critical:** Under "Select backup key", choose your **Old Key Service**
> This tells Google to include `original_kacls_url` in rewrap requests, pointing to your Old Key Service
#### Step 2: Assign New Key Service and Enable Migration
1. In Client-side encryption, click **Assign**
2. Select your **Organizational Unit** or **Group**
3. Under "Key service", select your **New Key Service**
4. Toggle **Migration** to **ON**
5. Confirm and **Save**
> Migration starts immediately - Google begins sending `/rewrap` requests to your New Key Service
#### Step 3: Monitor Progress
1. Go back to **Assign** section
2. Select your Organizational Unit
3. Check the **Migration** counter
| Status | Meaning |
| ------------------- | ------------------------------------ |
| `X items remaining` | X files still using Old Key Service |
| `0 items` | All DEKs migrated to New Key Service |
**Monitor your Key Service logs** for:
* `/rewrap` requests from Google
* `/unwrap` calls to Old Key Service
* Any errors or failures
#### Step 4: Cleanup (Optional - After Migration Complete)
Once migration counter shows **0 items**:
1. Go to Key Service list
2. Select your New Key Service
3. Click **Remove backup**
> After this, you can decommission Old Key Service (but keep key material for potential recovery)
***
### 3. When Does Each Flow Trigger?
#### Scenario A: Active Migration (Admin initiated)
| Trigger | Admin enables Migration toggle |
| ------------------------ | -------------------------------------------------------- |
| Google's action | Sends `/rewrap` to New Key Service for each file |
| New Key Service's action | Calls Old Key Service `/unwrap`, then wraps with new KEK |
| Result | DEKs permanently converted to New Key Service format |
#### Scenario B: User Opens Old File (Migration in progress)
| Trigger | User opens file not yet migrated |
| ------------------------ | ------------------------------------------------------------------------- |
| Google's action | Sends `/unwrap` to Old Key Service (Backup) |
| Old Key Service's action | Unwraps DEK and returns to Google |
| Result | User gets access; file stays with Old Key Service until rewrap reaches it |
#### Scenario C: Emergency Failover
| Trigger | New Key Service has critical failure |
| --------------- | -------------------------------------------------------------------------- |
| Admin's action | Click "Disable & use backup" |
| Google's action | Routes ALL requests to Old Key Service |
| Result | Old Key Service handles all encrypt/decrypt until Key Service KMS recovers |
***
### Important Limitations
#### Single Backup Rule
Only **ONE** backup service per KMS at a time.
#### Gmail Requires a Separate Process
| Service | Rewrap via Admin Console? |
| --------------------------- | --------------------------- |
| Drive, Docs, Sheets, Slides | Yes |
| Calendar, Meet | Yes |
| **Gmail** | **No** - requires Gmail API |
#### No Automatic Notifications
* No email when migration completes
* No progress bar
* Admins must manually check the counter