Edition & Topology Changes

The operator supports two in-place changes that preserve data on the existing PersistentVolumeClaims: raising the SQL Server edition on a running resource, and migrating a standalone MSSQLInstance to a MSSQLAvailabilityGroup.

note

This page is about changing an existing SQL Server deployment (its edition or topology). It is not about upgrading the operator itself — for that, see Installation.

Edition upgrade

Change spec.edition on a MSSQLInstance or MSSQLAvailabilityGroup to move to a higher edition. The operator passes the new value to the SQL Server container as MSSQL_PID and rolls the pod(s); the databases survive on the reused PVC. Microsoft ships a single image for all editions, so no image change is involved (see the MSSQL_PID mechanics in cr-reference.md).

spec:
  edition: Standard   # was: Express

Allowed paths

SQL Server can raise an edition on existing data but cannot lower it (a downgrade fails at engine startup). The admission webhook enforces this, so an unsupported change is rejected when the CR is applied:

From	Allowed to
Express	Developer, Standard, Enterprise, EnterpriseCore
Developer	Standard, Enterprise, EnterpriseCore
Standard	Enterprise, EnterpriseCore
Enterprise	EnterpriseCore
EnterpriseCore	Enterprise

• Setting the same edition is always allowed; an empty value defaults to Developer.
• Enterprise ⇄ EnterpriseCore is permitted in both directions (they differ only in licensing model).
• Downgrades are forbidden. To move to a lower edition, restore into a new resource.
• Express is rejected on MSSQLAvailabilityGroup (no Always-On support), so it cannot be the target edition of an AG.

Topology change (standalone → Availability Group)

MSSQLInstance and MSSQLAvailabilityGroup are separate CRDs — there is no in-place toggle on a single resource. To convert a standalone instance to an AG while keeping its data, bring up a MSSQLAvailabilityGroup on the reused PVCs of the standalone instance with adoptExistingDatabases enabled:

apiVersion: mssql.solanica.io/v1alpha1
kind: MSSQLAvailabilityGroup
metadata:
  name: my-mssql            # StatefulSet name; reuses the standalone PVCs
spec:
  size: 3                   # AG requires >= 2 replicas
  acceptEULA: true
  saPasswordSecret: my-mssql-secret
  edition: Developer        # any non-Express edition
  availabilityGroup:
    availabilityMode: synchronous
    adoptExistingDatabases: true

With adoptExistingDatabases: true, the operator adds any user database already present on the primary to the Availability Group — not just those listed in availabilityGroup.databases. Databases carried over on the reused PVC are joined to the AG on the primary and automatically seeded to the secondaries. Adoption is idempotent: databases already in the AG are skipped, so it is safe on every reconcile.

Requirements

• The MSSQLAvailabilityGroup must reuse the standalone instance's PVCs (same StatefulSet/resource name), so the previous MSSQLInstance must be removed first to avoid two controllers owning the same StatefulSet.
• At least 2 replicas (size >= 2).
• A non-Express edition (Developer, Standard, Enterprise, or EnterpriseCore) — Express does not support Always-On.

See availability-groups.md for full AG configuration.