Domain Migration to gaccess.io

1. Overview

Globus is changing the default domains for Globus Connect Server (GCS) endpoints to gaccess.io to keep institution-managed assets separate from Globus-managed resources.

All endpoints created with gcs endpoint setup after July 16, 2025 were automatically issued domains under the gaccess.io domain, so no action is required.

Endpoints created before July 16, 2025 have a default domain in the dn.glob.us or data.globus.org domains and will need to migrate. With the release of 5.4.100, domain migration is available for all endpoints except those listed in configurations not yet supported.

This document describes how to migrate an endpoint.

2. Migrating an Existing Endpoint

The process of domain migration for supported endpoint configurations begins as soon as the Globus Connect Server packages are updated to 5.4.100 or newer.

An endpoint with a data.globus.org or dn.glob.us default domain moves to gaccess.io in two phases:

  1. Phase 1: Allocate the New Domain (Automatic). Once services are restarted after updating packages, your endpoint is issued a gaccess.io name and begins answering on both its old and new names. This is the phase where anything that names a collection’s hostname should be updated to use the new gaccess.io domain.

  2. Phase 2: Retire the Old Domain (Admin-Initiated). You perform this when you are ready. The old name is retired and only the gaccess.io name remains.

2.1. Checking Progress

Use gcs endpoint migration-status to monitor progress of each phase of the migration. It works at any point, before, between or after the phases. Run it as root on an endpoint node. It prints a header, then each step of each phase marked OK, PENDING, SKIP, FAIL or UNKNOWN, and ends with a one-line result. This example output is for an endpoint that has completed Phase 1, but not Phase 2:

$ sudo gcs endpoint migration-status
GCS Domain Migration Status
============================================================
Endpoint:   00000000-1111-2222-3333-444444444444
Old Domain: a1b2c.data.globus.org
New Domain: a1b2c.9f8e.gaccess.io
OIDC:       no
Env:        production

PHASE 1 — Allocate the new domain (Automatic)
  [OK     ] DNS: new name allocated
  [OK     ] Auth: redirect URIs — new added  — 3 old / 3 new
  [OK     ] Auth: scopes updated  — 2 scope(s) carry new domain
  [OK     ] DNS: new name resolves  — all 2 node(s) resolve
  [OK     ] AppSync: new domain config written  — a1b2c.9f8e.gaccess.io
  [OK     ] Cert: SANs cover both names  — covers both old and new domains
  [OK     ] Vhosts: new domain added  — 12 of 12 updated

PHASE 2 — Retire the old domain (admin-initiated)
  [PENDING] Transfer: endpoint domain updated  — endpoint hostname not migrated; 12 of 12 collection(s) not migrated
  [PENDING] Auth: old redirect URIs deleted  — 3 old-domain URI(s) still present
  [PENDING] DNS: old name deleted  — old domain still active (A)
  [PENDING] AppSync: final config written  — still using old domain
  [PENDING] info.json: domain_name updated  — still shows 'a1b2c.data.globus.org', expected 'a1b2c.9f8e.gaccess.io'
  [PENDING] Vhosts: old domain removed  — 0 of 12 cleaned up

PHASE 1 COMPLETE — awaiting Phase 2 (retire the old domain).
  Pending: Transfer: endpoint domain updated, Auth: old redirect URIs deleted, DNS: old name deleted, AppSync: final config written, info.json: domain_name updated, Vhosts: old domain removed

The report ends with one of these results:

IN PROGRESS

Phase 1 is not yet complete. The steps still pending are listed. Phase 1 is automatic; see Phase 1: Allocate the New Domain (Automatic).

PHASE 1 COMPLETE

Phase 1 is done and the endpoint is waiting for you to start Phase 2.

FULLY MIGRATED

Both phases are complete.

NEVER NEEDED

The endpoint’s domain is already under gaccess.io and no migration is recorded for it. No action is required. The report ends early.

BLOCKED

The endpoint cannot be migrated at this time. The report ends early with the reason. See Configurations Not Yet Supported by Domain Migration.

2.2. Phase 1: Allocate the New Domain (Automatic)

After you upgrade to Globus Connect Server 5.4.100 or newer, the endpoint requests a gaccess.io name of its own, publishes its node addresses under that name, and adds it to the endpoint’s certificate. Once the certificate covers the new name, every collection begins answering on both its old and its new name.

No action is required to complete this phase, and everything continues to work as before. A collection previously reached at https://m-4283f.9009.09ad6.data.globus.org can also be reached at https://m-4283f.9009.09ad6.gaccess.io, and both names present a valid certificate.

Now is the window to update anything that references your endpoint or collection hostnames to use the new gaccess.io domain. See the Phase 2 Pre-flight Checklist.

Note
The Globus Connect Server assistant service performs Phase 1 and also renews your certificates. Phase 1 may take a few minutes after the upgrade. Run gcs endpoint migration-status to see when it has finished.

2.3. Phase 2: Retire the Old Domain (Admin-Initiated)

The endpoint serves both domains until you run gcs endpoint migrate-domain, which retires the old domain.

2.3.1. Pre-flight Checklist

Address each of the following before you run gcs endpoint migrate-domain.

Confirm Phase 1 is complete. Run gcs endpoint migration-status, as described in Checking Progress, and check that nothing in Phase 1 is still pending and that the report does not say BLOCKED.

