Migration
Part of Cloud infrastructure planning for businesses
Mapping business workloads before a cloud migration
Map business actions, components, data and owners before migration so placement decisions rest on a usable workload inventory.
Map a workload as a business action and the components needed to complete it. A server list is a useful starting input, but a migration decision also needs application owners, data stores, integrations, identities and demand patterns. The map should show likely migration groups, components that may stay in place and questions still to investigate.
Define the workload boundary
Start with a named action: for example, a staff member approves an invoice. Trace the application, database, identity service, document store and external connections involved. Record the technical and business owners. If a shared service supports several actions, show those relationships instead of assigning it to one server.
Keep the first pass small enough to review with people who use and operate the system. Describe the action's operating hours, importance and acceptable reduced service. This context helps identify a quiet but critical batch process alongside a busy web front end.
Collect evidence from more than one place
Use architecture notes, asset records, configuration, logs, monitoring and interviews as possible inputs. Mark where each entry came from and when it was checked. A network connection can suggest a dependency without revealing the traffic's business purpose. An owner's recollection can explain a process but should be checked against current configuration where possible.
Capture each component's environment, software or service, data held, demand and known constraints. Include scheduled jobs, service accounts, certificates, reporting feeds and third-party connections when they affect the action. Record unknowns openly; an empty dependency field can be mistaken for a confirmed absence.
Key Inputs for a Complete Workload Map
- Evidence sources
- Architecture notes, asset records, configuration, logs, monitoring, interviews
- Component details captured
- Environment, software/service, data held, demand, constraints, scheduled jobs, service accounts, certificates
- Ownership recorded
- Technical and business owners for each component
- Unknowns documented
- Open fields for unresolved dependencies or missing information
Draw flows that affect placement
A useful map shows each material flow's source, destination, purpose, data and owner, plus whether it is needed during normal operation or recovery. Focus on relationships that may affect migration, such as an application using a database left on premises or a nightly file exchange with a partner.
Map entry / Question to answer
- User action
- What completes successfully, and who can verify it?
- Application and data
- Which components hold state or may need to change together?
- Integration
- What connects to a system outside the proposed move?
- Identity and access
- Which accounts or services authorise the action?
- Operations
- Who monitors, patches and restores each component?
- Uncertainty
- What observation or owner can resolve it?
This is a workload map, not a packet-level network design. Investigate a material connection whose purpose is unknown before choosing the target arrangement.
Workload Components and Their Migration Considerations
- User action
- What completes successfully? Who can verify it?
- Application and data
- Which components hold state or must change together?
- Integration
- What connects to systems outside the proposed move?
- Identity and access
- Which accounts or services authorise the action?
- Operations
- Who monitors, patches and restores each component?
- Uncertainty
- What observation or owner can resolve it?
Turn the map into a decision input
Review the map with business, application, infrastructure and security owners. Ask which components are tightly coupled, which could be replaced or retired, and which constraints make a proposed target unsuitable. Record an initial treatment for each workload: retain, retire, replace, rehost or change the application. Treat it as a hypothesis until technical assessment supports it.
Keep a concise record for each workload: a diagram, component register, data classification, demand evidence, named owners and unresolved questions. A later migration plan can use it to decide order and cutover steps. Mapping alone does not show that a workload is ready to move or that a proposed design will meet its recovery targets.
Key Steps in Mapping Business Workloads Before Cloud Migration
- Define the workload boundaryIdentify a business action (e.g. invoice approval) and trace all components involved, including owners.
- Collect evidence from multiple sourcesGather inputs from architecture notes, logs, monitoring tools, interviews and configuration records.
- Draw material flows affecting placementMap data, integrations, identity flows and dependencies that impact migration decisions.
- Review with stakeholdersEngage business, application, infrastructure and security owners to assess coupling, constraints and treatment options.
- Record decisions and unknownsDocument initial treatment (retain, retire, rehost, replace), data classification, demand patterns and unresolved questions.
