Why a cloud pair is not enough
An application calls a specific Azure API with specific operations, fields, errors, identity behavior, and state semantics. A valid route must document how those behaviors map to a particular Scaleway service. Similar names such as blob storage and object storage do not establish that contract.Check the catalog
Start with the Azure Service Catalog. Select the exact origin service and read across its target environments. A supported direction links to a detailed service page with:- supported and rejected operations;
- capability and fidelity comparisons;
- identity and resource-name behavior;
- data, key, and state migration boundaries;
- target-specific limitations and other considerations.
Evaluate the application workload
Before choosing another route, capture the workload requirements:- Inventory every Azure service and operation the application calls.
- Record request options, conditions, pagination, retries, and expected errors.
- Create test data with no production dependencies.
- Define the native Scaleway state you would verify after each operation.
- Define cleanup for partial success and uncertain writes.
- Keep origin credentials separate from any target verification credentials.
What a supported route documents
Do not use a generic S3-compatibility test as evidence for an Azure Blob API route. It proves a different origin protocol.
For a runnable Scaleway example, use AWS to Scaleway, whose S3 to Scaleway Object Storage profile is published. For an Azure-origin workflow, choose a supported target from the Azure catalog.