Single service comparison

STS accepts a broader set of source types than OMS. STS ingests from S3-compatible stores, Azure Blob, HTTP/HTTPS URLs, and on-premises file systems using deployable transfer agents; OMS only accepts S3-compatible and HTTP/HTTPS-accessible object storage plus self-built object stores, with no agent-based file-system path. For on-premises NAS or POSIX file data that STS sweeps via agents, OMS is not an equivalent target and a separate Huawei file-migration approach is required.

Operationally both are task-driven with resumable transfers, hash verification, and incremental sync, but STS exposes natively scheduled recurring transfers and Cloud Scheduler-driven jobs, while OMS relies on manual or flag-based synchronization tasks plus SMN notifications. STS splits work via manifest files and condition logic; OMS auto-splits large jobs into concurrent task groups by object prefix and applies real-time traffic limiting. Neither exposes a public REST control-plane API for arbitrary orchestration without console or SDK invocation.

Pricing models diverge sharply. STS charges nothing for agentless cloud-to-cloud transfers and bills per-GB-month only for agent-based file transfers. OMS is a free service but you pay the source provider's egress and API-request fees plus Huawei OBS request charges (HEAD/GET/PUT per object, multipart for objects over 50 MB), so cost scales with object count, not just bytes. Recalculate using object cardinality, multipart thresholds, and cross-region traffic before committing.

Inventory the GCS source: bucket layout, object count, sizes, storage classes, lifecycle rules, KMS encryption, retention and holds, and HTTP-source endpoints. Match each source to a Huawei target: S3-compatible or HTTP/HTTPS object sources map directly to OMS-to-OBS; on-premises file-system sources backed by STS agents have no direct OMS equivalent and need a different Huawei file-migration approach, not OMS. Confirm OMS supported source providers and regional availability before assuming any third-party store is accepted.

Re-create bucket policies, lifecycle rules, KMS-encrypted storage classes, and CORS in OBS before migration. In OMS, configure migration tasks with source credentials, destination bucket, object selection by prefix, list, or time, storage class, and traffic limits. Use OMS synchronization tasks for incremental deltas and resume failed objects from recorded lists. Keep the 50 MB multipart boundary in mind when estimating request volume for large objects.

Before cutover, run a pilot OMS task on a representative prefix subset and compare object counts, sizes, ETags or hashes, and metadata. Use OMS failed-object reports and SMN notifications to drive retries until the delta stabilizes. Schedule application read/write cutover only after synchronization shows no source-side churn; freeze writes during the final sync window and repoint consumers to OBS endpoints. Re-validate lifecycle, versioning, and access policies in OBS post-cutover.

Reprice the workload for OBS, not GCS. OMS cost equals source API requests plus destination OBS HEAD/GET/PUT requests plus source egress, with extra requests for skipped and multipart objects, rather than a simple per-GB rate. Account for archived-object restoration fees if source classes are archival. Where STS ran scheduled recurring transfers, plan manual or externally triggered OMS sync tasks, since OMS lacks native recurring-schedule automation. Document unsupported STS features such as agent-based file transfer as known gaps.