Module: Migrate Servers and Workloads

Lesson: Discovery and Assessment

Introduction: The Foundation of Successful Migration

Migrating servers and workloads from on-premises data centers to cloud environments or between different infrastructure platforms is one of the most complex tasks an IT organization can undertake. Many projects fail not because of the technical execution of the move itself, but because of a lack of understanding regarding what actually exists within the current environment. Discovery and assessment represent the "look before you leap" phase of any migration project. Without an accurate inventory of your assets, their dependencies, and their performance requirements, you are essentially flying blind.

This phase is critical because it dictates the entire strategy for the migration. If you do not know how much storage a database consumes, or how many applications rely on a specific legacy server, you will inevitably encounter downtime, performance bottlenecks, or budget overruns. Discovery is the process of gathering data about your infrastructure, while assessment is the process of analyzing that data to determine the feasibility, cost, and method of moving those workloads. By investing time here, you mitigate the risk of "migration shock," where hidden dependencies cause massive outages during the cutover window.

The Scope of Discovery: What Are We Looking For?

Discovery is not just about counting the number of physical servers in a rack. It involves gathering a multi-dimensional view of your environment that encompasses hardware, software, network traffic, and business logic. To perform a thorough assessment, you must categorize your findings into distinct buckets that allow you to make informed decisions later.

1. Infrastructure Inventory

This is the baseline of your data. You need to identify every physical host, virtual machine (VM), storage array, and network device. For each item, you should capture core specifications such as CPU cores, RAM capacity, disk space, and operating system versions. Having this data allows you to perform "right-sizing," which is the practice of matching the provisioned cloud capacity to the actual utilization of the workload, rather than just matching what was provisioned on-premises.

2. Dependency Mapping

Dependency mapping is perhaps the most difficult but essential part of the discovery phase. You need to understand which applications talk to which databases, which web servers rely on which middleware, and which legacy systems are hard-coded to look for specific IP addresses. If you move a web server to the cloud but leave its backend database on-premises without considering the latency implications, the application will become unusable.

3. Performance Utilization

Raw capacity is not the same as actual usage. You might have a server provisioned with 64GB of RAM, but if it never uses more than 8GB, you are wasting money by migrating that same capacity to the cloud. By collecting performance metrics over a period—ideally at least 30 days to capture monthly cycles—you can determine the true resource footprint of your workloads.

Callout: Discovery vs. Assessment While these terms are often used interchangeably, they are distinct activities. Discovery is the act of collecting raw data (the "what"). Assessment is the act of interpreting that data to determine the "how," "when," and "how much" of the migration. You cannot have a valid assessment without a complete discovery, but discovery without assessment is just a list of numbers that provides no business value.

Practical Approaches to Data Collection

How do you actually go about gathering this information? Depending on the size of your environment, you might start with manual audits, but for any enterprise-grade migration, you will need automated tools.

Manual Audits (Small Environments)

For environments with fewer than 20 servers, a spreadsheet-based approach might suffice. You can manually inspect each server, document the running processes, and trace network connections using standard command-line tools. However, this is prone to human error and is rarely exhaustive.

Automated Discovery Tools

For larger environments, you should use agent-based or agentless discovery tools. Agent-based tools are installed directly on the servers, providing deep visibility into local processes, configuration files, and registry settings. Agentless tools use protocols like WMI (Windows Management Instrumentation), SSH, or API calls to query your infrastructure from a central point. Agentless discovery is generally easier to deploy but may provide less granular data regarding internal process dependencies.

Step-by-Step Discovery Process

To execute a successful discovery phase, follow these structured steps:

Define the Scope: Decide if you are migrating the entire data center or just specific application tiers. Setting boundaries early prevents "scope creep," where you end up trying to analyze hardware that you don't actually intend to move.
Select the Tooling: Choose a discovery tool that aligns with your target platform. Most cloud providers offer their own migration assessment tools, which are optimized to highlight compatibility issues with their specific cloud services.
Run the Collection: Initiate the discovery process. Ensure that you have adequate network permissions and that firewalls are configured to allow the discovery tool to communicate with your target endpoints.
Validate the Data: Once the collection is complete, review the output. Does the total number of servers match your internal asset management database? Are there "ghost" servers that haven't been touched in years?
Identify Dependencies: Use the network flow data generated by your tools to create a map of inter-server communication. This will reveal the "hidden" links that could break if you migrate servers in the wrong order.

Analyzing Dependencies with Code

Understanding network traffic is key to mapping dependencies. You can use simple scripts to identify which processes are listening on specific ports or which remote IP addresses a server is communicating with. Below is a conceptual example of how you might script a basic dependency check using Python on a Linux system.

