What problem are you trying to solve?

Focus on the what and why of the need you have, not the how you'd like it solved.

When we need to migrate our primary MongoDB Atlas clusters to a different cloud provider (e.g., from AWS to GCP) or a different region to optimize infrastructure or meet compliance rules, the associated Online Archives cannot be migrated alongside them. This forces our historical data to be locked into the original cloud provider and region, breaking our unified data mobility strategy.

What would you like to see happen?

Describe the desired outcome or enhancement.

I would like the ability to natively migrate an existing Online Archive to a different cloud provider or a different region. This should work similarly to how standard Atlas clusters can be migrated, allowing us to move the archive without losing federated query capabilities or resorting to manual data extraction.

Why is this important to you or your team?

Explain how the request adds value or solves a business need.

This is critical for avoiding cloud vendor lock-in, adhering to evolving data residency and compliance requirements (such as GDPR or local data sovereignty laws), and optimizing our overall cloud infrastructure costs. Without this capability, we face cross-region latency and high data egress costs when querying our historical data from our new primary cluster location.

What steps, if any, are you taking today to manage this problem?

Currently, because we cannot migrate the archive or write data directly to a new Online Archive, we are forced to choose between highly disruptive and expensive workarounds:

1. Leaving the archive behind: We keep the archive in the legacy cloud provider/region while moving the primary cluster. This results in permanent cross-region/cross-cloud latency and massive egress fees every time a federated query runs.

2. The "Hot Restore" method: We must export all archived data, re-insert it back into our live Atlas cluster (causing massive disk expansion and cost spikes), delete the old archive, wait the mandatory 5-day cooldown period (if changing cloud providers), create a new archive, and then wait weeks for the background job (which is throttled at 2GB per 5 minutes) to slowly re-archive the data.

3. Abandoning Online Archive entirely: We export the historical data to our own customer-managed S3/Blob storage, delete the Online Archive, and manually build and maintain a custom Atlas Data Federation setup, defeating the purpose of paying for a fully-managed archiving solution.