- Users must enable IPv6 locally on their MCP 1.0 servers, as IPv6 is utilized for the Client-to-Site VPN functionality in MCP 1.0 as described in How to Connect to a VPN with Single-Factor or Multi-Factor VPN Authentication
- This is a TCP/IP property in the Guest OS, which must be enabled locally to utilize IPv6
- VM Tools should be be up-to-date and running on All MCP 1.0 Source Servers that will be migrated
- See How to Update VMware Tools on a Cloud Server
- Source and Target Locations must be enabled for DRS for Cloud
- See How do I Identify Hardware Specifications and Capabilities Available in a Data Center Location
What cannot be migrated using this procedure?
- Organizations with *Complex Setups (refer to FAQ), including MCP 1.0 CPNC connections, are more likely to need Cloud Support team assistance.
- Please contact us well in advance of your planned migration for assistance.
- Some Virtual Appliances do not support replication
- Some virtualization appliances do not support the disk replication used by DRS for Cloud. If testing indicates this does not work, clients will need to re-import any appliance as a fresh device
- Windows 2003 Guest OS Customization Images will not work in MCP 2.0. See What Operating Systems are Currently Supported on CloudControl?
Steps to Prepare for Self-Service Migration
- Review your MCP 1.0 environment and eliminate unnecessary assets
- Review current Cloud Servers in the MCP 1.0 location. Delete any that you do not require on MCP 2.0
- Review any Client Images that you have deployed in the MCP 1.0 location. Delete any that do not require on MCP 2.0
- Consider your MCP 1.0 ACL Rules and any firewall rules that may be implemented directly on your Cloud Servers. It is likely that a subset (or all) of these will need to be recreated as MCP 2.0 Firewall Rules in a later step.
- Assess your downtime requirements
- Identify your mission-critical systems and calculate the downtime you can take
- Follow step 6 to migrate any machine(s) that can be shut down or which might require a longer downtime
- Create a Network Domain in the corresponding MCP 2.0 location (this will be your "Target" location)
- Deploy an MCP 2.0 Network Domain in the Target MCP 2.0 location as described in How to Deploy a Network Domain in a MCP 2.0 Data Center Location
- MCP 2.0 supports multiple VLANs in the same Network Domain so for most users, only a single MCP 2.0 Cloud Network Domain will be required
- For each MCP 1.0 Network, deploy a VLAN in the MCP 2.0 Network Domain to support your Cloud Servers
- You can configure each VLAN to match the Source Cloud Network's IPv4 Addressing. Unlike MCP 1.0, MCP 2.0 allows users to define their IPv4 address space. For details, see Introduction to IP Addressing in MCP 2.0
- Add Public IPv4 Blocks to support your needs. See How to Manage Public IPv4 Addresses on a Network or Network Domain
- Unlike MCP 1.0, a Cloud Network Domain does not include any public IPv4 addresses by default.
- Create Equivalent Firewall Rules on Your MCP 2.0 Target
- Create Firewall Rules on the MCP 2.0 Target Network Domain to match the MCP 1.0 Source Network's intent as described in How to Create a Firewall Rule on a Network Domain.
- Note firewall behavior is different in MCP 2.0. The default rules are different - traffic between VLANs is denied by default. For more details, see Introduction to Firewall Rules for Cloud Network Domains in MCP 2.0
- Copy Client Images from MCP 1.0 Source location to MCP 2.0 Target location
- This function does not use the DRS for Cloud feature as it applies only to Cloud Servers. Instead, use the function described at How to Copy a Client Image between Locations in the Same Geographic Region
- Copy powered off MCP 1.0 Servers from MCP 1.0 Source Network to MCP 2.0 Target Network Domain
- If the server isn't running, the DRS for Cloud feature isn't needed. Instead, use the function described at How to Copy a Stopped MCP 1.0 Cloud Server to an MCP 2.0 Data Center Location
- For each powered on MCP 1.0 Source Server, Create a DRS Target Server attached to the associated VLAN
- Details on this function are available at How to Create a DRS Target Server. Make sure you assign the DRS Target Server the same private IPv4 address as the Source Server. This ensures that the CloudControl IPv4 record will be accurate when the DRS Preview step is implemented below.
- MCP 2.0 supports multiple NIC's but since you're migrating an MCP 1.0 Cloud Server, it will only have one NIC.
- Create Consistency Group(s) that Pairs your MCP 1.0 "Source" Servers to the MCP 2.0 "Target" Servers
- Details on this function are available at How to Create a DRS Consistency Group
- Identify the servers that need to be migrated with the server state as of the same period in time and group them together in the same Consistency Group.
- You will need to wait for the Consistency Group to replicate, which can take several hours
- You can monitor the state as described in How to View and Clean your Consistency Groups
- You can test your migration by putting the Consistency Group(s) in DRS Preview mode using a DRS snapshot
- This brings up your Target Servers with the same disk state as the Source Servers as of the snapshot time. Details on this function are at How to Start a DRS Preview for a Consistency Group
- Use the most recent available DRS Snapshot
- Once the Consistency Group is in Preview Mode, you can log into any Target Server using the console option and verify its configuration.
- If you configure the NIC in the Target Server Guest OS with IPv6, you will be able to use that IPv6 to log in via the Client-to-Site VPN described in How to Connect to a VPN with Single-Factor or Multi-Factor VPN Authentication
- We recommend confirming the NIC configuration in the Target Server's Guest OS with the CloudControl record.
- Note that if your application leverages inbound public IP traffic, you'll need to configure equivalent connectivity to your new public IP addresses:
- MCP 2.0 NAT functionality is similar to MCP 1.0. See How to Create a NAT Rule on a Network or Network Domain
- MCP 2.0 uses Virtual Listeners instead of MCP 1.0 VIP functionality. For an overview, see Introduction to Virtual Listeners / VIPs in MCP 2.0
- You should ensure your DNS entries are prepared to support a migration to the new MCP 2.0 public addresses by making sure the TTL (Time to Live) is short
Steps to Implement Self-Service Migration
When you are ready to migrate, the actual migration is multi-step, one-way process:
- Put your MCP 1.0 assets into maintenance.
- Put the Consistency Group(s) in DRS Preview mode, in the same manner, you did for testing.
- Apply IPv6 addresses to the Target Servers as was done in testing.
- Confirm the application is ready to migrate prior to the next step!
- Commit the DRS Preview State as described in How to Initiate a Failover for a DRS Consistency Group
- The workload on the MCP 2.0 Target Server will be powered on and the corresponding workload in MCP 1.0 will be powered off
- The Consistency Group will be removed as part of this process, so it's a one-way change.
- If for some reason you need to fail back, you can power off the Server in MCP 2.0 and power the MCP 1.0 Server back on but to re-initiate migration, you will need to re-configure all of the Consistency Group(s)
- Optional but recommended, consider your SSL Certificate configuration
- MCP 2.0 offers a convenient means of SSL certificate management through the SSL Offload feature, which removes the need to apply your certificates directly on your Cloud Servers. For full information please refer to Introduction to SSL Offload, including SSL Domain Certificate, SSL Certificate Chain, and SSL Offload Profiles, which includes links to articles describing how to set up an SSL Offload configuration in addition to explaining how the feature works.
- As needed, update DNS records to the new Public IPv4 on the MCP 2.0 side
- You will need to work with your DNS provider support team to change the DNS setting
- If you use Cloud Monitoring, disable Cloud Monitoring on the MCP 1.0 Source Server and enable on the MCP 2.0 side.
- To disable to MCP 1.0 side, see How to Disable Cloud Monitoring for a Server
- Stopping Cloud Monitoring will delete historical data. You can download reports before you disable in case you need to preserve the historical data.
- To enable the MCP 2.0 side, see How to Enable Cloud Monitoring for a Server
- If you use Cloud Backup
- Backup history or retention cannot be moved to MCP 2.0
- If you do not need a backup history of the MCP 1.0 server, simply delete backups from MCP 1.0 as described in How to Delete a Backup Client on a Cloud Server and How to Disable Cloud Backup for a Server
- If you wish to keep the backup history available for a period of time, you can detach the history as described in Detaching a Backup Set. However, you cannot restore onto the MCP 2.0 server in a self-service manner. To restore onto MCP 2.0, you will need to open a ticket with backup support to perform a restore on your behalf
- In either case, you may want to change your backup approach on MCP 2.0:
- Many MCP 2.0 locations support a newer alternative called Cloud Server Snapshots. See Introduction to Cloud Server Snapshots
- Alternately, you can enable the same Cloud Backup feature on MCP 2.0 as described in:
- How to Enable Cloud Backup on a Cloud Server
- How to Install the Backup Client on a Linux Server and How to Install the Backup Client on a Windows Server
- Additional Steps to Enable Application Backups once Client is Installed
- When complete, delete your MCP 1.0 assets and take advantage of the new capabilities MCP 2.0 offers.
- The current MCP 1.0 Cloud environment meets all my needs. As such, why would I want to migrate to the MCP 2.0 environment?
There are several compelling reasons to migrate to the MCP 2.0 environment. MCP 2.0 utilizes the latest in “best-of-breed" technologies to service its many cloud customers. In addition, there are several services and features available in the MCP 2.0 environment that are not available in MCP 1.0. These include, but are not limited to the following: Cloud Server Snapshots, Provisioned IOPS, various Network Domain Options, and reduced compute pricing. In addition, there are more pricing options available to customers in MCP 2.0. Finally, as part of NTTC CIS's guiding principle of continuous improvement, we will be retiring the MCP 1.0 platform.
- Can I actively use my MCP 1.0 environment during the migration?
Customers cannot modify the hardware assets during the migration process, however, customers can make changes to the operating systems (OS).
- Is the migration process encrypted?
Yes, the migration process is encrypted. The source and destination storage arrays are encrypted, and the data is transferred via encrypted tunnels.
- What are the risks to the client in migrating from MCP 1.0 to MCP 2.0?
Risk is minimal as the Source MCP 1.0 environment will exist until the customer deletes it post migration validation. Clients will have the ability to validate their MCP 2.0 location servers prior to final cutover.
- When will the MCP 1.0 platform be retired?
Timelines for the inevitable retirement of MCP 1.0 are still being confirmed. Meanwhile, we are engaging with our clients early on so we can provide appropriate support and allow time to schedule the migration to lessen the burden on the client.
- Who is the target audience for Migration?
All customers on MCP 1.0 infrastructure (Public Cloud, Hosted Private Cloud, Provider Cloud) are part of the target Migration audience.
- *What is a Complex Setup?
Any client that has multiple CPNC or interconnects, significant numbers of Servers in multiple Data Centers and/or Geographic Regions, Static Route configurations, or physical devices.
If a screenshot is necessary and is very large, please resize to 80%. Add a Border to any Screenshots. "Notes" should be "Paragraph" heading with "Note" in Bold and the content in regular text.
Content by Label Macro. Related articles appear here based on the labels you select. Click to edit the macro and add or change labels.