Live Migrate (Push) a MongoDB 6.0.13+ or 7.0.8+ Cluster Monitored by Cloud Manager into Atlas

In Atlas, go to the Organization Settings page.

1. If it's not already displayed, select your desired organization from the Organizations menu in the navigation bar.

2. Click the Organization Settings icon next to the Organizations menu.

   The Organization Settings page displays.

Go to the Live Migration to Atlas page.

Click Live Migration in the sidebar.

The Live Migration to Atlas page displays.

Start the migration process.

1. Click Migrate from Ops Manager or Cloud Manager.

   Note

   The UI label mentions Ops Manager, however, for this procedure, you can only migrate to Atlas MongoDB deployments 6.0.13 or later that Cloud Manager monitors.

2. Click I'm Ready to Start.

Atlas displays a Live Migration wizard with instructions on how to proceed with the process. The process pushes the data from your source cluster to the new destination cluster. After you complete the wizard steps, you can point your application to the new cluster.

Link with Atlas.

1. Click Generate Link-Token. Atlas displays the page for generating a link-token.

2. Click Next to see a page that contains the generated link-token.

3. Copy the link-token and store it in a secure location. Atlas never displays the contents of the link-token. Atlas also does not display the link-token after generating it. Do not share it publicly.

   Note

   Use one unique link-token for live migrating all projects in one Cloud Manager organization to Atlas.

4. Click Done.

Paste the link-token into Cloud Manager.

1. Access the organization in Cloud Manager:

   Open Cloud Manager, and navigate to the organization whose project's cluster you are live migrating to Atlas.

2. Click Settings in the left navigation panel.

3. In the Live Migration: Connect to Atlas section, click Connect to Atlas. The Connect to Atlas dialog box opens.

4. Paste the link-token you generated in the previous step of the Live Migration wizard and click Connect to Atlas. Cloud Manager establishes the connection to Atlas. Use the Refresh button to send an update to Atlas, if needed.

Create the destination Atlas cluster.

If you haven't already, create a destination cluster in Atlas. See Required Access.

Initiate the migration from the destination cluster.

1. Click Select Target Cluster from Projects.

2. Go to your destination Atlas cluster's project and find your destination cluster.

3. Click and select Migrate Data to this Cluster from the dropdown list to start the migration. The Migrate Data to This Cluster page opens.

4. Click Migrate from Ops Manager or Cloud Manager.

   Note

   The UI label mentions Ops Manager, however, for this procedure, you can only migrate to Atlas MongoDB deployments 6.0.13 or later that Cloud Manager monitors.

   Fill in the fields as follows:

   • Select the source project in Cloud Manager, if it's not already selected.

   • Select the source cluster from the dropdown.

   • If you are migrating a replica set to a sharded cluster:

     • If you'd like to shard collections, click the checkmark in Include sharding parameters and paste your sharding configuration JSON into the text box using the sharding example. Save this configuration in a file externally, in case you would like to refer to it later.

       The sharding configuration JSON defines the shardingEntries array, which specifies the collections to shard, and the keys to use for sharding. MongoDB shards only those collections that you include into this array. To learn more, see Sharding.

       If you omit specifying the sharding configuration, you can shard collections on the destination cluster after you migrate your cluster to Atlas.

     • In addition to the sharding configuration, a compatible index for the specified sharding keys must exist on the destination cluster in service.

       Click the checkmark in Create supporting indexes so that MongoDB automatically creates supporting shard key indexes on the destination cluster in Atlas.

   • Select a migration host for handling the migration.

   • If you aren't using a private endpoint, review the IP address access list and check that the migration host's external IP address is included in this list. If it's not added, add it now:

     • Click Set Network Access for Host

     • Click + Add IP Address

     • Return to the Live Migration wizard. Select the source cluster from the dropdown and choose Migrate data to this cluster under .

   • Select the source cluster from the drop-down.

   • If the source cluster enforces authentication, enter a username and password into the provided text boxes.

     See Source Cluster Security for guidance on the user permissions required by Atlas live migration.

   • If you suspend the source cluster from automation in Cloud Manager, but continue to monitor the source cluster with the Monitoring Agent, the Username and Password display. If your deployment requires user authentication, provide the user name and password in these fields. The database user whose credentials you provide must have at least the backup role on the admin database and must be authenticated using both SCRAM-SHA-1 and SCRAM-SHA-256.

   • If the source cluster uses TLS/SSL, toggle the Is encryption in transit enabled? button.

   • If the source cluster uses TLS/SSL with a custom Root Certificate Authority (CA), copy the path to the CA file from your migration host and paste this path into the provided text box. The file must be present on the migration host to ensure the migration host can read the certificate. Atlas checks that the certificate is present and readable.

   • If your destination cluster has data that you want to preserve, keep the Clear any existing data on your destination cluster option unchecked. The live migration service checks a sample of documents during validation and warns you if it finds duplicate namespaces. If you want to delete the existing data, check this option and then enter the name of the destination cluster.

   • Choose a connection to connect to the cluster. The Standard connection always shows as available in the UI. However, other connection options are enabled only if you have previously configured a VPC peering connection or a private endpoint for your clusters. If Atlas detects that you don't have VPC connections or private endpoints configured, these options are grayed out.

     • If you aren't using VPC peering or a private endpoint, click Standard connection and proceed to the Validation stage of this step.

     • If you configured a VPC peering connection between the migration host and the Atlas replica set, the VPC Peering option is active. Click VPC Peering to connect using VPC peering for live migration. If the VPC Peering option is grayed out, configure a VPC peering connection before starting this procedure. To learn more, see Support for VPC Peering and Private Endpoints.

     • If you configured a private endpoint between the migration host and the Atlas cluster, the Private Endpoint option is active. Click Private Endpoint to connect with a private endpoint, and then select a previously-configured private endpoint from the dropdown. Only private endpoints that are in AVAILABLE state are valid. If the Private Endpoint option is grayed out, configure a private endpoint before starting this procedure. To learn more, see Support for VPC Peering and Private Endpoints.

       Note

       For push live migrations where the source and destination clusters are running MongoDB 6.0.13 or later, private endpoints are supported only for clusters deployed within a single cloud provider and single region.

   • Click Validate. The validation process verifies that your migration host is reachable, and performs the following validation checks to ensure that you can start live migration to Atlas.

     To take advantage of the following validation checks, upgrade the MongoDB Agent in Cloud Manager to the latest version. The following validation checks run during the live migration:

     • The migration host can connect to the destination cluster.

     • If the source cluster uses TLS/SSL with a custom Root Certificate Authority (CA), the migration host can access the source cluster using TLS/SSL.

     • The database user credentials are valid. This validation check runs only if you suspend the source cluster from automation in Cloud Manager, but continue to monitor the source cluster with the Monitoring Agent.

     • The migration process validates that the destination cluster has enough disk space based on the storage size of the compressed data. To learn more about data and storage sizes, see dbStats.

   • If validation fails, check the migration host, the validity of your external IP addresses or CIDR block, and the link-token. Also check the database user credentials, your TLS/SSL certificates, and the amount of disk storage size on the destination cluster.

   • If validation succeeds, click Next.

