How to do Cloud Migration the Right Way

Successful cloud migration requires an absolutely accurate analysis of an existing IT deployment. This includes the hardware, the software, all running services, and the interdependencies between them. Once these are known, the deployment can be broken into ‘chunks’, otherwise known as ‘move groups’ or ‘migration groups’ which are smaller, self-contained groups of hardware, software, and service dependencies that can move as a unit. These ‘move groups’ then must be matched with a proper target, or “right-sized” to their proper cloud instance size. The overall process goes something like this:

    1. Initial Discovery: Utilize a process like Device42’s autodiscovery to find all running applications and services, as well as the physical, virtual, and other network connected devices that are supporting them. Create a detailed map of your infrastructure including all relevant CI details and their interrelationships.
    2. Create Migration Groups (a.k.a. ‘Move groups’): Select one or more applications and their supporting hardware interdependencies to move as a unit.
        1. Run full discovery against the application’s supporting hardware.
        2. Collect dependency details for the relevant applications that are part of the move group.
        3. Match the application’s processing and memory workload (resource utilization) with the properly sized cloud target instance.
  1. Migration: Execute the actual logistical move of each migration (“move”) group.
  2. Readiness Check: Ensure that the migrated application, now running in the cloud, is functioning as expected, cut over production traffic, and then decommission the legacy application.

Initial Discovery

Obtaining that true understanding of an existing deployment is in almost all cases much easier said than done. Across the IT universe, various parties have abused the term “discovery” to the point of semantic satiation. It has been repeated to the point where all but its most basic meaning (in the context of either CMDB’s, ADM systems, DCIM systems, or ITAM systems alike) has been lost.

This has been a disservice to the IT community at large, and left a wide gap to be filled by a product that could re-define discovery, finally bringing “True discovery” to market. Anyone who has ever been involved in a cloud migration knows how important accurate discovery is, and the pains that obtaining that invaluable data can cause.

Device42 has undertaken the challenge of re-defining discovery, bringing the first “True discovery”, product to market. Device42 is not doing the discovery of yesteryear: Device42 delivers actionable data that can be directly put to use in making migration-related decisions – “True discovery”.

“A single source of truth system provides IT personnel with practically everything they need to know about their physical, virtual, and cloud servers and network components as well as complete application and dependency maps.” – IDC

When it comes to “True discovery”, Device42 is in a class of its own. Device42 simply discovers the “right data”. Device42’s CMDB accomplishes a first in the world of the Single Source of Truth (SST) because it, as opposed to creating proprietary data formats and locking customers in, instead has chosen to become an open, centralized platform for powerful data federation. Setting new standards with the ease at which data both enters and leaves the system, Device42 has re-defined both “discovery” and the role of the CMDB.


“…this information should be available from within most IT systems such as monitoring, security, service management, enterprise architecture, portfolio management, change and configuration management, and financial management systems.” – IDC


Device42 unifies the data silos that exist around your environment, and presents both an easy to use web interface for direct human consumption, API-based access for machine-readable data input and output, as well as SQL database access via DOQL, to create custom output, meaning all a migrator has to do is write a query, and the Device42 responds with the requested data, no matter where it originated: anything from an Excel spreadsheet to an ITSM system to another vendor’s CMDB system is welcome, easily, and openly imported into Device42 [and is easily exported, too].

Create Migration Groups

Once Device42’s initial discovery is complete, the accurate data in Device42’s CMDB can be used to select hardware or application members and dependencies to create your ‘move groups’. Move groups  [aka “migration groups”] consist of groups of interrelated and interdependent servers (and possibly supporting systems if migrating to a hybrid environment). Device42’s “true discovery” uses a multitude of methods to produce accurate application dependency mapping (ADM) data, which forms the cornerstone of move group creation.

Relevant applications are selected, and the aforementioned application workloads are then ‘right-sized’. The rightsizing process entails either or both of dividing the workloads into sub-workloads to fit given size instances, and/or choosing the best matching cloud instance sizes for a given workload. The availability of key performance data metrics from the Device42 single source of truth (cpu, memory, disk, and network IO/utilization) allow workload right-sizing decisions to be made, as workload utilization allows accounting for both average load and peak transient loads.

“By leveraging a comprehensive single source of truth that offers visibility into all the systems and applications in the organization, [..] unnecessary security risks as well as financial and operational inefficiencies associated with the over/under purchasing of IT systems and applications [can be reduced -SIC].”


As this process continues in the background for the next group, the initial group is migrated. The migration is followed by a readiness check, and the entire time, discovery continues running, picking up the changes that were just made. Ensure auto-discovery jobs are rescheduled and re-pointed to include newly created cloud subnets and cloud credentials, as well.

These changes are then verified against the accurate newly discovered data in Device42’s SST on a move group to move group basis, and the aforementioned cycle again repeats until all move groups have been migrated.

Final Checkout and Decommissioning

After the migration team has iterated through all of the move groups, final checkout is in order. That checkout verifies full application functionality in the new environment, and finally production traffic cutover.

The very last step is the decommissioning of the original datacenter installation’s servers and any ancillary equipment. Dismantling is rather straightforward if the entire installation has been retired; a bit less so if it’s only been a partial cloud migration, in which case care must be taken not to disrupt any servers that are still and will remain in production. Ensure that Device42’s scheduled auto-discovery jobs are disabled for IP ranges that are no longer in service. If the subnet(s) in question will remain active, Device42 will see that the old devices no longer exist automatically [ensure you’ve set the discovery action for “VM not found” as appropriate; you may choose to simply have auto discovery change its service level, or delete it completely. The correct option depends on your specific procedures, policies, and data-retention requirements].

Follow through with your equipment disposal plans and procedures, putting aside any server or other equipment that was particularly troublesome over its lifetime for a bit of reckoning, introducing them the “office space” treatment, if desired. [note: kidding here (mostly), and I take no responsibility for injuries to yourself or your equipment if you actually choose to ‘dispense’ of it in this way]

Congratulations! The hard work is done. Time to relax, and consider how painful that could have been without the help of Device42.

Come back again for more fun and informative articles from Device42, and if you have any questions or comments, please don’t hesitate to leave them below. We love interacting with our readers and users alike.

If you are already using Device42, make sure you are using the latest version – We’re always releasing new features, and upgrades are quite painless. If you aren’t already using Device42, and need a high-quality automated documentation solution / CMDB to track your infrastructure deployment, or to plan a migration, don’t hesitate to try it out!

Download a 30-day full featured Device42 trial now!

Share this post

About the author