How to verify where your data is stored before migrating to the cloud

Knowing in which region a resource is stored helps evaluate residency, latency, redundancy, and recovery requirements. Location must be reviewed by service and resource: in Cloud Storage, for example, the location type determines how information is replicated.

For a regulated migration, separate three questions: where the main data is stored, where it can be replicated or processed, and which entities can access it. Location must be evaluated by resource and service, along with the conditions applicable to the organization.

Location also affects technical decisions. In Google Cloud Storage, a region, a dual-region, and a multi-region have distinct redundancy and cost behaviors; placing storage near computation can help performance. Choose the location based on the specific requirement, not because the geographic name seems sufficient.

In Google Cloud Storage, a region is a specific geographic location; a dual-region comprises two regions, and a multi-region covers a broad geographic area with two or more regions. The location type determines how information is replicated and billed. Specific options depend on the service.

Do not assume that a region code identifies a single building. In Cloud Storage, Google distinguishes regional, dual-regional, and multi-regional locations; objects in a dual-region are replicated in the regions that compose it, while a multi-region covers a broader geographic zone. The granularity configured by the client depends on the service and should not be confused with the physical location of each copy.

Nor do all services in the same project inherit a single location. Firebase documentation indicates that products like Cloud Firestore and Cloud Storage require locations configured per instance or bucket, and that some functions have a default region if none is specified. A project configuration does not automatically prove where all its resources are.

Start by inventorying the services that will contain personal or confidential data: databases, buckets, disks, backups, queues, logs, and analytics services. For each item, note the resource identifier, the service, the configured region, the owning account or project, and dependencies that may generate copies or additional processing. The unit of verification is the resource, not just the cloud account.

In Google Cloud Storage, location is part of the bucket metadata and can be consulted with appropriate permissions. Official documentation distinguishes region, dual-region, and multi-region, and specifies that the chosen location influences replication and price. In Firebase, the location guide describes where to check the location of databases, buckets, backends, and functions; some products, like Gemini Developer API in Firebase AI Logic, are described as global.

The AWS DataSync guide indicates that, to transfer data to or from an Amazon S3 bucket, a transfer location is created and DataSync is granted access to the bucket via an IAM role. That configuration describes the access necessary for the transfer.

Azure Portal allows managing resources and viewing them organized by service and resource group. To verify residency, identify the specific region of each resource and separately check accompanying functions, such as geographic redundancy, disaster recovery, and monitoring services. A deployment region does not prove that all derived or auxiliary data has the same territorial scope.

ISO/IEC 27001 refers to an information security management system within a defined scope; it is not a map of data centers or a universal residency certification. Before attributing value to it for a migration, identify which entity, service, region, and activities the certificate covers, in addition to its validity and issuing body.

Providers publish scopes that can vary by service or geography. For example, Esri explains that the scope of its ISO 27001 certification for ArcGIS ISO Cloud applies to services hosted in its European regional location and does not automatically extend to APAC. It also clarifies that AWS or Microsoft Azure certifications on underlying infrastructure do not themselves expand the scope of Esri's certification.

OVHcloud's compliance page distinguishes included services and points to a specific perimeter for US data centers. As a practical check, request the certificate and review its scope for the contracted service. A certification supports controls included in that scope.

Evaluate security, privacy, compliance, and location separately. Check the specific scope of each certificate or report: it may identify the entity, services, and locations included. OVHcloud, for example, indicates that its certificates and reports cover services hosted in its data centers, with a specific perimeter for the United States.

To know the location of a resource, consult the metadata or location configuration offered by the service. In Cloud Storage, the bucket location is part of its metadata and can be consulted with the appropriate permissions.

Another error is assuming that all services in the same project have a single location. Firebase distinguishes resources whose location is configured per instance, bucket, or backend, and products for which a location cannot be selected, such as Gemini Developer API in Firebase AI Logic. Review the location according to the product and resource.

Finally, do not confuse regional availability with the location of each object. Redundancy options may imply replicas in several regions; this may be desirable for resilience, but it must fit with residency restrictions. Confirm which modality is active, how recovery behaves, and if there are restrictions to change or move the location.

Before approving the transfer, convert the legal and operational requirement into verifiable and maintainable checks. A screenshot can serve as a point-in-time record, but it does not replace a contractual clause or a change control procedure. Keep the configuration and its review date in the asset inventory.

• Identify each service and resource that will store, replicate, or process sensitive data.
• Record region, zone if applicable, redundancy modality, and backup location.
• Check the effective location and who has permissions to modify it in the console or metadata.
• Review the locations of logs, support, monitoring, analytics, and connected services.
• Request certificates and reports with identifiable scope, entity, service, geography, and validity.
• Contrast residency and transfers with the contract, service terms, and applicable legal analysis.
• Define who will review region changes, new replicas, and exceptions after the migration.

The final decision does not consist of choosing a country from a product label, but in verifying that the architecture satisfies the requirement. Document the configured locations and redundancy modalities for each resource and evaluate any component whose location you cannot determine against the workload needs.

The practical result is a file per workload: identified resources, documented locations, contractual scope, and relevant certifications, along with responsible parties and change controls. If you cannot demonstrate the location of a critical piece, do not treat it as equivalent to the others or assume it is covered by the main region.