Th: 11 Document different scenario & steps for migration - TanveeKhanDB/OCI GitHub Wiki

Build a migration dossier for OrderDesk, a fictional application with a web server, Oracle database, attachment store and reporting integration. Compare four relocation paths, then rehearse a transfer and recovery procedure.

This is a planning and validation lab. Examples do not claim a production migration has been completed. Use disposable resources and synthetic or masked data for practical work. Cloud infrastructure and transfer services may incur charges.

Deliverables: workload inventory, four scenario worksheets, target design, validation record, timed cutover plan and acceptance sheet.

Before choosing tools, complete this worksheet.

Draw the dependency chain user → application → database → reporting service. Add the attachment store and identity provider. Mark components that need a coordinated move because a temporary split would break transactions or create excessive latency.

Keep these objectives separate:

• RTO: recovery-time limit after disruption.
• RPO: maximum acceptable age of lost data during recovery.
• Migration outage window: the separately agreed period for the planned switch.

For the exercise, assume a 60-minute outage, 60-minute RTO and 5-minute RPO. These are fictional planning values, not production recommendations. Record source latency, error rate, throughput and resource usage under representative load as the comparison baseline.

Checkpoint: another engineer can identify every dependency and the owner who approves each requirement.

Start with a low-risk pilot. Group later waves around dependencies, then schedule critical services after the process is proven. A wave is a coordinated workload group, not simply a fixed number of servers.

Challenge: users are closer to another OCI region; ownership remains within the same tenancy.

1. Confirm destination services, quotas, capacity and approved data location.
2. Build the target VCN, subnets, routing, access controls and monitoring. Avoid address conflicts with connected networks.
3. Recreate infrastructure from controlled configuration. Check image, backup and database portability for each service.
4. When private inter-region traffic is needed, configure DRGs and remote peering, including route tables and security rules. This creates a network path; it does not transfer servers or databases.
5. Seed the database and files with a supported restore/export or replication method. Track changes made during the initial copy.
6. Test the destination, freeze source writes, apply the remaining changes and reconcile before switching users.
7. Retain a recoverable source until acceptance and the required retention period end.

Attach to the worksheet: regional capability review, network diagram, copy log, reconciliation record and response-time comparison.

Challenge: a subsidiary must take ownership of OrderDesk in its own tenancy.

1. Identify both tenancy owners and the exact resources and datasets to transfer.
2. Record ownership and data-transfer approvals, including responsibilities for retained records.
3. Prepare target compartments, identities, policies, keys and operating controls. Source resource identifiers and permissions are not automatically portable.
4. Choose connectivity according to region and isolation needs. A tenancy change does not always require remote peering. Cross-region peering and same-region designs require different planning; use the OCI DRG documentation for the selected topology.
5. Scope temporary cross-tenancy permissions to the transfer. Test approved paths and confirm unrelated resources are inaccessible.
6. Copy approved data, redeploy the application and configure target endpoints and credentials.
7. Obtain acceptance from both owners and remove temporary access after the transfer is accepted.

Attach to the worksheet: ownership record, access matrix, isolation tests, data manifest and two-party acceptance.

Challenge: the organisation wants OrderDesk hosted in its Azure operating environment.

Service names provide starting points for design. They do not establish feature parity or automatic conversion.

1. Design Azure resource organisation, identity and networking. For hub-and-spoke, document gateway placement, DNS forwarding, inspection paths and spoke isolation.
2. Assess connectivity. OCI–Azure interconnect joins FastConnect and ExpressRoute in supported locations; check the actual region pair. A provider connection or VPN may suit other requirements. See Oracle multicloud interconnect.
3. Verify bidirectional routes, DNS, required ports, throughput and path failover. Specify encryption explicitly; a private circuit alone does not prove all encryption requirements are met.
4. Select the server method after checking support. Azure Migrate covers multiple source types, including public-cloud VMs, but the machine and migration-path requirements still need assessment. Rebuilding and redeploying is another option. See Azure Migrate overview.
5. For Oracle-to-Oracle movement, assess logical export/import or physical backup/restore according to compatibility. Supported, licensed change replication may reduce the catch-up period; test the complete seed-and-sync process.
6. For a different database engine, assess schema, procedures, types and application SQL separately. Choose tooling for the precise source/target pair. A generic migration service does not guarantee Oracle conversion support.
7. Transfer files and objects using a tool that supports both endpoints. Reconcile bytes, metadata and permissions. Recreate secrets through an approved process.
8. Validate the application and rehearse recovery, including preservation of writes made after target activation.

Attach to the worksheet: compatibility matrix, service decisions, network tests, database method, licensing review, cost estimate and recovery evidence.

Challenge: OrderDesk runs on ageing local equipment.

1. Inventory physical/virtual hosts, storage, hardware dependencies, operating systems and licences.
2. Identify fixed-IP assumptions, attached devices and unsupported runtimes. Decide their treatment before building the target.
3. Prepare OCI compartments, networking, access, keys, backup and monitoring. Confirm capacity for special needs such as GPUs before committing.
4. Select FastConnect or Site-to-Site VPN based on throughput, resilience, lead time and cost. Plan redundant paths when required.
5. Test dependencies that remain local, including identity, DNS and partner integrations.
6. Move a pilot, validate it, then repeat in dependency-based waves.
7. Keep original hosts recoverable through the acceptance period.

