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.
The Google OpenID Connect (google_oidc) configuration is tied to the CGA application registration and cannot be reused in SecureEdge. Therefore, you must reconfigure Google OIDC after migration, regardless of the migration method used.
CGA’s custom OpenID Connect (OIDC) configuration can be migrated to SecureEdge OIDC. After migration, you must add the SecureEdge redirect URI (
Auth0Endpoint}/login/callback) to the list of allowed redirect URIs in your OIDC provider.
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
Before migrating from CGA to SecureEdge, ensure the following prerequisites are met:
Shorten all resource names to ≤31 characters.
Replace any wildcard or CIDR-based internal hosts with specific IP addresses.
Remove external group memberships from local user accounts.
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.
Connectors and Resources
Connector IP Range – Must accommodate all CGA Connector resources, each requiring a virtual IP range.
Mixed Resources – If a Connector has both SaaS and self‑hosted resources, one Connector is created for self‑hosted resources. In addition, a Custom Web application is created for SaaS resource(s), categorized under Web Traffic / SAAS_AND_BUSINESS.
>10 Servers per Access Proxy – Migration creates a single Connector even if an Access Proxy manages more than 10 servers.
Connector Registration Tokens – Tokens provided in the report are valid for 24 hours.
Names and Data Quality
Names in SecureEdge can contain only letters, numbers, and hyphens. Note: Any other character is replaced with a hyphen.
If CGA data is inconsistent or incomplete, such as missing email or invalid host, the wizard prompts the user to make a correction, such as requesting the email domain. In addition, the wizard logs errors in the Migration Report for manual follow-up.
Existing SecureEdge Users
Existing SecureEdge users with non-empty workspaces are out of scope for the automated wizard. These accounts will need manual / assisted migration facilitated by Barracuda Networks Technical Support. For assistance, users can contact technical support by visiting the following link: https://www.barracuda.com/support/contact.
Ignored / Normalized Settings
The migration ignores or normalizes certain fields:
Field Name | Ignored |
|---|---|
ZTNA Device Posture | Linux OS posture in CGA |
Device Options / General Zero Trust Settings |
|
Web Filter Policies |
|
Field Name | Supported range in SecureEdge |
|---|---|
Re‑authentication Durations | You can specify the re-authentication policy time for each resource.
|
Actions to Take if Migration Fails or is Aborted
Note that if CGA migration fails or is aborted, follow these steps:
Check error message in wizard.
Check migration report (if generated).
Typical fixes include the following:
Correct invalid CGA entries, such as names and URLs.
Correct identity provider and directory credentials, and verify network access.
Adjust the connector IP range to ensure validity and sufficiency.
Retry migration
Restart from CGA by clicking the migration button again.
The wizard will guide users to a new clean workspace and may also reset the previous migration workspace, depending on the implementation.
Initiating Migration
Open CGA.
Select the I have read the document box. Selecting this checkbox enables the Start button; otherwise, the Start button stays disabled.
Click Start.
The Preparing your account for migration… window opens, showing the status as Preparing.
Verify all your setups on CGA for user directories, applications and resources, and web filter policies.
After the configuration is ready to be copied to SecureEdge, click Next to continue.
You will be redirected to the SecureEdge migration wizard. Note: In SecureEdge, the initial setup starts with a workspace selection via a wizard. If no workspace exists, the wizard creates one. If a workspace exists, you can either use it and erase its configuration after confirmation or create a new workspace for migration. Users may opt out of automated migration to prevent overwriting current configurations; those who opt out must migrate manually without CGA automation.
The SecureEdge Welcome window opens. Click Start now!
The Personalization page opens. Specify values for the following:
Region – Select your region. You can choose either Europe or North America. Note: This field is mandatory.
Type of business – Select your business type. You can choose between School, Corporate, Government, or Other. Note: If you choose Other, please specify your business type.
Number of users – Select a value based on the number of users. Choose from the following ranges: 0-50, 51-200, 201-1000, 1001-5000, 5001-10000, or > 10000.
Click Submit.
The Account Migration page opens and displays the following information:
The chosen Tenant/Workspace is displayed in the top menu bar. The CGA setup will migrate to SecureEdge in the selected cga-migration workspace.
Displays details about the account name, seat availability, and expiration date.
In the Identity section, authorize and re-sync Identity. You can view details about identity providers and user directories:
Identity Providers – Authorize your identity provider. For example, in this case, Email is used.
User directories – Authorize your user directories. For example, in this case, Okta, Microsoft Entra ID, and LDAP user directories are used. Note: When adding user directories, a new tab opens for authorization. Enter your admin credentials and click Sign in. After authorization, return to the migration wizard page.
The Add User Directory page opens. Specify the values for the following:
Display Name – Displays name of your user directory.
Okta Domain Name – Enter the Okta domain name. This is the domain assigned to your organization inside Okta.
Okta Auth Token – Enter the Okta auth token. This is an Okta authentication token, and it is required to sync with Okta directories.
Click Save.
Repeat the steps to configure the remaining user directories. Ensure all directories sync and complete full sync.
In the Configurations section, specify values for the following:
Connector IP Range – Enter the network IP pool range that will be used by the Connector clients.
Email Suffix – Enter the email domain.
Click Next. Note: The Configuration sections will also show a green check mark.
During the migration, you can view the progress bar in the sections Report and Migration report.
After migration completes, the Migration report section shows Done with a green check mark. The Report sections also display a green check mark. You can then do the following:
To preview the report, click Preview Report. The Migration Report page opens, where you can verify the migration details.
To download the report, click Download Report. Note: You can download the report only once. Save it because you cannot download it again. The report contains the following:
The report summarizes counts and errors for various migrated areas.
It covers Identity Providers, detailing successful migrations and failures with error messages. It also addresses User Directories, Local Users, Local Groups, and Apps & Resources, highlighting sync statuses, creation and failure counts, and common issues.
The report includes information on Connectors, ZTNA Policies, Zero Trust settings, the App Catalog, Web Filter Policies, and Enrolled Users, summarizing successes and failures in each category. Note that the Connector token in the report is valid for 24 hours.
Click Next.
Click Exit.
The SecureEdge Dashboard page opens.
Verify all your SecureEdge setups for user directories, applications and resources, and ZTNA and web filter policies with respect to the report you have downloaded.
To verify your identity provider and user directories, go to Identity > Settings.
To verify users or groups migration, go to Identity > Users or Groups respectively. For more information, see Identity Management.
To verify SecureEdge Enrollments, go to Access > Enrollments. For more information, see Enrollments.
To verify custom Web / Network apps migration, go to Security > Apps and Resources.
To verify Application Catalog entries migration, go to Access > Application Catalog.
To verify your Web Filter policies migration, follow these steps:
In the left menu, click Security.
Expand the Web Filter menu and select Policies.
The Web Filter Policies page opens, displaying all your migrated policies. Confirm that the SecureEdge ACTION field for allowed or blocked websites matches CGA behavior. Also, validate both user/group and default policies. For more information, see Web Filter Policies.
To verify your Connector migration, follow these steps:
Go to Infrastructure > Connectors.
The Connectors page opens, displaying all your migrated connectors. To deploy Connectors, use the registration tokens in the report.
To verify your Subscriptions in the SecureEdge Manager, follow these steps:
In the bottom left of the window, click the Profile icon.
The Profile menu opens. Click Subscriptions.
The Subscription page opens. You can see the subscription(s) for your products.
After successful migration, the CGA account is marked MIGRATED. A grace period of 60 days begins, and after this period the CGA tenant becomes READ-ONLY. During READ-ONLY, users can still log in to review old configurations but cannot change policies or settings.
Actions to Perform on Your Network after Successful Migration
Step 1. Tasks to Perform on Your Network after Connector Migration:
Install the Connector to replace the proxy.
Configure the Connector, move some resources or servers to it, and verify that traffic passes.
Test Connectors by sending traffic.
If possible, route a small portion of production traffic through SecureEdge, then move all traffic.
Optionally, configure an IPsec VPN instead of Connectors when more resources connect to the proxy.
Note: The token in the report is valid for 24 hours. After that time period, you can regenerate it from the Connectors page on SecureEdge Manager. Verify that each CGA Access Proxy replaces to a SecureEdge Connector.
For more information on Connectors, see How to Configure the SecureEdge Connector. Optionally, configure an IPsec VPN instead of Connectors for specific use cases.
Step 2. Connect a Barracuda SecureEdge Access Agent:
Download the Barracuda SecureEdge Access Agent.
Install and run the SecureEdge Access Agent.
Verify your ZTNA policies via Security > ZTNA > Policies.
Enroll users.
After connecting to the SecureEdge Access Agent, verify the user entries on the Access > Enrolled Users page and the device entries on the Access > Enrolled Devices page in the SecureEdge Manager. For more information, see Enrollments.
For more information, see:
To download and install the Barracuda SecureEdge Access Agent, follow the steps mentioned in the section Step 3. Connect a Barracuda SecureEdge Access Agent of the article How to Enroll Users.