What to Expect During the Migration¶
Mirantis Secure Registry (MSR) 4 represents a significant evolution in managing container images and associated metadata. The transition introduces a new architecture centered around projects, improved security models, and streamlined policy-based configuration.
The transition may take a significant amount of time, depending on your system and data volume. However, your current MSR instance may remain fully operational throughout the migration, allowing you to continue work without interruption.
Most core data will be transferred automatically, but some settings and features require manual reconfiguration after migration. Understanding what is and is not migrated will help you plan the migration effectively.
What is migrated¶
During migration, MSR automatically transfers key content and configurations, preserving the core of your container registry environment:
Repositories
Repositories from MSR 2.9 and MSR 3.1 are migrated as projects in MSR 4.
Images
All image data, including associated metadata and tags.
Permissions
Permissions are mapped into the MSR 4 project-based access control system as shown in the diagram below:
Push and Poll Mirroring Policies
Mirroring policies are exported and can be manually triggered or rescheduled.
Roles
LDAP-based user accounts assigned to project roles are migrated.
Helm Charts
Chart packages stored in the registry are preserved.
What is not migrated¶
The following items must be recreated or reconfigured after the migration:
Audit Logs
Set up new logging and compliance monitoring mechanisms.
API Updates
Some endpoints have changed; update as needed to maintain automation and tooling compatibility.
Authentication
SAML support is removed. Use LDAP or OIDC instead.
Certificate Management
Define retention and cleanup rules in the new system.
Garbage Collection Settings
Manually reconfigure garbage collection policies in MSR 4.
Image Tag Retention
Reconfigure rules to manage image lifecycle in MSR 4.
Labels
Update image and repository labels.
Local Groups and Users
Manually recreate any local groups and users that are defined only in Enzi and not managed by an external identity provider.
Project Permissions
Depending on your permission settings you may need to recreate user and team access rules using MSR 4’s project-level model.
Project Visibility
Set project visibility manually for each project. MSR 4 does not support mixed visibility within a single organization as shown in the diagram below:
Pruning Policies
Configure pruning policies manually. These settings cannot be imported directly, as MSR 4 uses reversed logic when evaluating pruning rules.
Scanning Settings
Enable and configure Trivy to support image vulnerability scanning in MSR 4.
Signed Images
Existing image signatures are not preserved. They need to be re-signed using Cosign.
Tag Immutability
Tag immutability is configured at the project level, and must be set up manually for each relevant project. However, if a repository had tag immutability previously set to
false
, there is no need to apply a new tag immutability rule after the migration.Tokens
Tokens from previous versions are not preserved. Generate new tokens in MSR 4
Webhooks
Recreate and redirect webhooks to MSR 4 endpoints.
Removed features¶
The following features are not supported in MSR 4:
Swarm Support
While MSR 4 no longer supports Swarm HA clusters, single-instance deployments remain viable for Swarm users, though not recommended for production use. For more information visit Install MSR single host using Docker Compose.
Promotion Policies
Automate promotion workflows through updated CI/CD pipelines.