Stop Counting a Cloud Migration Done When the Servers Copy — Prove the Business Capability Actually Runs

A complete migration plan should answer:

1. Why is the workload moving?
2. What business outcome must be achieved?
3. What components are in scope?
4. What is explicitly out of scope?
5. What migration strategy is approved?
6. What dependencies exist?
7. Which components must move together?
8. Which dependencies may remain hybrid?
9. What downtime is acceptable?
10. What data loss is acceptable?
11. How will data be moved?
12. How will data be reconciled?
13. How will users connect after migration?
14. How will integrations be redirected?
15. What security controls must exist before cutover?
16. How will the workload be tested?
17. What conditions require rollback?
18. How long is rollback feasible?
19. Who has go/no-go authority?
20. Who supports the workload after migration?
21. What costs will continue during parallel operation?
22. When can the source environment be retired?
23. How will success be measured?

Recommended principles include:

• Migrate workloads, not isolated servers.
• Confirm business ownership.
• Validate dependencies before cutover.
• Establish the target platform before migration.
• Automate repeatable infrastructure.
• Rehearse high-risk steps.
• Measure data-transfer duration.
• Define rollback before implementation.
• Separate reversible and irreversible actions.
• Preserve evidence.
• Test business outcomes, not only infrastructure.
• Maintain security throughout the migration.
• Transfer operational ownership deliberately.
• Communicate user impact clearly.
• Decommission intentionally.
• Record lessons for subsequent migrations.

Define the workload as a complete operating capability. Include application components, databases, storage, APIs, messaging, scheduled jobs, identity, certificates, DNS, network, monitoring, backup, recovery, security controls, administrative tools, integrations, users, and operational procedures.

Explicitly document: in scope, out of scope, retained on-premises, replaced, retired, and deferred.

The migration strategy may include: rehost, relocate, replatform, refactor, rearchitect, repurchase, rebuild, or hybrid transition.

The migration plan should reflect the approved strategy from the readiness and disposition process. Do not introduce major modernization during migration unless it is necessary or explicitly approved. Combining too many changes increases failure risk.

Separate migration changes into: foundation, infrastructure, platform, application, database, data, identity, network, DNS, security, monitoring, operational, and user changes. This helps identify which changes can be tested independently.

Assess readiness across: business, application, infrastructure, data, identity, network, security, compliance, operations, support, financial, organizational, vendor, testing, and change management.

Rate each area as: Ready, Ready with prerequisites, Not ready, Not applicable, or Unable to assess.

Examples include: business owner approval, technical owner assignment, target architecture approval, landing-zone readiness, identity integration, network connectivity, DNS design, security approval, licensing confirmation, data-classification completion, backup validation, recovery plan, monitoring integration, test environment, migration tooling, change window, support readiness, rollback capability, and cost approval.

Mandatory prerequisites should not be mixed with optional improvements.

Identify dependencies through: architecture diagrams, application documentation, network-flow data, firewall logs, DNS logs, configuration files, source-code review, database connections, scheduled tasks, service inventory, process monitoring, application performance monitoring, interviews, vendor documentation, and support tickets.

No single discovery source is complete.

Capture: application-to-application, database, file share, API, message queue, identity provider, directory, DNS, certificate authority, email, batch transfer, scheduled task, license server, hardware device, mainframe, SaaS, vendor service, monitoring, backup, security tooling, and administrative access.

Workloads or components may need to move together when they have: synchronous dependencies, shared databases, shared storage, high-frequency traffic, strict latency, shared transactions, coupled releases, common identity dependencies, common downtime windows, or shared vendor support. Migration groups should reflect technical and business behavior.

Some dependencies may remain outside the cloud temporarily. For each hybrid dependency define: connectivity, latency expectation, bandwidth, authentication, encryption, monitoring, failure mode, cost, security controls, maximum hybrid duration, and exit plan.

Temporary hybrid architecture often becomes permanent unless an exit condition is defined.

Validate that the target environment provides: approved resource hierarchy, identity, roles, network, DNS, connectivity, security policies, logging, monitoring, key management, secrets management, backup, recovery, cost allocation, infrastructure deployment, incident response, and support ownership.

