A cloud exit plan should prove the service works somewhere else

Start the cloud exit rehearsal at the destination. Ask its proposed operating team to produce one business result with exported data and the replacement tools. The exercise will reveal more about portability than a successful download or a diagram showing a new hosting location.

For the cloud platform lead, the objective is a credible option before renewal. That requires knowing what can move, what must be rebuilt, how long the transition will take and which risks the business would accept. An exit plan can support a decision to stay when the existing service’s value exceeds the cost of replacing it.

Move a useful slice, including its awkward data

Choose a representative workflow, such as producing a customer invoice or completing a reporting cycle. Include the transformations, permissions, scheduling and downstream consumers needed to finish it. Avoid a sample consisting only of the easiest tables or the least consequential application.

Export formats have practical boundaries. BigQuery’s export documentation states that nested and repeated data cannot be exported in CSV, while Avro, JSON and Parquet support it. It also explains that JSON exports encode INT64 values as strings to preserve precision. The destination needs to interpret that structure and typing correctly, rather than merely accept the files.

In a hypothetical invoice migration, the exported customer and order records load successfully, but the destination’s transformation changes how repeated line items are handled. The file count matches while an invoice total does not. Reconcile the business result and investigate the difference before describing the workflow as portable.

Test more than totals. Include keys, missing values, time handling, relationships and exceptional transactions relevant to the service. Check that the authorised user can complete the task and that an unauthorised user cannot. The goal is equivalent behaviour at the boundary the business depends on, not identical internal technology.

Keep failed tests useful. If a proprietary transformation needs rewriting or a scheduler needs replacing, that is part of the cost of leaving. It may be entirely manageable, but it belongs in the estimate and sequence before the renewal deadline forces a rushed decision.

Separate data transfer from service replacement

Inventory the dependencies that remain after an export: identity, secrets, encryption keys, message delivery, monitoring, deployment pipelines, backups and supplier support. Identify who will run the replacement and what new tasks they inherit. A destination with no tested restore procedure is not operationally equivalent to a service whose recovery process the business already relies on.

Estimate migration duration from the slowest necessary path. Moving bytes may be quick compared with validating results, obtaining permissions or rebuilding an integration. A short sample transfer can also mislead when the full dataset competes with production traffic or requires repeated reconciliation.

Account for changes during the move. BigQuery documents that data loaded while an extract job runs is not included in that job and requires another extract. For a live service, decide how later changes are captured, how the final difference is reconciled and whether the business can tolerate a pause in writes. A snapshot alone does not define a cutover.

The operating team should rehearse the switch and the decision to stop it. Define who authorises cutover, what evidence is required and what happens if a critical comparison fails. Keep the old environment usable until the agreed acceptance point, with a clear understanding of the cost and access needed to retain that option.

Rollback also has a data problem. Once the destination accepts new transactions, returning traffic to the old system may require reconciling those changes. “Switch back” is incomplete unless the plan explains what happens to work completed after the switch.

Put commercial conditions on the migration timeline

Data-transfer offers can reduce one cost without removing the rest. Google Cloud’s free exit data-transfer programme requires an Exit Notice before migration for which credits are expected. Its published conditions require ending all use of the particular Google Cloud service being left, while allowing continued use of other Google Cloud services. A partial move within that service does not qualify under the programme.

These conditions affect sequencing. Match the intended scope to the offer, confirm the applicable process and migration period, and identify when completion notice triggers termination. Do not begin a rehearsal or partial migration on the assumption that every transfer charge will later be credited. Equally, do not retain an obsolete egress estimate when an applicable offer has been confirmed.

Review the actual agreement for notice, outstanding commitments, export access, deletion and any paid assistance. Keep account access and the people authorised to submit notices available through the transition. Turning off the administrative route too early can make an otherwise successful move difficult to close.

Price the whole transition: destination preparation, engineering, validation, parallel operation, residual commitments, supplier assistance and decommissioning. Distinguish an estimate supported by a rehearsal from a task whose effort is still unknown. The uncertainty itself can justify a small test before the organisation commits to either a hurried move or another long term.

Finish the plan with a decision the service owner can use: a plausible destination, the demonstrated workflow, the remaining gaps, a migration sequence and a cost range tied to those gaps. Refresh it after material architecture or contract changes, rather than preserving an export procedure for a service that no longer exists.

Take that evidence into the vendor lock-in and renewal decision. A tested exit option lets the business value the benefits of staying with a clearer view of what leaving would actually require.