The Problem.

During my career I have carried out numerous migrations for businesses moving to new infrastructure or to another IaaS or cloud provider. The process is usually tedious, slow and complex with the normal mop-up at the end, but you get there. There is always some issue that will bite you.

I have used a vast array of tools and software from the major vendors over the years, most of which involve installing an agent on the source server, configuring up the migration job with its hundred and one options and hitting go. Invariably, you get failures mid-flight, some compatibility issue or some post-migration script that failed and you have to repeat the process. The process is never automated end-to-end or easy to work with. No two migrations are the same.

The amount of professional service dollars incurred by businesses for specialists to carry out these manual or semi-automated migrations can be huge. Time equals money and sometimes migration projects just don’t get off the ground due to the unknown time frames, cost or high failure rates. Migrating to the cloud for example which seems cheap looking at the per hour costs can take years to return value to the business when you factor in these migration costs.

We all live in a cloudy world now, there are cloud offerings everywhere. This has only added to the migration complexity. How do we handle porting between on-premises VMware to AWS, Physical to Cloud, Cloud to Cloud, AWS cross-region or return your cloud VMs back in-house? How do we look after the conversion of the VM format when moving cloud providers.

So I went hunting for a cloud-based SaaS based offering. I was looking for a product that had a low overhead of configuration, was agent-less, supported all the major cloud vendors, looked after physical to cloud migrations and had a simple and intuitive user interface. It needed a high-degree of automation to lower migration time and cost and the ability to consume cloud APIs.

The Solution

I came across RiverMeadow Software, Inc. who are based in San Jose, CA. Their product RiverMeadow Cloud Migration SaaS looked great and exactly met the requirements I was looking for.

I was lucky to have a discussion with RiverMeadow’s John Merryman (Vice President) and Michael Kent (Director, Pre-Sales Engineering) about their RiverMeadow SaaS product and was kindly offered some free migrations so I could run through the process end to end. Thanks RiverMeadow!

You can purchase migration licences direct from RiverMeadow in quantities that get cheaper with scale or subscribe to RiverMeadow SaaS via the Amazon Web Services (AWS) MarketPlace portal. Put your credit card details in there and get billed per successful migration with 30 days of included differential migrations allowed on the original. I thought the pricing was quite reasonable.

I ran two separate migration tests from source to target cloud. At the end I was just amazed at how simple RiverMeadow have made the process. It was so straight-forward. All API driven and automated with built-in pre-flight checks. The entire process starting at the AWS MarketPlace, being re-directed to RiverMeadow’s portal, configuring the source and target was so simple and easy. Oh, and the migrations just worked, even powering off the source at completion meaning very little downtime at the final cut over.

From Anywhere To Anywhere

With RiverMeadow you can quickly migrate from any source (physical, virtual or cloud) to any supported target cloud (private, hybrid and public). Virtual to Cloud, Cloud to Cloud, Physical to Cloud, VMware to VMware, AWS cross-region. It covers a wide range of use cases and is hypervisor agnostic.

It has some great features built into the product like Destination Isolation to reduce network conflicts and the Differential Migration option to keep the target in-sync with the source. It supports Windows and Linux as source operating systems and they can be physical, virtual or cloud based.

Currently RiverMeadow SaaS supports AWS, VMware vCloud Director and VMware vSphere as target (destination) cloud environments. Check the RiverMeadow documentation portal to see the full range of features and supported operating systems versions and target cloud requirements.

My Test Environments

My cloud environments are provided by theCloud, a leading New Zealand based provider with platforms in Auckland, Hamilton and Wellington. Thanks goes to theCloud for allowing me to run these migrations on their vGRID platform powered by VMware vCloud Director (vCD) which allowed me to capture all the screenshots for this blog.

I have a separate vCD instance in Auckland and Hamilton, each with its own stand-alone Edge Services Gateway and public IP address. My migration tests fall into the cloud to cloud category (VMware vCD to VMware vCD). As this is vCD – the VMware API is available externally for consumption.

Network Requirements

You need a routable path between your source and target (destination) environments so the data blocks can be replicated. This was achieved by a Site to Site IPSEC VPN.

Only a few firewall ports are required to be open between the source and target for RiverMeadow SaaS.

The target additionally needs firewall ports open to RiverMeadow SaaS, which will talk directly to the target cloud API to automate the migration.

Cloud Appliance & Target Workers

RiverMeadow SaaS deploys into the target environment a single Cloud Appliance (CA). It also deploys a Target Worker (TW) for every workload being migrated.

The Cloud Appliance collects metadata and attributes from the source to model a Target Worker. These attributes consist of operating system, memory, network, storage and CPU etc.

The Target Worker replicates the source workload and has customisations applied if selected at migration time such as an increase in CPU or memory, server host name or IP addresses.

Migration to VMware vCD – High Level

For each full migration that is classified a success you can then carry out a Differential Migration for 30 days that allows you to keep the source and target in sync. If you are going to use this feature, make sure you plan ahead as it’s only available for 30 days otherwise a paid migration extension will be required. The differential is a great option that allows you to after the first full migration of the source do the deltas and then cut over with a small outage.