Infrastructure should be deployed through approved automation where practical. Provision accounts/subscriptions/projects, resource groups, networks, subnets, routes, security groups, firewalls, load balancers, compute, storage, databases, identity roles, monitoring, backup, budgets, tags, and policies. Validate the environment before migrating data or application traffic.

Data migration is often the critical path. Assess: data sources, data owners, data volume, growth, change rate, transfer bandwidth, downtime, encryption, data classification, residency, retention, quality, referential integrity, replication, validation, reconciliation, cutover, rollback, and archival.

Possible methods include: offline export and import, online replication, log shipping, database-native replication, storage synchronization, change-data capture, bulk-transfer appliance, application-level dual writing, backup and restore, and incremental synchronization.

Select based on: data size, change rate, downtime, platform compatibility, consistency, security, cost, and reversibility.

Estimate transfer duration using: data volume, effective throughput, protocol overhead, encryption overhead, network contention, retry rate, data compression, transfer windows, and provider limits. Perform a representative transfer test. Theoretical bandwidth is not the same as effective migration throughput.

Validate: record counts, file counts, checksums, table counts, transaction totals, referential integrity, sample records, application behavior, timestamps, permissions, metadata, encoding, time zones, data ownership, and retention.

For transactional systems define: source-of-truth point, freeze time, in-flight transaction handling, final synchronization, duplicate detection, missing-record detection, financial reconciliation, business-owner acceptance, and exception handling.

If the application writes to both source and target systems, assess: ordering, failure handling, retry behavior, duplicate transactions, conflict resolution, reconciliation, rollback behavior, and duration. Dual writing can increase rather than reduce migration risk if not carefully designed.

Assess: database engine, version, extensions, stored procedures, jobs, triggers, collation, character sets, time zones, authentication, encryption, high availability, backup, performance, query behavior, connection strings, client compatibility, and licensing.

Assess: file count, file size distribution, permissions, ownership, links, open files, file locking, case sensitivity, path length, metadata, access patterns, change rate, archival, malware scanning, and user mapping.

Define: user authentication, service authentication, workload identity, role mapping, group mapping, claims, single sign-on, multi-factor authentication, conditional access, privileged access, emergency access, guest access, session behavior, and logging.

For each nonhuman identity define: current credential, target identity, permission scope, token method, credential rotation, cutover sequence, fallback, owner, and monitoring. Avoid copying long-lived credentials into the target environment.

Define: target address ranges, connectivity, routing, firewall rules, security groups, load balancers, private endpoints, internet ingress, internet egress, partner connectivity, remote administration, flow logging, performance tests, and failover.

DNS cutover should define: records, owners, time to live, lowering schedule, health checks, load-balancer targets, certificate requirements, caching behavior, split DNS, private DNS, rollback records, validation, and propagation monitoring. DNS changes are often central to cutover and rollback.

Assess: certificate owner, certificate authority, subject names, expiration, private keys, renewal method, load-balancer termination, internal trust, client validation, revocation, and emergency replacement.

Ensure the target environment includes: identity controls, privileged access, network segmentation, encryption, key management, secret management, logging, security monitoring, vulnerability management, configuration standards, backup protection, incident response, and compliance evidence. Security controls should be active before production traffic is redirected.

May include: configuration review, vulnerability scanning, dependency scanning, identity testing, privilege review, network testing, encryption validation, secret scanning, logging validation, alert testing, penetration testing where required, and threat-model review.

Application migration may include: runtime installation, configuration externalization, environment variables, secrets, file-path changes, endpoint changes, connection strings, authentication changes, hostname changes, scaling changes, deployment automation, feature flags, session state, cache, background jobs, and monitoring agents.

Classify configuration as: environment-specific, secret, runtime, deployment, business configuration, feature flag, network configuration, or operational threshold. Configuration should be version-controlled where appropriate. Secrets should not be stored in source control.

The test strategy should include: infrastructure testing, connectivity testing, identity testing, functional testing, integration testing, data testing, performance testing, security testing, recovery testing, monitoring testing, operational testing, user acceptance testing, and rollback testing.

Validate: core business functions, critical user journeys, batch processes, scheduled jobs, notifications, reports, file operations, authentication, authorization, administrative functions, and error handling.

Validate: upstream systems, downstream systems, APIs, queues, file transfers, vendor services, identity provider, email, monitoring, backup, security systems, and billing systems.

