Planning a Migration to OpenStack Flex

Migrating your data and workload to the Rackspace OpenStack Flex platform

Guide to Migrating Data & Workloads to a New VM in an Rackspace OpenStack Flex

This guide walks you through the key considerations, preparations, and common pitfalls when migrating data and workloads from a remote Linux VM on another platform (on-prem, cloud, etc.) to a new OpenStack Flex virtual machine.

1. Planning Your Migration

Understand the Source Environment

Before you move anything, it's critical to assess your source environment. The source environment is the location where the data resides currently - where you will be migrating from. Consider the following:

  • Workloads in Use: Files, databases, apps, cron jobs, background services, etc.
  • System Configuration: OS versions, installed packages, user accounts, and customization.
  • Network Restrictions: Can your source system reach the OpenStack VM via SSH/SCP/SFTP?

Understand the OpenStack Flex Destination Environment

You’ll be working within your project in OpenStack Flex. Since this is a multi-tenant shared environment you won’t be able to access the underlying infrastructure such as the hypervisor, network, or storage backend. What you'll need to focus on is the following:

Key things to know:

2. Security & Access Considerations

  • SSH Key Pair : Most OpenStack environments require you to associate an SSH key pair at VM creation time. This is not a requirement as password authentication can be selected - but is not recommended.
  • Firewall Rules (Security Groups ): Ensure inbound ports (e.g., SSH, RDP, application ports) are allowed.
  • Floating IPs: Assign a public IP if your destination VM must be reachable from the internet.

If you can’t connect directly between source and destination (e.g., firewalls block direct SSH), you may need to:

  • Use an intermediate staging server
  • Push data from source to the OpenStack Flex VM
  • Pull data from the OpenStack Flex VM using tools like scp or rsync with NAT-friendly flags

3. What Should Be Migrated?

It's critical to know what should and shouldn't be migrated. You do not want to just blindly copy everything from a VM onto another VM and overwrite the destination. This will likely lead to unintended consequences and problems. Instead, migrate only the essential and required data to the new environment. Below is a list to help you think through data that may need to be moved.

ComponentWhat to consider
Application filesAre they portable? Do they need specific directory paths or users?
DatabasesDump and transfer, or export via tools. Match DB engine versions.
User accountsMay need to recreate users with the same UID/GID if permissions matter
Cron jobsThese are not migrated automatically—recreate manually
Services/DaemonsEnsure dependencies and config files are installed on new system
Scripts/AutomationConfirm any scripts that reference IPs, paths, or platform-specific features are updated

4. Preparing the OpenStack Flex VM

If you haven't already provisioned your OpenStack Flex VM(s) on the destination, be sure to consider these before building out the destination devices:

  • Choose the Right Flavor (CPU, RAM, Disk)
  • Pick a Compatible OS Image (ideally similar to source)
  • Attach any necessary Volumes (for persistent storage)
  • Enable Security Group Rules for SSH (22/tcp) or RDP (3389/tcp)

5. Migration Approaches

Because you'll be migrating into the OpenStack Flex ecosystem you may need to rely on file-based migration methods:

Common Data Migration Options:

  • rsync over SSH: Good for structured, incremental transfers.
  • SCP/SFTP: Simple, but not ideal for very large data sets.
  • Compressed Archives (tar, zip): Good for packaging and reducing transfer size.
  • Database dumps: Use tools like mysqldump, pg_dump, then transfer and restore.

If source and destination VMs are not routable to each other, consider transferring data through your local workstation or using a cloud storage service (if allowed by your organization).

Snapshot Migration Options:

The OpenStack Flex environment you're migrating to uses KVM hypervisors, which support virtual machine disk images in the following formats:

  • QCOW2 (recommended): Offers features like compression, snapshots, and copy-on-write performance. Ideal for most workloads.
  • RAW: A simple, unstructured format. Offers slightly better performance in some cases but consumes more space.
  • ISO: Primarily used for installation media or live CDs, not for full VM disks.

If you're migrating a complete VM image (rather than just data and workloads), ensure your image is in one of these supported formats. When preparing a custom image to upload to OpenStack:

  • Convert your disk image using tools like qemu-img if needed.
  • Strip platform-specific drivers or agents that may conflict
  • Ensure the image is compatible with KVM

You can upload your image file into your OpenStack Flex project under the Compute > Images > 'Create Image' section of the Skyline UI.

NOTE: Imported Snapshots cannot be fully supported by Rackspace technical support in all cases due to the wide range of potential changes brought along from other platforms.

6. Downtime and Syncing

If migrating live services or active databases you'll want to plan for downtime:

  • Schedule a final downtime window for:
    • Stopping services
    • Performing a last sync or data dump
    • Swapping DNS or IP mappings
  • Use read-only mode (if supported) to minimize data changes during transfer. This will help ensure that data is not corrupted or partially captured.
  • It is critical that you keep your source platform up and running until you've completely validated that everything is working well on the OpenStack Flex destination.

7. Common Issues in Public Cloud Migrations

IssueRisk
UID/GID MismatchesFiles may become inaccessible if permissions break
Firewalls/SGs block trafficSSH or RDP won't work until you allow ports
Wrong SSH key setupLock yourself out of VM if you forget to upload keys
Missing software packagesApp may break if dependencies aren't reinstalled
OS image differencesSome system paths or behaviors may differ from source
Private IP conflictsDon’t assume your new VM has the same IPs as the old one
Timezone differencesCan affect cron jobs and logs

8. Validation and Post-Migration Steps

After the migration:

  • Verify service functionality (apps, daemons, web interfaces)
  • Check file ownerships and permissions
  • Test application logic and scheduled jobs
  • Update DNS records or service endpoints
  • Enable backups and monitoring in the new environment

Consider running the new VM alongside the old one briefly as a fallback.

Summary Checklist

TaskDescriptionStatus
Document source servicesList what's running and what's needed
Provision OpenStack VMUse correct image, flavor, and SSH key
Configure access & security groupsOpen necessary ports, assign floating IP
Transfer dataUse rsync, SCP, or archive + restore
Install dependenciesRebuild software stack, user accounts
Verify & test servicesApplication-level testing and logs
Final switchUpdate DNS, shutdown old VM (if needed)

Final Advice

  • Test the process with a non-critical VM or small workload first.
  • Try building out and migrating to a development environment first.
  • Do NOT delete resources on your source platform until you've successfully moved and tested on the destination.
  • Automate common steps (e.g., user setup, package install) with scripts.

What’s Next

Read more about OpenStack Flex here!