For AI agents: a documentation index is available at https://www.mongodb.com/docs/llms.txt — markdown versions of all pages are available by appending .md to any URL path.
Docs Menu

Migration to Kubernetes Prerequisites

Confirm each prerequisite on this page before you start a migration of a self-managed deployment into Kubernetes.

  • A Ops Manager or Cloud Manager connection ConfigMap with the keys baseUrl, orgId, and projectName.

  • An API key Secret with the keys publicKey and privateKey.

  • The Kubernetes Operator ServiceAccount has batch/jobs permissions (create, get, list, watch, and delete) for the dry-run connectivity Job.

  • The project contains exactly one deployment.

You need:

  • An existing replica set or sharded cluster that Ops Manager or Cloud Manager manages.

  • A Kubernetes cluster, or clusters, with Kubernetes Operator already installed. For a multi-cluster target, provision and bring every cluster under operator management before migration begins, and confirm that cross-cluster FQDN resolution already works.

  • A deployment that is healthy and at goal state.

You need:

  • The kubectl mongodb plugin, at a version that matches Kubernetes Operator. Kubernetes Operator enforces this version match on every reconcile, including the dry run, through the mongodb.com/migrate-tool-version annotation.

  • Operator Role-Based Access Control (RBAC) restricts system access based on assigned roles. Here, it includes batch/jobs permissions (create, get, list, watch, and delete), which Kubernetes Operator requires to run the dry-run connectivity Job.

You need:

  • Bidirectional network connectivity between the virtual machine hosts and the Kubernetes Pods. You provision this connectivity yourself. Agent-to-mongod and mongod-to-mongod traffic must flow in both directions across the boundary, and your drivers must reach both sides.

  • cert-manager or an equivalent certificate issuer, if the deployment uses TLS.

You need:

  • The SCRAM user passwords in hand. You cannot recover them from the automation config, which stores only the salt, the server key, and the stored key.

  • A backup taken before you start.

Migration supports replica sets and sharded clusters. It supports No Auth, SCRAM-SHA-256, X.509, LDAP, and TLS, in any combination. When you use LDAP, the bindMethod must be simple.