import psutil
import socket

def get_network_connections():
    # This function retrieves active network connections
    # It filters for established connections to identify dependencies
    connections = psutil.net_connections(kind='inet')
    dependency_list = []
    
    for conn in connections:
        if conn.status == 'ESTABLISHED':
            remote_ip = conn.raddr.ip if conn.raddr else "N/A"
            remote_port = conn.raddr.port if conn.raddr else "N/A"
            dependency_list.append({
                "local_port": conn.laddr.port,
                "remote_ip": remote_ip,
                "remote_port": remote_port,
                "pid": conn.pid
            })
    return dependency_list

# Execute and print findings
dependencies = get_network_connections()
for dep in dependencies:
    print(f"Process ID {dep['pid']} is talking to {dep['remote_ip']} on port {dep['remote_port']}")

Explanation: This script utilizes the psutil library to inspect the network state of a server. By identifying established connections, you can see exactly what external services a server relies on. In a real-world migration, you would run this across your entire fleet to build a comprehensive map of how your applications communicate.

Assessment: Turning Data into Strategy

Once the discovery phase is complete, you move into assessment. This is where you categorize your workloads into one of the "6 Rs" of migration: Rehost, Replatform, Refactor, Repurchase, Retain, or Retire.

Strategy	Description	When to use
Rehost	"Lift and shift" the server as-is.	When speed is the priority.
Replatform	Move to cloud but change the OS or database version.	When you need better performance or managed services.
Refactor	Rewrite the code to be cloud-native.	When the app needs to scale or be highly resilient.
Repurchase	Replace with a SaaS equivalent.	When the software is a commodity (e.g., email).
Retain	Keep it on-premises for now.	When dependencies are too complex or it is legacy.
Retire	Turn it off.	When the application is no longer in use.

Right-Sizing and Cost Estimation

The assessment phase must include a cost projection. A common mistake is to assume a 1:1 mapping between on-premises hardware and cloud instances. If your on-premises server has 32GB of RAM but only uses 4GB, you should map that to a smaller, cheaper cloud instance. If you don't perform this right-sizing, you will significantly overpay for your cloud infrastructure.

Note: Always account for "burst" capacity during your assessment. If your application has a predictable peak (like an e-commerce site during the holidays), ensure your assessment accounts for the maximum resource usage, not just the average.

Common Pitfalls and How to Avoid Them

Discovery and assessment are prone to several traps that can derail a project before it even begins. Being aware of these will save you significant time and effort.

1. Ignoring "Dark" Assets

Many organizations have servers that were set up years ago and have been forgotten. If you don't include these in your discovery, you might miss a critical internal dependency that causes a production outage when you migrate the application that does rely on that "dark" server.

Fix: Perform a comprehensive network audit. If a server is communicating with your production systems, it is not "dark"—it is a dependency.

2. Relying on Static Documentation

Documentation is almost always out of date. Relying on a spreadsheet from three years ago to understand your current environment is a recipe for disaster.

Fix: Trust only the data that you collect through automated discovery tools during the assessment phase. If the data contradicts your documentation, assume the data is correct and the documentation is wrong.

3. Underestimating Latency

When you move a web server to the cloud but keep its database on-premises, the round-trip time (RTT) for data packets can become a bottleneck.

Fix: Use network performance tools to measure current latency between your application tiers. If the latency is high, you must migrate those tiers together or implement high-speed dedicated connections like ExpressRoute or Direct Connect.

4. Failing to Account for Security and Compliance

Sometimes, a server cannot be moved to the cloud because it contains sensitive data that must remain in a specific geographic region or on specific hardware for regulatory reasons.

Fix: Include a compliance review in your assessment. Identify any data sovereignty requirements early, as these may force a "Retain" decision for certain workloads.

Building the Migration Roadmap

The final output of your discovery and assessment should be a prioritized migration roadmap. You should not attempt to move everything at once. Use the data you gathered to group your servers into "migration waves."

Wave 1: Low-hanging fruit. These are simple, non-critical applications that have few dependencies. They allow your team to gain experience with the migration tools and processes.
Wave 2: Departmental applications. These are more complex but still isolated from the core business functions.
Wave 3: Core systems. These are your most mission-critical workloads. Only move these once you have successfully completed the previous waves and have refined your processes.

Best Practices for Long-Term Success

To ensure your discovery and assessment phase provides lasting value, adopt these industry-standard practices:

Iterative Discovery: Discovery is not a one-time event. Infrastructure changes constantly as new services are deployed and others are decommissioned. Keep your discovery tools running throughout the migration project to capture changes.
Stakeholder Engagement: Include application owners in the assessment process. They know the business context of their apps better than any automated tool. Ask them about their performance expectations and their tolerance for downtime.
Validate Assumptions: If your discovery tool shows that an application is not communicating with any other system, verify this with the application owner before deciding to retire it. You don't want to accidentally shut down a service that only runs once a year for annual reporting.
Centralize Data: Create a "Migration Command Center" dashboard. This should be a single source of truth that contains the inventory, dependency maps, and the status of every application being assessed.

Callout: The "Human" Element in Discovery While automated tools are powerful, they cannot tell you why an application exists or how important it is to the business. Always supplement your technical discovery with interviews. A server might show low CPU usage, but if it is the primary gateway for a critical customer-facing service, its importance is far higher than the raw data suggests.

Deep Dive: Handling Complex Dependencies

One of the most challenging scenarios is the "spaghetti" environment, where almost every application is dependent on a shared database or a legacy middleware platform. When you encounter this, you cannot perform a simple lift-and-shift. You must break the dependencies before you can move the workloads.

Decoupling: If you have an application that is tightly coupled to a local database, consider migrating the database first, then updating the application to point to the new cloud-based connection string. This is a "replatforming" step.
API Wrappers: If your legacy application relies on direct file access to a server, you might need to create an API wrapper that abstracts the file access, allowing the application to function over a network connection once it is in the cloud.
Proxying: If you have a cluster of servers that must move together, use a load balancer or a proxy to manage the traffic during the transition. This allows you to cut over one server at a time while maintaining the appearance of a single, continuous service to the end user.

Final Considerations: The "Retire" Strategy

Do not overlook the "Retire" strategy. Discovery often reveals that 20% to 30% of a typical enterprise data center consists of "zombie" servers—systems that are powered on, consuming power, and potentially posing a security risk, but providing no value. By identifying these during the discovery phase, you can reduce the scope of your migration, saving money and effort.

When you identify a server as a candidate for retirement, follow this procedure:

Isolate: Move the server to a restricted network segment where it cannot communicate with the rest of the environment.
Monitor: Watch for any "crying" logs—errors from other systems complaining that they cannot connect to the isolated server.
Backup: Perform a full backup of the server's data.
Decommission: If no errors are reported after a full business cycle (e.g., a month), power down the server and eventually decommission it.

Common Questions (FAQ)

Q: How long should the discovery phase take? A: It depends on the size of the environment. For a small data center, it might take two weeks. For a global enterprise, it could take several months. The key is to gather enough data to make informed decisions without falling into "analysis paralysis."

Q: What if our discovery tools don't support our legacy hardware? A: This is common with older mainframe or specialized industrial equipment. In these cases, you must rely on manual documentation, network flow logs from your core switches, and interviews with the original system architects.

Q: Does discovery require downtime? A: Generally, no. Most modern discovery tools are designed to be non-disruptive. However, you should always test them in a development environment first to ensure they do not spike CPU usage on your production servers.

Q: Should I use cloud-native discovery tools or third-party tools? A: Cloud-native tools (like AWS Migration Hub or Azure Migrate) are excellent if you are moving specifically to that cloud. If you are considering a multi-cloud or hybrid strategy, a third-party discovery tool may provide a more platform-agnostic view of your environment.

Summary of Key Takeaways

Discovery is Mandatory: Never attempt a migration based on guesswork or outdated documentation. A complete, data-driven inventory is the only way to avoid catastrophic failures.
Focus on Dependencies: Understanding how systems communicate is more important than knowing the specs of individual servers. A migration that ignores dependencies will almost certainly break applications.
Right-Size for Cost: Use performance data to match cloud resources to actual usage. Do not blindly replicate on-premises hardware capacity in the cloud, or your costs will skyrocket.
Prioritize in Waves: Move workloads in logical groups. Start with low-risk, low-dependency applications to build team confidence and refine your processes before tackling core systems.
Identify the "Zombie" Servers: Use the discovery process as an opportunity to clean up your environment. Retiring unused workloads is the fastest way to reduce the complexity and cost of your migration.
Verify with Stakeholders: Technical data is only half the picture. Always validate your findings with the people who manage and rely on the applications to ensure you understand their business importance.
Iterate and Adapt: Discovery is not a one-time project. Keep your tools running and your assessments updated as your environment evolves during the migration process.

By diligently following these steps and maintaining a rigorous approach to discovery and assessment, you transition from a reactive state—fixing problems as they arise—to a proactive state, where you are orchestrating a controlled, predictable, and successful migration. This phase is the bedrock upon which your entire cloud journey is built; ensure it is solid before moving forward.

Discovery and Assessment