ISS Labs · Updated October 15, 2026 · Practical planning guide
A cloud migration changes how a service is operated, supported, and secured. Moving an application successfully means more than transferring its data. The organization needs a clear view of responsibilities, dependencies, recovery needs, costs, and the evidence required to make an informed launch decision.
Define the workload and purpose
Describe the business problem the move should solve and the services that must keep working. Identify whether you are replacing an application with SaaS, deploying to a managed platform, or operating virtual machines. The choice changes what your team must configure and maintain.
- Which users and business processes depend on the workload?
- What availability, performance, and recovery expectations have owners agreed?
- Which capabilities must be retained, changed, or retired?
- Who owns the application after migration, and who funds ongoing operation?
Include identity systems, domain names, certificates, scheduled jobs, integrations, and service accounts in the inventory. A low-visibility dependency can interrupt a critical process even when the main application is healthy.
Map information and dependencies
Document where information enters the service, where it is stored, who can access it, and where it leaves. Include backups, logs, analytics, support exports, and test environments. Identify sensitive information with the relevant business, privacy, and compliance owners.
Ask whether proposed locations, subcontractors, retention settings, and support arrangements meet applicable organizational and contractual requirements. Provider marketing material is a starting point; evaluate the actual service, selected features, region, and agreement.
- Can data be exported in a usable format if the service changes?
- How will retention and deletion apply to copies and backups?
- Which integrations depend on fixed addresses, local authentication, or legacy protocols?
- Can test data be minimized or de-identified before migration rehearsal?
Assign security responsibilities
Microsoft's shared responsibility guidance explains that responsibilities vary across IaaS, PaaS, and SaaS. Customers retain responsibility for their data and identities. Build a workload-specific responsibility matrix using the chosen provider's documentation and agreements.
| Area | Decision to document | Evidence to request |
|---|---|---|
| Identity and access | Who approves access, manages privileged roles, and removes accounts? | Role design, authentication settings, access-review records |
| Configuration and updates | Who maintains each layer and handles exceptions? | Service responsibility terms, baseline, change process |
| Monitoring and response | Who receives alerts and coordinates incidents? | Log coverage, routing test, response contacts |
| Backup and recovery | Who configures retention and proves restoration? | Recovery design, restore-test results, recovery ownership |
| Assurance | Who reviews provider evidence and customer-side controls? | Relevant reports, scope details, identified evidence gaps |
A provider assurance report does not establish that your own access rules, application configuration, or operating processes are effective. Identify which controls are inherited, shared, or operated by your organization, and record the basis for that conclusion.
Plan for daily operations
Design access, logging, recovery, and change management before launch. Confirm that the team can see important events, recognize failures, and act on alerts. Decide who covers incidents outside normal hours and how the provider is contacted.
- Access: Use defined administrative roles, strong authentication, and a controlled emergency-access process. Include service identities and credential rotation.
- Logging: Identify needed events, retention, access permissions, and alert owners. Check that logs can support investigation without exposing unnecessary sensitive data.
- Recovery: Agree recovery time and acceptable data loss with business owners. Demonstrate restoration; do not assume service availability guarantees provide a backup strategy.
- Cost: Account for storage growth, backups, logging, support, licenses, and data transfer. Assign budget alerts and someone to review them.
- Change: Decide how configuration and application changes are reviewed, tested, deployed, and reversed.
Set launch and rollback criteria
Define what must be demonstrated before launch: application behavior, user access, data reconciliation, monitoring, recovery, support readiness, and resolution or authorized acceptance of material risks. Identify who makes the final decision.
Illustrative cutover checkpoint: Before moving a scheduling application, test staff sign-in, integration messages, alert delivery, and restoration of a representative backup. Reconcile migrated records. Keep the original service available under a documented rollback plan until the agreed acceptance checks pass.
Fictional example. Actual checks and retention periods depend on the workload.
Document rollback triggers, the person authorized to invoke them, how users will be informed, and how transactions created during cutover will be reconciled. Schedule a post-launch review and retire old access, integrations, and resources only after the appropriate checks.
Questions for the decision meeting
- Do we understand the complete workload and its dependencies?
- Have data handling and applicable requirements been reviewed?
- Does every security and operational responsibility have an owner?
- Have monitoring, recovery, and support arrangements been demonstrated?
- Are launch, rollback, and residual-risk decisions documented?
- Can the team operate and fund the service after the migration project ends?
Next step: Turn unanswered questions into an owner-and-action list before committing to a cutover date. Use the assessment preparation guide to organize a focused review of the proposed environment.
Use this guide as a planning aid. Adapt it to your systems, applicable requirements, and agreed review scope; it does not establish compliance or replace a system-specific assessment.
