Planning a Migration to 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 Rackspace OpenStack Flex virtual machine.

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.
• Critical versus Non-critical resources: Not everything needs to be migrated over, identify what if anything should be migrated, and what should be built from a fresh install.
• 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 Rackspace OpenStack Flex Destination Environment

You’ll be working within your project in Rackspace 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:

• You provision and manage VMs via the self-service interface called Skyline .
• You can:
  • Choose OS images and VM types (from a predefined list)
  • Assign Floating IPs for external access
  • Manage your own SSH keys
  • Use volume based storage
• You cannot:
  • Customize networks beyond project-level isolation
  • Use nested virtualization
  • Use Admin APIs to manage underlying infrastructure or projects not your own

NOTE: The current Rackspace OpenStack Flex platform does not contain the following types of products currently found on our original Rackspace Cloud:

• RackConnect
• Cloud Databases
• Cloud Files CDN
• Rackspace CDN

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 or Load Balancer 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

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.

Preparing the Rackspace OpenStack Flex VM

If you haven't already provisioned your Rackspace 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)

Migration Approaches

Because you'll be migrating into the Rackspace 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.
• Rackspace Backup Agent: This tool was designed for use in our original Rackspace OpenStack Public Cloud - but can be installed on another VM like a Rackspace OpenStack Flex VM. So if you're already using our Rackspace Cloud, then after configuring the Backup Agent on a Rackspace OpenStack Flex VM with your Rackspace Cloud username/API key it will create a listed System and Destination for restores - as well as making Rackspace OpenStack Flex able to back up data to OSPC's Cloud Files (egress data is billed on OSPC though). You just need to be sure that when you are running the configuration command you set the --flavor to dedicated rather than raxcloudserver. For more information on the steps necessary to migrate data using the Rackspace Backup Agent, see this guide

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 Rackspace 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.

Windows Specific Challenges

When we cannot simply export/import a Windows VM (e.g., due to incompatible hypervisors, licensing, or architecture differences), and instead must migrate the data, applications, and configurations from one Windows environment to another, there are a number of Windows-specific challenges that go beyond generic “server migration” problems that we need to be aware of.

Registry and Application Configuration

Many Windows apps store critical settings and licenses in the Registry, not in config files. Simply copying program files rarely works — you often need to reinstall or export/import registry keys. Registry entries can contain absolute paths and machine-specific GUIDs that break on the new VM.

Security Identifiers (SIDs) and Permissions

User and service accounts have unique SIDs, so even if you recreate accounts with the same name, NTFS permissions, scheduled tasks, or services won’t automatically map correctly. This is a huge source of “it runs but can’t access data” issues. Use domain accounts where possible — local accounts almost always cause ACL problems after migration.

Windows Authentication and Services

Services configured to run under local accounts or with “Log on as” credentials may fail to start after migration. Applications using Windows Integrated Authentication (IIS, SQL, etc.) often need SPNs, certificates, and permissions reestablished.

File and Data Migration

NTFS permissions and ownership can get lost if files are copied incorrectly. Use:

robocopy source dest /MIR /COPYALL /SEC

Check drive letters and paths — many Windows apps use hardcoded paths that differ between environments.

Certificates and IIS

SSL/TLS certs live in the Local Machine certificate store — they do not transfer with file copies. IIS site bindings, AppPool identities, and machine-specific settings (like Windows auth) need manual recreation or export/import.

Domain, DNS, and Policy Differences

Moving between networks or AD domains can cause name resolution and Group Policy issues. Applications that depend on specific FQDNs or domain trust relationships may fail silently.

Summary

Most breakages happen because Windows ties so much to machine identity — registry, SIDs, local certs, and authentication contexts. The safest migration strategy is to:

1. Reinstall applications cleanly.
2. Copy data with ACLs intact.
3. Recreate service accounts and certs.
4. Reapply configuration manually or via scripts (PowerShell, GPO, etc.).

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 Rackspace OpenStack Flex destination.

Common Issues in Public Cloud Migrations

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

Final Advice

• Test the process with a non-critical VM or small workload first. Once you understand the process and have determined a workflow that is comfortable and repeatable - attempt on more important VMs.
• 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.