Quick answer: Before choosing how to migrate, identify each workload’s business purpose, owners, components, dependencies, data requirements, operating constraints, and performance baseline. Use that evidence to decide what should move, what should stay, and which components belong together. AWS and Microsoft both place workload discovery and assessment before detailed migration planning. (docs.aws.amazon.com)
This guide is for teams planning their first migration from an existing data center or another cloud. Start with access to configuration records, monitoring, application documentation, and the people responsible for operating the workload. Use a shared spreadsheet or catalog if that is sufficient; the important deliverable is an evidence-backed inventory with accountable owners.
1. Define workloads, not just servers
A workload is the collection of components supporting a business process. Its boundary can include application code, virtual machines, databases, storage, identities, integrations, and supporting services. A server list is therefore useful input, but not a complete migration inventory. Microsoft’s discovery guidance explicitly calls for defining workload boundaries and including components across environments. (learn.microsoft.com)
Create a workload record first, then link its component records underneath it. Ask:
- What business process does this workload support?
- Who can approve changes and confirm that it works?
- Which components are dedicated, and which are shared?
- Who uses its outputs, including reports and exported files?
- What is explicitly outside this migration?
For example, an application may depend on a shared identity service without requiring that identity service to move. Record the dependency, its owner, and the required connectivity rather than silently including the entire shared platform.
Also record the reason for considering migration: a facility exit, support deadline, operational requirement, or business capability. AWS recommends aligning portfolio discovery with business drivers, application criticality, and business cycles. These inputs help distinguish a necessary move from an optional modernization project. (docs.aws.amazon.com)
Practical check: Ask the application owner and operations team to review the same boundary diagram. Resolve disagreements before scheduling a wave.
2. Capture the fields that change migration decisions
Microsoft’s migration planning template separates business requirements from technical details. It includes owners, criticality, data sensitivity, maintenance windows, geographic restrictions, architecture, software versions, databases, performance requirements, and licensing. (learn.microsoft.com)
Use those categories to build a compact inventory:
| Category | Fields to record | Decision it supports |
|---|---|---|
| Identity and ownership | Workload ID, purpose, environment, business owner, technical owner, support team | Who approves and validates the move |
| Business constraints | Criticality, change windows, freeze periods, deadlines, success criteria | When migration is acceptable |
| Components | Hosts, operating systems, runtimes, databases, storage, network services | What must be assessed |
| Data and protection | Classification, location restrictions, retention requirements, backup and recovery requirements | What the target must protect |
| Dependencies | Source, destination, protocol, authentication, frequency, shared-service owner | What moves together or needs connectivity |
| Performance and capacity | Provisioned resources, observed utilization, storage demand, application response times | What to size and test |
| Compatibility and cost | Versions, licenses, unsupported features, current cost baseline, target assumptions | Which strategies remain feasible |
| Evidence and status | Source, collection date, reviewer, confidence, unresolved questions | Whether the record is decision-ready |
The evidence fields are a recommended addition, not a vendor-mandated schema. They make it possible to distinguish a current observation from an old diagram or an owner’s recollection.
Keep allocated capacity separate from measured demand. Microsoft’s assessment guidance calls for evaluating workload performance, architecture, software, and databases before migration decisions. A hardware specification alone does not establish the workload’s target requirements. (learn.microsoft.com)
Mark missing information as unknown, with a person responsible for resolving it. Do not turn an empty cell into an assumption. For sensitive records, store references to approved credential or secret-management systems rather than passwords in the inventory.
3. Discover dependencies with tools and human review
Use automated discovery where supported, then reconcile it with configuration records and owner interviews. Microsoft notes that assessment tools can miss undocumented dependencies and permits manual discovery where automation is restricted or unavailable. (learn.microsoft.com)
A practical discovery sequence is:
- Collect existing records. Compare configuration databases, virtualization inventories, deployment definitions, backup lists, and monitoring.
- Observe communication. Use approved dependency discovery to identify connections between components.
- Inspect configuration. Review connection strings, service endpoints, file paths, identity references, and scheduler definitions.
- Interview operators. Ask about reporting cycles, manual transfers, maintenance procedures, and external consumers.
- Resolve unexplained findings. Assign an owner to every connection or component whose purpose remains unclear.
For a concrete tool example, Azure Migrate’s agentless dependency analysis captures TCP connection information and can display a dependency map or export CSV data. Its process information is not guaranteed: Microsoft documents cases where a connection is recorded with an “Unknown process.” Treat the map as evidence to investigate, not proof of a complete application boundary. (learn.microsoft.com)
Choose an observation period that covers the workload’s actual operating cycle. As a practical inference, a short capture cannot establish that an infrequently scheduled integration does not exist; check scheduler definitions and historical records as well. Azure Migrate’s documented TCP-based collection also should not be treated as a complete description of every dependency type. (learn.microsoft.com)
For each dependency, record whether it must remain close to the application or can operate across a hybrid connection. Microsoft distinguishes direct, low-latency dependencies from occasional interactions that may tolerate separate migration waves. (learn.microsoft.com)
4. Choose a strategy from constraints, not labels
AWS describes seven migration strategies. Use them as decision categories, not as a requirement to choose the same approach for every component. (docs.aws.amazon.com)
| Strategy | Meaning | Question to settle first |
|---|---|---|
| Retire | Decommission or archive | Is it genuinely unnecessary, and are retention obligations resolved? |
| Retain | Keep in the current environment | What blocks migration, and when will that decision be reviewed? |
| Rehost | Move with minimal application change | Is the destination compatible with the existing workload? |
| Relocate | Move to a cloud version of the existing platform | Is the required platform available and suitable? |
| Repurchase | Replace the application with another product or service | Can data, integrations, and business workflows transition? |
| Replatform | Change selected platform components | Which features and operational behaviors require testing? |
| Refactor or re-architect | Redesign the application architecture | Does the business benefit justify the engineering scope? |
These descriptions follow AWS’s framework; the questions are practical review prompts. None establishes savings, compatibility, or an acceptable outage without workload-specific assessment. (docs.aws.amazon.com)
Record the proposed strategy, rationale, rejected alternatives, and blockers. For example, “replatform the database, subject to feature compatibility testing” is more useful than simply “modernize.”
Keep target costs provisional until the target architecture and operating requirements are understood. Microsoft’s planning template includes platform service and operational cost estimates; avoid treating an early estimate as a verified outcome. (learn.microsoft.com)
5. Select a representative pilot and build its inventory
Microsoft recommends beginning with less complex, lower-risk workloads and migrating nonproduction environments before production. It also recommends representative workloads that expose patterns relevant to later migrations. A pilot should teach the team something useful without making a critical business system the first experiment. (learn.microsoft.com)
Prefer a candidate with an engaged owner, testable business behavior, understood dependencies, and a feasible recovery plan. An abandoned application with nobody available to validate it is not automatically an easy pilot.
The following is an illustrative planning example, not a real customer inventory or measured result:
| Component | Purpose and dependencies to verify | Accountable role | Provisional approach | Open question |
|---|---|---|---|---|
| Internal application | Reads and updates its database; uses shared identity | Application owner | Rehost initially | Are configuration and session behavior portable? |
| Database | Stores application records; receives writes from application and jobs | Database owner | Assess replatforming | Are required features and recovery procedures supported? |
| Scheduled jobs | Import records and generate reports; access database and file destination | Job owner | Move within the same dependency group | Are all schedules, credentials, retries, and consumers documented? |
Start by moving a representative nonproduction copy. Test the application, database interactions, and scheduled jobs together.
For this example, use a conservative production planning assumption: keep all three in one migration group until evidence supports separation. Shared identity and the report destination remain external dependencies requiring connectivity and access validation. That approach follows Microsoft’s guidance to group uncertain critical dependencies and validate group completeness. (learn.microsoft.com)
Do not finalize the database approach until its assessment is complete. The pilot is where a provisional strategy should be confirmed—or changed.
6. Turn the inventory into an owned migration wave
A migration wave is a controlled group of workloads or components planned to move together. Keep the immediate wave detailed and later waves flexible so discoveries can change the plan. (learn.microsoft.com)
For the illustrative application, create this wave outline:
| Stage | Required evidence or action | Accountable role |
|---|---|---|
| Readiness | Approve boundary, dependency list, target design, access, and unresolved risks | Migration lead |
| Rehearsal | Run representative application transactions and jobs in the test target | Application and job owners |
| Data preparation | Confirm transfer method, synchronization process, backups, and reconciliation tests | Database owner |
| Cutover | Follow approved write-control, synchronization, routing, and job-enablement sequence | Migration lead coordinating component owners |
| Acceptance | Confirm business functions and operational readiness | Business owner and operations lead |
| Stabilization | Monitor, resolve defects, and update support documentation | Operations lead |
Name actual people and alternates before execution; role labels are only placeholders. Microsoft calls for a readiness review covering team responsibilities, access, verification procedures, and rollback criteria. (learn.microsoft.com)
Write down failure triggers before the cutover. Examples include failed data reconciliation, broken authentication, an unusable critical workflow, or performance outside the workload’s approved acceptance limits.
Also define the last point at which the planned rollback remains valid. If the cloud database has accepted new writes, routing users back does not itself reconcile those writes. The runbook should state how the team will handle that condition rather than assuming DNS reversal is sufficient. Microsoft’s guidance calls for explicit rollback planning and controlled final synchronization. (learn.microsoft.com)
7. Use acceptance gates and catch common mistakes
Before authorizing cutover, require evidence for these gates:
- Data: agreed integrity checks pass, and final synchronization is complete.
- Function: representative users can authenticate and complete critical workflows.
- Integration: reports, transfers, and scheduled jobs work as intended.
- Performance: results meet the workload’s approved requirements.
- Operations: monitoring, support access, documentation, and backup validation are ready.
Microsoft’s execution guidance includes data-integrity checks, end-to-end testing, reporting, integrations, backups, and owner confirmation before declaring success. Retain the source environment as a controlled fallback during stabilization. (learn.microsoft.com)
Watch especially for these planning mistakes:
- A server export becomes the whole inventory. Return to workload boundaries and shared dependencies.
- A quiet component is assumed unnecessary. Confirm its business purpose and operating cycle.
- A discovery map is treated as complete. Review unknown processes and unobserved integrations.
- A strategy becomes permanent too early. Update it when assessment or rehearsal finds a blocker.
These checks follow the frameworks’ emphasis on complete workload discovery, tool limitations, and iterative planning. (learn.microsoft.com)
Your first deliverable is not a migration date. It is an owner-reviewed inventory that makes the next decision defensible: what moves, why, with which dependencies, and under what acceptance conditions.
Read next: Regions and Availability Zones: What They Mean for Application Design