Confirm your collections answer on their new names. Each collection keeps its label and changes only the domain. Verify collection HTTPS access before you rely on the change. A collection on a custom domain, whether its own or the endpoint’s wildcard custom domain, keeps its name.

You and your users update anything that names a collection’s old hostname. The Globus Web App and Globus Transfer follow a renamed collection automatically; nothing else does. Collection hostnames are subdomains of the endpoint’s domain, so you and your users should update any reference to a host ending in data.globus.org or dn.glob.us. Check:

  • scripts and automation that use collection HTTPS URLs

  • firewall or proxy rules that name the old hostnames

  • browser bookmarks, documentation, and portal configuration that link to collections

  • HTTPS clients that pin the old names

  • Globus Flows definitions and input schemas and Globus Search indices

Only the suffix of your Globus-issued domain changes. For example, a mapped collection at m-4283f.9009.09ad6.data.globus.org becomes m-4283f.9009.09ad6.gaccess.io. This applies to your endpoint domain (including the management API) and to all mapped and guest collections using Globus-issued domains.

You and your users can view endpoint and collection domains on the Endpoint and Collection Overview pages of the Globus Web App.

Example 1. Finding the names in use

Collections are named as subdomains of the endpoint’s domain, so a rule or script referring to any host ending in data.globus.org or dn.glob.us for this endpoint needs updating.

Tell your other endpoint administrators. Anyone using the GCS CLI against this endpoint must log in again after Phase 2; see Logging In Again.

2.3.2. Perform Domain Migration

Phase 2 removes the old domain from DNS, so update anything that still uses the old hostnames before you run gcs endpoint migrate-domain.

When you are ready to retire the old domain, run:

$ gcs endpoint migrate-domain
Domain migration cannot be reversed. Are you sure? [y/N]: y
Message: Success

Alternatively, you can perform domain migration from the endpoint overview page in the Globus Web App.

If the endpoint is not yet ready, gcs endpoint migrate-domain reports why and makes no changes, so it is safe to run and try again later. Running it again after the migration is complete reports "Domain already migrated." and changes nothing.

Use gcs endpoint migration-status to follow the progress of Phase 2, as described in Checking Progress.

2.3.3. What Happens After the Command Returns

After gcs endpoint migrate-domain returns, each node rewrites its Apache configuration and reloads. On a large endpoint this can continue for several minutes after the command reports success.

Note
Your collections stay reachable on their new names throughout. Both names were already configured before Phase 2, so this work removes the old name from the configuration.

2.3.4. Logging In Again

Anyone using the GCS CLI against the endpoint must log in again after Phase 2, not only whoever ran gcs endpoint migrate-domain. When you run gcs login, the GCS CLI records the endpoint’s GCS Manager URL, and that URL no longer exists once Phase 2 is complete. Log in again to record the new domain URL:

gcs login --force ENDPOINT_ID

On an endpoint host, gcs login --force localhost does the same. The --force option is required. Without it, gcs login detects the existing login and does not update the recorded URL.

3. Configurations Not Yet Supported by Domain Migration

Not all endpoint configurations are supported for domain migration at this time. Depending on the reason gcs endpoint migration-status reports, either migration support for the configuration will be released at a later date, or you will need to contact support@globus.org.

gcs endpoint migration-status reports BLOCKED when the endpoint’s configuration is not yet supported for domain migration. Such an endpoint is not issued a gaccess.io domain name, gcs endpoint migrate-domain refuses the migration with the same reason, and the endpoint keeps its current domain name.

$ sudo gcs endpoint migration-status
GCS Domain Migration Status
============================================================
Endpoint:   00000000-1111-2222-3333-444444444444
Old Domain: a1b2c.data.globus.org
Env:        production

BLOCKED — DNS migration is not yet available for endpoints with a non-wildcard custom domain. An announcement will be made when domain migration is ready for your endpoint configuration.

The reason is one of the following.

An OIDC server that was removed with gcs oidc delete.

DNS migration is not available for endpoints whose Globus-issued domain still
has an OIDC identity provider registered with Globus Auth, including one left
by `gcs oidc delete`. Please contact support@globus.org for assistance.

Removing the OIDC server does not remove its identity provider from Globus Auth, and the identity provider still prevents migration. Contact support@globus.org to request removal of the identity provider from Globus Auth. Once the identity provider is removed, you may migrate your endpoint (assuming your endpoint is not blocked by one of the other configuration settings described below).

A non-wildcard custom domain.

DNS migration is not yet available for endpoints with a non-wildcard custom
domain. An announcement will be made when domain migration is ready for your
endpoint configuration.

No action is required. An announcement will be made when migration is available for this configuration. A wildcard custom domain does not prevent migration.

A Globus OIDC server named under an old Globus domain.

DNS migration is not available for endpoints with an OIDC server using the
Globus-issued domain. An announcement will be made when domain migration is
ready for your endpoint configuration.

No action is required. An announcement will be made when migration is available for this configuration. An OIDC server with a hostname of its own, or one under a wildcard custom domain, does not prevent migration.

The DNS service cannot allocate a new domain.

a1b2c.data.globus.org cannot be migrated to the new domain. Please contact
support@globus.org for assistance.

The report shows this after the first Phase 1 step, which is marked FAIL. Contact support@globus.org.