Compare target behavior to an approved baseline. Measure: response time, throughput, error rate, concurrency, database latency, storage latency, network latency, batch duration, queue depth, resource utilization, scaling, and failover behavior.

User acceptance should include: named business testers, defined scenarios, expected results, defect process, severity criteria, retest, sign-off, and outstanding limitations.

Validate: monitoring, alerts, dashboards, log access, backup, restore, scaling, restart, deployment, rollback, certificate renewal, access request, privileged elevation, incident escalation, and vendor support.

A rehearsal should simulate the migration as closely as practical. Rehearse: data transfer, final synchronization, infrastructure deployment, application deployment, configuration, DNS, validation, communications, decision points, rollback, timing, and resource coordination. Record actual duration and problems.

The runbook should include: step number, time, action, owner, preconditions, command or procedure reference, expected result, validation, failure action, rollback impact, and completion status. The runbook should be executable by the assigned team without relying on undocumented knowledge.

A complete cutover plan should include: date and time, business window, freeze window, participants, bridge or command channel, runbook, data freeze, final synchronization, application deployment, identity change, network change, DNS change, integration change, validation, business acceptance, go/no-go points, rollback threshold, communications, support coverage, and post-cutover observation.

Define: systems affected, start time, end time, allowed emergency changes, approval authority, enforcement, communication, and release exceptions. A freeze helps prevent source changes during critical synchronization.

Example go criteria: prerequisites complete, critical defects resolved, rehearsal successful, data migration within window, rollback tested, target environment healthy, monitoring active, support staff available, business owner present, change approval complete.

Example no-go criteria: missing critical owner, unresolved security blocker, failed data reconciliation, target instability, connectivity failure, rollback unavailable, unapproved architecture change, insufficient support coverage, critical test failure.

Define who may: approve start, pause migration, continue with known issue, initiate rollback, accept residual risk, declare success, extend the window. Authority should be explicit before cutover.

Rollback should define: trigger, decision owner, maximum decision time, source environment state, data handling, DNS reversal, network reversal, identity reversal, integration reversal, user communication, transaction reconciliation, evidence, and post-rollback review.

Rollback becomes more difficult after: new transactions are created in the target, database schemas change, external systems are redirected, source data becomes stale, users change data in both systems, legacy infrastructure is modified, licenses are transferred, or source systems are shut down. Define the rollback window explicitly.

Identify actions such as: destructive schema changes, source deletion, data transformation, license reassignment, contract termination, external endpoint changes, encryption-key destruction, permanent data archival. Require explicit approval before irreversible actions.

Identify audiences: executives, business owners, users, support desk, application teams, operations, security, vendors, customers, partners. Communications may include: migration announcement, maintenance notice, freeze notice, progress update, delay notice, rollback notice, completion notice, known issues, support instructions.

Document: downtime, read-only periods, login changes, URL changes, performance changes, client updates, data-entry restrictions, support contacts, and expected post-migration behavior.

Include: change record, risk classification, approvals, maintenance window, backout plan, test evidence, stakeholder notice, conflict review, emergency procedure, and closure evidence.

For major migrations establish: migration lead, technical lead, business lead, data lead, network lead, identity lead, security lead, operations lead, communications lead, scribe, and executive decision-maker.

The migration bridge should provide: single coordination channel, participant list, decision log, timeline, issue tracking, escalation, status updates, go/no-go decisions, rollback decision, and completion record.

Define a stabilization period. Monitor: availability, errors, latency, transactions, queues, database health, user logins, integrations, security alerts, cost, backup, support tickets, and customer impact.

Hypercare may include: extended support hours, dedicated team, increased monitoring, frequent status reviews, accelerated defect handling, vendor support availability, daily reconciliation, and executive reporting. Define a clear exit from hypercare.

Handover should include: architecture documentation, support model, ownership, runbooks, monitoring, alert routing, backup, recovery, access, deployment, patch responsibility, incident procedures, escalation, vendor contacts, known issues, cost ownership, and service-level objectives.

Operations should formally accept responsibility after confirming: documentation complete, monitoring active, alerts tested, access available, backup configured, restore validated, runbooks tested, support contacts confirmed, known risks accepted, and training complete.