Differential Migration – High Level

This workflow shows a Differential Migration being applied to a VMware vCD cloud migration after the initial full migration.

Configuration options are available in the portal, one being the ability to shut down the source VM and bring up the destination VM at the target site.

Destination Network Isolation – High Level

To reduce network conflicts such as duplicate IP addresses or Active Directory clashes you can use the Destination Network Isolation feature. This allows you to stage your migration into the target using the same server names and IPs without impact. It sits in a secondary isolated network where you can run Differential Migrations and then cut over, at which point it will drop into the correct primary network you selected.

Migration Requirements

All of this information is available on the RiverMeadow SaaS document portal.

These requirements are for a migration into VMware vCloud Director (vCD)

Source:

• Source operating system is supported.
• Source operating system requirements have been met.
• You have the source usernames, passwords and the correct permissions.
• Firewall network ports have been opened.

Target Cloud:

• Confirm your target cloud meets the requirements.
  • For VMware vCloud Director this is:
    • The vCD version.
    • vCD Catalog access and permissions.
    • Must have enough compute and storage available.
    • Provisioned virtual network.
    • Firewall network ports have been opened.
    • External API access and URL
    • vCD Organisation Name.
    • Correct usernames and passwords to vCD Organisation.
    • Correct roles assigned within vCD Organisation.
• Cloud Appliance deployed.
• Sources defined.

Migration Walk Though

So lets see this all in action from start to finish. I will utilise the AWS MarketPlace for the RiverMeadow SaaS subscription and billing.

As mentioned above, this is a cloud to cloud migration – from a vCloud Director environment in Hamilton to a vCloud Director environment in Auckland. My cloud provider has the vCD APIs externally published for consumption.

The process is identical if you were looking to lift and shift on-premises physical machines to the cloud.

My migration will lift and shift a Windows 2012 R2 VM to the target cloud. I will change the server name and IP during the migration. To keep it simple for this demonstration I am not using the Destination Isolation feature – just simply migrating the VM to the target cloud with a rename and new IP.

Breaking the migration down into pieces for a blog does make the migration seem long-winded, but I assure you that it has taken longer to write this blog than it has taken to do two RiverMeadow SaaS migrations from scratch.

Step 1: AWS MarketPlace

Hit the AWS MarketPlace in your browser.

If you do not already have an AWS MarketPlace account create one. During that process you confirm your email address, login password and credit card details for billing.

Once you have an AWS MarketPlace account, search for RiverMeadow SaaS. Click the Continue button. This will walk you through subscribing to the product.

Below shows the RiverMeadow SaaS subscription page on the AWS MarketPlace.

Once you have subscribed you will receive an email from AWS confirming your subscription.

You will also receive an email from RiverMeadow asking you to confirm your email. Click on Confirm your email. This process will also allows you to confirm your RiverMeadow password for the portal (the username is your email address).

Step 2: RiverMeadow SaaS Portal

The URL for the RiverMeadow SaaS portal is: https://migrate.rivermeadow.com/

Enter your RiverMeadow credentials to login to the migration portal.

Once logged in you are presented with the initial welcome screen.

At the top of the page you have the Migrations and Manage tabs. This is where you configure, start and view migrations and also configure your target cloud and sources.

Step 3:  Check & Confirm Prerequisites

Make sure you check and confirm all prerequisites have been met. This includes having a routable path to source from target, firewall rules, operating system and cloud versions.

You need to have access to the usernames, passwords and permissions to the source machines and to the target cloud environment.

For a smooth migration double-check you have all this prior to starting!

All information regarding prerequisites are available at the RiverMeadow SaaS document portal.

Step 4: Setup Target Cloud

From the RiverMeadow SaaS Migration portal, at the top of the page click the Manage tab – then click Target Cloud. You will be presented with the following screen.

Click the Add New Target Cloud Account button.

You now get to choose your target cloud: AWS, vCloud or vSphere.

I have selected vCloud as I am migrating to vCloud Director.

This then presents you with a screen that needs to be populated with the relevant details to connect to the target cloud. Once the correct information is entered click the Test Connection button which will attempt to connect to the target cloud API. As you can see my connection was validated and I can now click the Add Target Cloud Account button.

Also note in the above screenshot the box is ticked for Setup Cloud Appliance.

Once you click the Add Target Cloud Account it saves the target cloud to the RiverMeadow SaaS migration portal and then will start prompting you for information to deploy the cloud appliance. The cool thing here is the deployment is automated and communicates with your target cloud by the API.

You can now populate the information required to deploy the Cloud Appliance into the target cloud.

Once you have entered all the correct information, click the Initiate Cloud Appliance Checks button.

 

RiverMeadow SaaS will now start doing its pre-flight checks.

 

If all the pre-flight checks pass then the Cloud Appliance will start deploying into your target cloud.

 

From within the vCloud Director portal I can see the Cloud Appliance being deployed into a new vApp all via the API – I love automation!

