Decision criteria for option "Auto-Migrate"

When to Choose Auto-Migration

• Your environment is complex, with many interdependent virtual machines and services that would be difficult or risky to rebuild from scratch.
• Your current setup contains legacy configurations or components that would require significant effort to reproduce in a clean rebuild.
• You are comfortable working with the technical details of the provided OS Migrate tools and are prepared to troubleshoot or adapt configurations if necessary.

Pros

• No need to fully understand or document every technical detail of your current setup — virtual machines, volumes, security groups, and networks are migrated as they are 1:1.
• Existing service identities and connections are preserved — there is no need to create temporary service names, DNS entries, or new certificates.

Cons

• The entire migration process cannot be tested in advance — the actual cutover serves as the test.
• Unexpected issues may arise on migration day, making troubleshooting more stressful and time-critical.
• You miss the opportunity to clean up outdated configurations, legacy components, or inefficient architectural patterns.

When using the auto-migrate feature, we strongly recommend starting with your test or staging environments before proceeding to production.

Overview of an Auto-Migration

A typical OpenStack project migration follows this process:

1. Request a destination project in the Switch Cloud OpenStack environment by contacting your local Informatikdienste (IT services).
2. Ensure that sufficient quotas are allocated for the new project so it can accommodate all resources — RAM, CPU, and storage — currently in use on the existing source project in SWITCHengines.
3. Use Switch’s "ecm" tool to simplify and manage the original OS Migrate tools.