Start the migration.

1. Review the report listing your source organization, project and cluster, and the migration host that the live migration process will use.

2. Click Start the Migration.

   Once the migration process begins, Atlas UI displays the Migrating Data walk-through screen for the destination Atlas cluster. The walk-through screen updates as the destination cluster proceeds through the migration process. The migration process includes:

   • Applying new writes to the source cluster data to the destination cluster data.

   • Copying data from the source cluster to the destination cluster.

   • Finalizing the migration on the destination cluster.

   A lag time value displays during the final phase of the migration process that represents the current lag between the source and destination clusters.

   When the lag timer is close to zero and the migration process is caught up, Atlas activates the Cutover to your destination cluster button and indicates that your source and destination clusters are in sync. Proceed to the next step.

Perform the cutover.

Cutover is a three-step process of directing your application's reads and writes away from your source cluster and to your destination cluster.

When Atlas detects that the source and destination clusters are nearly in sync, it starts an extendable 120 hour (5 day) timer to begin the cutover stage of the live migration procedure. After the 120 hour period passes, Atlas stops synchronizing with the source cluster.

At this stage in the migration process, you can proceed to cutover or extend the syncing period and then proceed to cutover.

• If you click I'm ready to cutover, Atlas starts the cutover process.

• If you click Extend Sync, and if the extended sync completes successfully, Atlas confirms that source and destination clusters are in sync. Proceed with the cutover process. If the sync time expires, you can retry the migration.

  If your migration is about to expire, Atlas sends you an email similar to the following example:

  A migration to your Atlas cluster will expire in <number> hours!
  Navigate to your destination cluster to start the cutover process. If
  you don't take any action within <number> hours, the migration will be
  cancelled and you will need to start again. You can also extend the
  migration process if you need more time.

1. Click I'm ready to cutover. Proceed with the three-step cutover process quickly to ensure minimal downtime to your application.

2. Click Proceed to cutover. The three-step cutover process begins:

   1. Stop writes to your source cluster. Click I confirm that I've stopped writes to my source cluster. Click Finalize migration to proceed.

   2. Wait a few minutes while Atlas finalizes the migration. Atlas performs these actions to complete the process:

      • Removes the MongoDB live migration server subnets from the IP access list on the destination cluster.

      • Removes the database user that live migration used to import data to the destination cluster.

      If the cutover process has been in progress for at least 12 hours, Atlas sends you an email that suggests you check on the migration process or contact support.

   3. If the migration succeeds, the You have successfully migrated to Atlas page displays. Atlas shows the status of the synced changes, the application downtime, the duration of the migration process, the amount of initial data copied, and the number of copied collections.

      • Verify that your data is transferred to the destination cluster by comparing document counts and running hash comparisons. To learn more, see Cluster-to-Cluster Sync Verification of Data Transfer.

      • Click Connect to your new cluster. Atlas redirects you to the Connect to Atlas page, where you can choose a connection method.

      • After you connect to your cluster, resume writes to the destination cluster.