Cloud portability: what to check before planning a migration

The editorial question is specific: has a recent, verifiable change altered the conditions for moving data or services between cloud providers? The documentation gathered for this article does not support answering yes. The sources include general explanations of cloud services, billing pages and user discussions, but no recent announcement demonstrating that portability has become easier, harder or otherwise changed in general terms.

For that reason, presenting this subject as current news would require a claim that the research does not support. The entry into force of the European Data Act is an important regulatory development, but the source consulted places it in January 2024. That fact alone is not enough to turn it into a new development in October 2026. This article is therefore framed as a verification guide, not as an announcement of a new development or a conclusion about the market as a whole.

The distinction matters because “cloud” covers different services: moving files is not the same as rebuilding a database, an application or infrastructure. An introductory page about types of cloud services can help identify those categories, but it does not establish that a particular workload is portable. The availability of an export option is one specific piece of evidence; it does not prove that the entire service can be replaced without changes.

The first step is to find the documentation for the exact product that holds the data and read it as a procedure, not as a general promise. Determine which objects can be extracted, in which formats, through which interface and subject to what restrictions. Also check whether the process preserves relevant attributes such as metadata, permissions, timestamps or relationships between records. If the documentation does not clarify one of these points, record it as an open question rather than assuming that the information is preserved.

An export, on its own, also does not prove that the destination can use the data. A format may be readable and still require conversion, scripts or a compatible application. For a database, for example, extracting a copy does not establish that the schema, queries or service-specific functions will behave the same way in another engine. In an application service, data may be only one part of the workload: configuration, secrets, queues, identities and connections to other services would also need to be identified.

To avoid generalisations, record the source and scope of every answer. A manual for one service and region does not necessarily describe another product from the same provider. A useful checklist can include:

• Content: what is exported and what is excluded.
• Format and tools: supported formats, available interfaces and conversion requirements.
• Operational limits: size, volume, duration, quotas and possible interruptions.
• Dependencies: services, APIs, licences or configurations that would need to be replaced.

The absence of a published answer does not prove that a feature does not exist; it means that it needs to be confirmed in additional documentation or with the provider.

The price of a transfer is not necessarily the total cost of a migration. An assessment should separate data-egress charges from other possible items: temporary storage, read operations, conversion tools, resources at the destination, connectivity and technical work. Billing documentation may explain how charges or discounts apply to a particular case, but it cannot by itself calculate an organisation’s bill without information about its volume, region, configuration and billing period.

The available sources include Google Cloud documentation about a data-transfer waiver or discount for research and education. Its existence shows why the scope and eligibility criteria of each policy need to be checked; it does not demonstrate that the benefit is available to every customer or migration. There is also a Google Cloud page describing the data structure of a pricing export. That structure may help analyse pricing information, but it is not the same as a final quotation for egress costs.

Before comparing scenarios, record the date checked, currency, market, region, traffic type and tariff conditions. Then calculate the scenario using actual usage data and compare the result with the relevant official calculator or documentation. If a price depends on an allowance, service class or exception, the comparison must reflect that condition. Without those data, a single figure would imply false precision, not an estimate that can be generalised.

The European Commission reported that the Data Act entered into force on 11 January 2024 and presented it as part of the European rules on access to and use of data. The legislative text published on EUR-Lex is the primary reference for reviewing its scope and specific provisions. However, a law does not demonstrate that a particular export is complete, that one format is compatible with another system, or that a transfer can take place without interruptions.

A practical assessment requires a distinction between legal obligations, provider documentation and system behaviour. These are related, but they are not interchangeable. For an actual decision, an organisation must identify which services and data are within scope, which contractual terms apply and which technical tests are still outstanding. If the question is legal—for example, how a provision applies to a particular contract—this editorial review is not a substitute for specialist analysis.

Nor should community questions and answers be treated as an official tariff or a product guarantee. The available Azure discussions illustrate specific user questions about transfers and costs, but they do not, on their own, constitute a contractual policy or price list. To establish an assumption, consult the current official documentation for the service and check that the rule applies to the region, route and configuration in question.

An initial assessment can conclude with a concise matrix separating what is confirmed from what has not been checked. For example, “the documentation describes an export in format X” is an observation limited to that source; “the application can be migrated without changes” is a conclusion requiring additional tests. The matrix also helps assign responsibility and prevents a documented possibility from becoming a guarantee in meetings or budgets.

Before approving a plan, the team should test a representative sample and verify integrity, timing, permissions, dependencies and operation at the destination. The sample alone cannot predict all behaviour at large scale: its limits must be recorded and compared with actual volume, network conditions and service windows. If continuity, recovery or temporary coexistence is required, those requirements are also part of the design and cost.

The conclusion of this research is deliberately limited: there is not enough evidence here to publish that a recent change has made cloud portability easier or harder. There are, however, reasons to treat export, formats, billing terms and dependencies as matters to verify for each service. Whether a migration is viable depends on the case, and only a specific assessment—with applicable documentation and testing of your own—can support that conclusion.