Track: migration tooling, temporary infrastructure, data transfer, parallel run, consulting, overtime, support, additional licenses, cloud consumption, decommissioning, and delay cost.

Document: planned cost, actual cost, variance, cause, owner, forecast impact, and corrective action.

Examples include: critical business functions operate correctly, data is complete and reconciled, performance meets the approved threshold, security controls are operational, monitoring is active, recovery objectives are met, users can authenticate, integrations succeed, support ownership is active, cost remains within the approved range, no severity-one defects remain, source retirement criteria are defined.

Useful metrics include: workloads assessed, workloads migrated, migration success rate, rollback rate, cutover duration, downtime, data-transfer duration, data-reconciliation defects, post-migration incidents, user-impacting defects, performance variance, cost variance, security findings, recovery-test completion, monitoring coverage, documentation completion, decommissioning completion, parallel-run duration, hypercare duration, support-ticket volume, business-owner acceptance, and time to operational handover.

Decommissioning should include: business approval, dependency verification, source shutdown, monitoring period, data archival, backup disposition, license update, contract update, hardware disposition, network cleanup, DNS cleanup, identity cleanup, firewall cleanup, monitoring cleanup, CMDB update, cost validation, security disposal, and documentation.

A temporary hold may preserve the source environment in a powered-off or restricted state. Define: duration, storage cost, security controls, access, backup, reversion feasibility, destruction date, owner, and approval.

A migration is closed when: success criteria are met, business acceptance is recorded, operations accepts the service, critical defects are resolved, residual risks are assigned, documentation is updated, financial variance is recorded, source disposition is approved, lessons learned are documented, and metrics are updated.

Review: What succeeded? What failed? Which assumptions were wrong? Which dependencies were missed? Which steps took longer? Were communications effective? Did rollback remain feasible? Were security controls ready? Was support prepared? Did costs match estimates? What should change for the next migration?

Document: lesson, evidence, impact, root cause, recommended change, owner, target workflow, and status. Lessons should update migration templates and standards.

A migration factory standardizes: intake, discovery, assessment, architecture, security, costing, infrastructure, data migration, testing, cutover, rollback, handover, decommissioning, and reporting. Standardization should accelerate repeatable work without ignoring workload-specific risks.

Workload: Customer Order Management

Current Environment:

• Two Windows application servers
• SQL Server database
• Shared file storage
• Active Directory authentication
• Nightly batch processing
• Integrations with warehouse, billing, and email systems
• Manual deployment
• Private data-center hosting

Target Environment:

• Cloud virtual machines
• Managed load balancer
• Managed database service
• Cloud file storage
• Federated authentication
• Private hybrid connectivity
• Central logging and monitoring

Constraints:

• Maximum downtime: two hours
• Maximum data loss: zero approved transactions
• Data volume: approximately four terabytes
• Warehouse system remains on-premises
• Migration must occur before hosting-contract expiration
• Regression-test coverage is limited

The workload is suitable for migration but is not yet ready for production cutover. Primary blockers include:

• Limited regression-test coverage
• Unrehearsed database migration
• Incomplete warehouse latency testing
• Unconfirmed software licensing
• Missing rollback reconciliation procedure
• Incomplete support handover

Recommended disposition: Ready with mandatory prerequisites

Recommended cutover: Blue-green infrastructure with controlled final database synchronization and DNS redirection

Go:

• Final synchronization completed successfully.
• Database reconciliation is within approved tolerance.
• Critical application tests pass.
• Warehouse integration latency meets target.
• Identity authentication succeeds.
• Security monitoring is active.
• Rollback remains feasible.
• Business and technical owners approve.

No-Go:

• Unreconciled order transactions
• Target database instability
• Failed identity integration
• Missing critical logs
• Warehouse integration timeout
• Rollback path unavailable
• Required decision-maker absent

Trigger: Any confirmed loss, duplication, or unreconciled state involving approved customer orders.

Decision Owner: Business Owner and Migration Lead jointly.

Decision Deadline: Within thirty minutes of production traffic redirection.

Rollback Actions:

• Stop new target transactions.
• Restore source routing.
• Reverse DNS.
• Re-enable source application.
• Reconcile target-created transactions.
• Notify users.
• Preserve logs and database evidence.