Attach to the worksheet: host assessment, connectivity results, pilot report, wave schedule and source-retention decision.

Produce two linked design records. The HLD explains architecture, service choices, security boundaries and recovery objectives. The LLD specifies addresses, routes, policies, sizing, configuration and implementation steps. Review changes for consistency between them.

Before live data is loaded, demonstrate:

• Named identities, MFA where appropriate and narrowly scoped administrative access.
• Private application/database placement and rules limited to required traffic.
• Approved encryption, key ownership and secret handling.
• Owner, application, environment and cost-allocation tags.
• Audit retention, budget alerts and incident escalation.
• Backup restoration and a recovery exercise against the agreed targets.
• Approved data locations and applicable organisational requirements.

Estimate costs from quantities: compute, storage, backup, circuits, transfer, licences, support and temporary duplicate environments. Build the schedule from dependency analysis, data size, change rate and measured rehearsal durations.

Sizing exercise: an initial 200 GB copy at an effective 100 Mb/s takes about 4.4 hours before validation and later changes. Use observed throughput rather than the circuit's advertised rate.

Complete the security assessment before go-live. Resolve blocking findings and record any formally accepted exceptions.

Reconcile data at a common consistent point. Counts alone do not establish correctness. Compare row/file counts, file hashes, appropriately normalised database values, sampled related records, business totals and the final replication checkpoint.

Example Oracle checks, adapted to the real schema:

SELECT COUNT(*) AS order_count FROM lab_orders;
SELECT status, COUNT(*) AS order_count, SUM(total_amount) AS amount
FROM lab_orders
GROUP BY status
ORDER BY status;

Run equivalent checks on both sides after final sync. Keep outputs with timestamps and investigate unexplained differences. Matching totals do not replace transaction-level validation.

flowchart TD
    A[Readiness evidence complete] --> B{Approve window?}
    B -->|No| C[Fix gaps and repeat rehearsal]
    B -->|Yes| D[Freeze source writes and jobs]
    D --> E[Final sync and reconciliation]
    E --> F{Validation passes?}
    F -->|No| G[Execute data-safe recovery]
    F -->|Yes| H[Test target with controlled access]
    H --> I[Approve and redirect users]
    I --> J[Observe transactions and service health]

Inform users, support and affected partners ahead of the change. Confirm certificate coverage and new IP allow-lists. Lower DNS TTL early enough for the previous TTL to expire, while allowing for clients that cache addresses or retain sessions.

Use this illustrative runbook for the lab's 60-minute outage. Replace estimates with rehearsal measurements.

The minute-40 decision reserves 20 minutes for rehearsed recovery. If recovery needs longer, move the decision earlier or revise the window. Do not consume the reserve without a new decision.

Agree triggers beforehand: unexplained reconciliation differences, a failed critical workflow, excessive errors/latency, or a missed decision deadline.

Before target writes: stop target services, confirm the source remains authoritative, restore the source traffic path, restart source jobs and validate access.

After target writes: freeze target writes and preserve its changes. Run a tested reverse-replication, transaction replay or reconciliation procedure before reopening source writes. Reversing DNS alone may lose orders or duplicate processing. Where safe return is unavailable, document that limitation beforehand and agree restore or forward recovery.

Maintain one authoritative writer in this lab. Include queues, background jobs, files and external side effects in recovery planning.

Failure drill: fail a target health check before opening writes. Return to the source, record elapsed time and prove that no order was lost or processed twice. Then model the post-write case using synthetic transactions and reconcile them before reopening either side.

During the agreed observation period, track response times, errors, database health, failed jobs, capacity and actual spend. Assign alert owners and escalation contacts. Include relevant business cycles when deciding how long observation should last.

Leave these items unchecked until evidence is available:

• Scope, architecture and costs are approved.
• Business workflows and partner integrations pass.
• Reconciliation has no unexplained differences.
• Outage and recovery results meet approved limits.
• Performance meets agreed baseline criteria.
• Access, encryption and security reviews are complete.
• Backup restoration and recovery are demonstrated.
• Operations has runbooks, training, contacts and as-built diagrams.
• Business acceptance and source-retention dates are recorded.
• Temporary permissions and migration services have a removal plan.

Decommissioning is a separate controlled step after acceptance and retention obligations are satisfied. Preserve required final backups, obtain required approval, remove obsolete resources and update cost/licence records. Review observed target demand before purchasing long-term capacity commitments.

Include the inventory, all four scenario worksheets, HLD/LLD, compatibility decisions, costs, test outputs, timed cutover/recovery records and acceptance sheet. Label items planned, tested or approved accurately.

1. Why is working peering insufficient evidence of a completed migration?
2. Which dependency could require two components to move in one wave?
3. What must change in recovery after the target accepts an order?
4. How would you prove copied attachments retain the intended access?
5. What evidence would justify retaining a workload where it is?