How to Migrate CGA to SecureEdge
This article explains how to migrate your Barracuda CloudGen Access (CGA) account to SecureEdge Access, enhancing your Zero Trust Network Access (ZTNA) experience with centralized policy management, agentless access options, advanced reporting, and integration with other Barracuda services on a single, unified platform. The migration uses an automated wizard for a streamlined transition. If needed, a temporary/trial subscription for 21 days is created in SecureEdge to ensure that users can be enrolled even if the user count exceeds the allocated seats, and that the service continues uninterrupted. This article covers the following contents:
Important Information Related to CGA Setup
Ensure you complete all necessary changes in CGA before starting migration. Once started, you cannot revert or retry. Make all changes to users, policies, applications, and resources before clicking the Start button. You must verify and update the following: the user directories list under Identity > Settings, the web filter policies under Web Security > Policies, the applications under Catalog > Apps, and the connected resources under Access > Resources, Policies and Proxies.
Prerequisites for Migration
User / Environment requirements:
You must have a valid CGA tenant with the migration/EOL banner enabled. Note: The tenant must be eligible for migration and not already marked as successfully migrated.
You must log in via Barracuda Cloud Control (BCC) and have access to CGA.
You must have permissions to start migration from CGA and to authorize identity providers and directories in SecureEdge.
Supported Identity Providers:
azure_oidc(Microsoft Entra ID),barracuda_oidc(BCC), Email, SAML.Supported User Directories:
azure_ad(Microsoft Entra ID),google_apps(Google Workspace), Okta, and LDAP. (Note: LDAP requires a public IP for Secure Edge Manager connectivity).
Note: You must re-enter connection details for your Connectors directory (such as LDAP host, bind DN, client IDs) in the wizard. After setup, a full sync must complete before ZTNA / Web filter policies relying on those users/groups become effective.
SecureEdge – Infrastructure requirements:
Access PoPs must be available for the tenant. Note: This is required for Connectors.
Specify a Connector IP range (CIDR) during the wizard, e.g.,
192.168.10.0/24. Ensure it can allocate a virtual IP pool for each migrated Connector resource.User is ready to deploy SecureEdge Connectors in their network after migration.
Licensing requirements:
Migrated tenant uses license SKU type: Private in SecureEdge.
A temporary trial subscription (21 days) is created automatically, if needed.
For enrollment, users register under the Managed device profile. The enrollment service requires local users and groups to be saved, with external directories configured and synced.
CGA-to-SecureEdge Migration Video
Feature Mapping from CGA to SecureEdge
Note that objects or features in SecureEdge may differ in name from those in CloudGen Access (CGA). For example, Access > Proxies in CGA is categorized as Infrastructure > Connectors in SecureEdge. For more information on feature mapping from CGA to SecureEdge, see the following table:
CGA Object / Feature | SecureEdge Equivalent | Examples |
|---|---|---|
Identity > Settings > Identity Providers | Identity > Settings > Identity Providers | Types included: |
Identity > Settings > User Directories | Identity > Settings > User Directories | Types included: |
Identity > Users | Identity > Users (Directory Type = Local) |
|
Identity > Groups | Identity > Groups (Directory Type = Local) | Maintain group membership consistent with CGA where possible. |
Access > Proxies | Infrastructure > Connectors | Each CGA AccessProxy connects to a SecureEdge Connector. |
Access > Resources (self‑hosted) | Security > Infrastructure > Connectors | Each self‑hosted resource creates a connector and server, which in turn can be referenced by ZTNA policies. |
Access > Resources (SaaS) | Security > Apps and Resources + Custom Web application | Policy category |
Access > Policies (ZTNA) | Security > ZTNA > Policies | Order preserved; per‑user / per‑group mapping preserved when directories sync correctly. Use self-hosted or SaaS resource. |
Web Security > Policies | Security > Web Filter Policies | User/group policies → default policies → |
GlobalSettings (ZTNA) | Access > Settings | Enrollment limits, web filtering toggle, tamperproof settings. Some low‑level options are ignored. |
UserSettings (per‑user ZTNA) | Access > Enrolled Users > <User> (per‑user overrides) | Where supported; otherwise defaults from global settings apply. |
EnrolledUsers | Access > Enrolled Users | Migrated as preselected users for enrollment invitations. |
AppCatalog | Access > Application Catalog | Catalog apps linked to ZTNA resources or users/groups |
CGA Account “state” | SecureEdge workspace + CGA tenant status (migrated → now READ ONLY) | CGA becomes read-only approximately 90 days after successful migration. |
Points to Note while Migrating
One‑Time Successful Migration
You cannot perform a full migration more than once after success. The CGA account is marked as migrated and automated runs are blocked.
Failed or aborted runs can be retried by restarting from CGA (export and redirect), or the wizard can create a new workspace or reset an existing migration workspace.