While the Cloud Appliance is deploying you can move on and start configuring your source. I waited for it to deploy. It took around 10 minutes

Step 5: Add Sources

From the RiverMeadow SaaS Migration portal, at the top of the page click the Manage tab – then click Sources. You will be presented with the following screen.

Click the Add Source button.

This is where you add all the information for a single source server. Repeat this process to add as many sources as you require. My source is a Windows 2012 R2 server sitting in another vCloud Director environment. Don’t forget you need a routable path between the source and target.

Click the Add Source button once you have entered all the information.

The source is then added, but at this point has not been inspected by RiverMeadow SaaS.

Step 6: Configure & Start Migration

From the RiverMeadow SaaS portal, click on the Sources tab at the top of the screen.

Tick the box next to your source and then click the Inspect Sources and Configure Migration button. For me this is my 192.168.15.100 source.

 

You are then prompted to select your target cloud. Once you have selected the target cloud, click the Check Migration Readiness button.

 

RiverMeadow SaaS then runs the readiness checks.

 

All the readiness checks have passed, tick the box next to your source machine and then click the Create Migration Profile button.

The following shows all the options available that can be applied during this migration. As this is the first migration on this source this will be a full migration and then following I can run Differential Migrations for 30 days on the original source.

The only options I have chosen to change for this test migration are:

• I am changing the target VM server name – from HAMVM001 to AKLVM001
• I am changing the target NIC to Static Manual and giving it a new IP address and associate details.

The migration is scheduled to run straight away once I click the Continue button.

Migration pre-flight checks commence. I love that RiverMeadow does this prior to starting so the migration doesn’t fail mid-way for some obscure reason.

Once the pre-flight checks have passed the migration auto starts.

From the vCloud Director portal I can now see the target VM being staged.

Back in the RiverMeadow SaaS portal you can see the migration steps that have completed, in progress and to be completed.

Once the migration is complete you will receive an email from RiverMeadow advising of this. The migration took a total of 37 minutes.

From the RiverMeadow SaaS migration portal I can see the migration has a status of Complete.

Not best practice, but I did not select the shutdown option when I configured the migration job  – so both my source and target VMs are operational. I wanted to show you this when I do the Differential Migration.

In a real world deployment I would more than likely use the Destination Network Isolation feature so the target VM is ring-fenced from production until cut over time to avoid any conflicts such as AD or IP duplicates etc.

Next I will proceed to do the Differential Migration and I will show you the shutdown option and use it for the final cut over.

Step 8: Final Differential Migration

The Differential Migration feature allows you to migrate only the differences between source and target server. You can run a Differential Migration on the original, complete migration for 30 days. Past that date you will need to obtain a migration extension (which  costs) so make sure you plan ahead!

Make sure you read the RiverMeadow documentation about Differential Migrations. You can include/exclude specific items and it only captures changes at the file and directory level, so if your source server is a SQL database server then the database will need to be quiesced prior to the final differential to capture all the changes.

To run a Differential Migration:

From the RiverMeadow SaaS migration portal, click on Migrations, then View Migrations.

Select a migration that has completed already (tick the box next to it) for which you wish to run the differential.

Click the Start Differential Migration option (looks like a refresh button at bottom right).

The following screen appears with the following options. I provided the job name, selected block-based, tick the drive letters I want to run the differential on and lastly ticked the box for shutdown source. I then click Confirm and Initiate Migration.

 

Pre-flight checks once again prior to the migration.

 

Once pre-flight checks have completed the Differential Migration commences.

Once the Differential Migration has finished you will receive an email from RiverMeadow and in the portal you will see the migration marked as completed. The migration took 21 minutes to complete.

I confirmed my source server had been powered off and also confirmed my target server was operational.

If this was a production migration I would for sure utilise the Destination Network Isolation feature so the target is staged in a secondary network. The source is up and online the entire time, there are no target server clashes of any sort and during the final Differential Migration I choose to shut down the source which drops the target into the correct destination network.

There are many use-cases for RiverMeadow SaaS and just like any migration there are additional post-migration tasks that would need to be carried to fully complete the transition i.e. DNS changes. These changes all depend on your migration so I cannot list them out here.

Final Thoughts?

The best migration software I have ever used. It just works. It was fast, reliable and the pre-flights checks give you trust that your migrations will be a success.

I did two full and two differential migrations with no issues experienced at all. Being a SaaS cloud based platform the ability to access multiple clients sites from one portal is awesome.

It has all the features I was looking for and more, importantly it can consume cloud APIs which offers a high-level of automation and is hypervisor agnostic.

I think this is a great tool for cloud service providers to on-board new tenants. Cloud specialists and consultants can also use it for on-boarding and additionally for migrations between cloud providers. It just removes so many of the hurdles you normally experience which in-turn lowers the time, cost and risk.

The ability to carry out automated migrations from on-premises physical servers to the cloud, between cloud or back on-premises is a winner for me. I just see so many use-cases.

Overall, great product. Recommend it.

Thanks again to RiverMeadow and theCloud for allowing me to run these migration tests free of charge.