Migrate a Google SecOps instance to a BYOP project
This guide helps Google Cloud administrators and security engineers to migrate an existing Google SecOps instance, including its data, to a different Google Cloud project using the Bring Your Own Project (BYOP) model. This process helps you consolidate resources, realign billing, or adapt to organizational changes while preserving your security data and instance configuration.
Key terminology
- Bring Your Own Project (BYOP): A model where you use your own Google Cloud project to host and manage the Google SecOps instance.
- Proof of Concept (POC): A non-production instance used for evaluation or testing.
- Technical Point of Contact (TPOC): The designated contact person in your organization for technical communications regarding the migration.
Before you begin
Before starting the migration, confirm that the target Google Cloud project meets the following requirements:
Permissions: To perform a self-service migration for a POC instance, you must have the IAM role
chroniclesm.admin, which includes thechroniclesm.projectLink.enablepermission.Billing account: You must link the Google SecOps instance to a target BYOP project that uses the same Google Cloud billing account as the original project. Confirm that the billing account subscription is active.
Project availability: You can use an existing or a new Google Cloud project as the target:
- Existing project: Confirm it's a valid Google Cloud project and not already linked to an active Google SecOps instance.
- New project: Configure the project as described in Configure a Google Cloud project for Google SecOps.
Organization policies: If the current Google Cloud project has active organization policies, such as VPC Service Controls, CMEK, FedRAMP, or other compliance frameworks, contact Google SecOps Support for assistance before initiating the migration.
Chronicle API: Enable the Chronicle API in the target Google Cloud project. For more information, see Enable the Chronicle API.
Authentication (BYOID only): If your instance uses Bring Your Own Identity (BYOID), configure the workforce pool in the target project. For more information, see Configure a third-party identity provider.
Downtime: Be aware that the migration process requires downtime. To maintain data integrity, the Google SecOps instance and its APIs are temporarily unavailable and return an HTTP 503 error. Ingestion and feeds are also affected.
Migrate the instance to a BYOP project
The migration process depends on whether you are migrating a POC instance or a non-POC production instance.
Migrate a POC to a production BYOP
If you are moving from a POC to a full production environment, you can initiate the migration yourself. This process starts automatically when your new production contract begins. Your designated TPOC receives a contract start notification email with a setup link.
Follow the instructions in Link a Google SecOps instance to a new subscription, specifically the subsection To link an existing POC Google SecOps instance to a new subscription.
Migrate a non-POC project to a BYOP
For non-POC projects, such as for internal organization restructuring or Managed Service Provider (MSP) transitions, Google SecOps Support manages the migration.
- Initiate the request: Open a standard support ticket to request the project migration. Include details such as whether you have a new subscription and want to change the linked Google Cloud project for the Google SecOps instance.
- Migration process: Google SecOps Support triggers the update. You don't need to take any action in the console. Automated status emails are sent to your team as the migration progresses.
During the migration process
A brief maintenance window is required to move your instance to the target project and maintain data integrity.
- During the critical phase, your Google SecOps instance and its APIs are temporarily unavailable and return an HTTP 503 (Service Unavailable) error. This is expected. Normal service resumes automatically when the project update completes.
- For more information on how data feeds are affected, see Impact of changing your linked Cloud Project on data feeds.
Complete post-migration actions
After you receive the migration completion notification email, your TPOC must complete the following actions to restore full functionality:
Configure authorization: Set up all required IAM authorization rules on the target project. For more information, see Configure feature access control using IAM.
Recreate specific ingestion feeds: While most ingestion feeds continue without interruption, you must manually recreate the following feeds in the target environment. Follow the steps in Required actions for customers:
Verify other ingestion: Confirm that all other ingestion mechanisms are working as expected. Contact Google SecOps Support if you encounter issues.
BigQuery data: If you store data in BigQuery associated with the old project, contact Google SecOps Support to help migrate this data to the target project.
Update automations: Reconfigure any external automations or scripts that rely on the Chronicle API. Update them with the target project ID, generate new API keys, and create any necessary service accounts in the target project.
Migrate POC data: If you migrated an existing POC instance to a new subscription, contact Google SecOps Support or your Google representative to assist with migrating the POC data after activation.
Troubleshooting
- HTTP 503 Error: This error is expected during the migration window, as mentioned in the During the migration process section. Service should be restored automatically upon completion.
- Feed issues: If feeds other than the ones listed for manual recreation are not working post-migration, contact Google SecOps Support.
- Permission errors: Double-check the IAM roles and permissions in the target project.
Need more help? Get answers from Community members and Google SecOps professionals.