Migrating from OpenStack Swift to Ceph RGW: what the move involves
If your Swift cluster serves applications directly, or serves OpenStack services such as Glance or Cinder backup, and you have decided to move to the Ceph Object Gateway (RGW), the effort is set less by the storage itself and more by four things: how far your clients depend on Swift-specific behavior, how Keystone authentication is wired into every consumer, how endpoints change in every client configuration, and how the existing data is copied across. Ceph RGW speaks both the S3 and Swift APIs, so the question is not whether data can be stored, but which API calls your applications make and whether RGW implements each one the way your clients expect. Start by inventorying clients and the Swift features they use, including temporary URLs, large object manifests, container-level ACLs, metadata and version handling. The number of clients that rely on those features, not the total data volume, is usually what determines the scope.
Keystone integration deserves its own design decision. RGW can authenticate users against Keystone, but your token validation, service accounts, project-to-tenant mapping and role names must be checked against your current deployment and the RGW release you plan to run. Confirm the exact Keystone settings for your chosen release in the Object Gateway documentation before you plan the cutover, and test token behavior for every service account, not only for human users. For the data copy, decide whether containers are migrated by a tool that reads through the Swift API or through S3, and whether object metadata, timestamps and ETags must survive the move. Plan endpoint changes per client, for example a DNS alias that you repoint at cutover or a configuration change in each application, and decide how long Swift and RGW will run side by side while writes are redirected and verified.
Running both stacks during cutover is where most of the risk sits. Agree on a single write path per container during the transition, define how changes made after the initial copy are synchronized, and set a rollback point for each consumer. The effort will recur for as long as both clusters run, so ask any partner to state which parts are one-time (design, Keystone mapping, client changes, the copy and its verification) and which continue (parallel operation, monitoring and decommissioning Swift). Where an assessment is needed before you commit, a short compatibility test against a copy of your client workload gives the most reliable basis for an estimate.
Which Swift features map to RGW and which need redesign
This table compares common Swift capabilities with their closest Ceph Object Gateway (RGW) equivalents and notes where a feature needs a redesign. Read the notes column as a checklist: items marked to confirm need a test against the RGW Swift API documentation for the release you plan to run before cutover.
| Swift feature | RGW equivalent | Migration notes |
|---|---|---|
| Containers and objects | Swift containers map to RGW buckets exposed through the Swift API | Confirm how container names, account naming and URL layout appear to clients before changing any endpoint. |
| Account and container metadata | Swift metadata headers are supported through the Swift API | Confirm which X-Account and X-Container metadata headers your clients read and write, and test each one. |
| Temporary URLs | Supported through the Swift API with temp URL keys | Confirm signature algorithms and key handling for your release, and plan to reissue links that outlived the old keys. |
| Large object handling (SLO and DLO) | Large object manifests are supported in the Swift API, with behavior to verify | Confirm manifest behavior, segment container layout and listing semantics. Clients that assume Swift-specific segment naming may need changes. |
| Object versioning | Versioning is available on buckets, but the Swift versioning model is not identical | Flag as needing redesign if applications depend on Swift-style version containers. Confirm the behavior of delete markers and version listing. |
| ACLs and Keystone roles | Keystone authentication for the Swift API maps project roles to access, with RGW-side policy | Map each Swift role to an RGW access decision and test read-only and admin paths. Roles that rely on container ACL edge cases need explicit review. |
| Swift behaviors without a direct counterpart | No one-to-one equivalent for some Swift-specific operations | Identify custom middleware, account-level quirks and any operation your clients call that the RGW documentation does not describe. Plan a redesign or client change for each. |
Documented paths for moving Swift data into RGW
Moving objects out of Swift and into RGW usually means one of three routes: an S3-style copy tool reading through a compatible endpoint, an rclone-style sync, or a documented script that converts the data directly. Each route changes what metadata survives, so the choice should follow a test on your own containers rather than a general preference.
S3-compatible copy tools
Some S3 client tools can read from a Swift endpoint through a compatible API layer and write into RGW buckets. This keeps one copy path for both sides, but it depends on how completely the source exposes object listings, large objects and custom headers. Validate the tool against your exact Swift version, and confirm how it handles segmented large objects and zero-byte directory markers before running a full copy.
rclone-style sync
rclone-style sync tools can list containers on the source, stream objects, and write them to RGW while preserving a checksum comparison. They suit incremental passes during cutover, since a repeated sync only moves what changed. Confirm which checksum and modification-time behavior your chosen version applies to Swift and RGW, and run a dry-run listing comparison before trusting it for the final pass.
Native Swift-to-S3 copy scripts
Where the Ceph documentation describes a Swift-to-S3 copy procedure, it is the most direct path because it targets the RGW interfaces the cluster is built around. Only use steps the documentation covers for your release, and check which account, container and ACL mappings the procedure assumes. Treat any script you did not get from documentation as a custom tool that needs its own review.
Metadata that survives the copy
Object bodies copy reliably in most tools, but user metadata, content types, expiration settings, Swift-specific container ACLs and temporary URL signatures may not map one to one. Build a small test set with each variant, copy it, and compare headers on both sides. Record which fields arrive intact and which need to be reapplied through RGW configuration or client code.
Validation against your Swift version
The team should validate every tool against the exact Swift release and RGW release in their environment, since API coverage differs between them. Ask each tool's maintainers which Swift features they support and which they reject. Run checksums on a sample of containers, including the largest objects and the deepest prefixes, and keep the results with the cutover record.
Running both during cutover
During cutover, applications may write to Swift while the copy runs, so the plan needs a final incremental pass and a defined freeze point for each container. Decide whether writes stop, switch to RGW, or dual-write, and confirm which tool can resume after an interruption. Document who approves the switch and how a rollback back to Swift would work.
How Keystone authentication works for RGW during cutover
The Ceph Object Gateway can validate Keystone tokens for both Swift and S3 requests, which means your existing Keystone identities can keep working during a Swift to RGW move instead of forcing every client to receive new credentials on day one. RGW checks the token against the Keystone endpoint you configure, then maps the authenticated project and roles to the bucket ownership and access rules it applies. Before cutover, confirm the exact Keystone-related configuration keys and their expected values in the Ceph Object Gateway documentation for your release, and confirm that the RGW node can reach the Keystone admin and identity endpoints over the network path your clients will use. Treat that network check as a cutover prerequisite, not a detail to revisit later.
The critical alignment work is in project IDs and roles. Swift accounts in OpenStack are keyed to project IDs, so the RGW tenant or user model you choose must make each project's data land in a predictable place, and the roles that Swift operators use for container administration must map onto the RGW permissions your applications expect. Build a table of every project, the roles held by each service account, and the RGW identity that will own the corresponding buckets, then verify it with a test project before any production traffic moves. Illustrative example: if a backup service account holds a reader role in Swift but RGW maps it to full control, a misconfiguration may be invisible until a restore is attempted.
Token policy is the most likely source of surprise. Keystone token lifetimes, the scope a token carries, and whether long-running jobs refresh tokens can differ from what a Swift client assumed, and a token that validates on the Swift endpoint may behave differently when the same client is pointed at RGW. During the period when both systems run, test long-lived uploads and scheduled jobs against the token settings in force, and record which clients use application credentials, EC2-style credentials or direct tokens, because each path has its own validation behavior. Ask your Keystone administrator to confirm that token policy changes are frozen for the cutover window.
Running Swift and RGW side by side through cutover
This sequence moves accounts, containers and client applications from Swift to RGW while both clusters stay available, so each stage has a known state and a clear exit check. The result is a verified copy on RGW, clients pointed at it, and a Swift cluster kept intact until the rollback period ends.
Inventory accounts, containers and client applications
Your team lists every Swift account, container, and the applications that read or write them, including batch jobs, backup tools and scripts that hold credentials. For each container, record object count, total bytes, metadata and large-object or static-website settings, then flag any feature that RGW's Swift API layer does not cover in your environment. Confirm each gap with a test against your RGW version rather than relying on assumptions. The output is a migration register with an owner, a target bucket name and a cutover group for every application. The step is done when every container maps to an owner and every flagged gap has a decision.
Stand up identity and run a pilot tenant
Configure Keystone authentication for the RGW endpoint, with a test project and user mapped to a single account, and confirm that tokens issued by your identity service are accepted. Then move one low-risk tenant end to end: bulk copy, delta sync, client change and validation. The pilot tests the tooling, the credential model and the runbook before anything important moves. The output is a written pilot report listing what failed, what needed manual work and how long each stage took in your environment. The step is done when the pilot tenant runs against RGW for a full working cycle with no unexplained object differences.
Run the initial bulk copy
Copy each container from Swift to RGW with a sync tool your team has tested, running against a snapshot of the source listing where possible. Start with the largest or least active containers so that throughput limits are found early. Keep a log of each container's source and destination counts and any objects that failed to transfer. Expect to rerun failed objects rather than assume a clean pass. The output is a bulk copy log and a list of containers that still differ from the source. The step is done when the bulk copy completes for all in-scope containers and the remaining differences are small enough to close in the delta phase.
Sync deltas while both clusters serve traffic
Repeat the copy for objects written or deleted on Swift after the bulk pass, while applications keep reading and writing Swift. Use object timestamps or a change feed where your tooling supports one, and track deletes separately, since a naive copy will not remove objects that were deleted on the source. Repeat the delta run until each cycle changes a small and stable set of objects. The output is a delta log per container with the last synchronized point. The step is done when consecutive delta runs show no meaningful change and the team agrees on a cutover window.
Change client endpoints and credentials per application
For each application in the register, prepare a configuration change that sets the RGW endpoint, the Keystone-issued credentials or EC2-style keys, and any path-style or virtual-host addressing the client requires. Test the change in a non-production copy of the application, and keep the old Swift configuration available for reversal. Changes are applied per cutover group, not all at once, so each owner can observe their own application. The output is a signed-off configuration change per application and a record of which applications read from RGW and which still read from Swift. The step is done when every application has a tested configuration and an owner has confirmed its behavior.
Cut over with a read-only window on Swift
Put the Swift containers in scope into read-only mode, run a final delta sync so that RGW holds the complete data set, then switch each application group to the RGW endpoint. Keep Swift readable so that clients can check historical data and so that rollback remains possible. Watch error rates, latency and authentication failures during the window, and have the rollback configuration ready for each group. The output is a cutover record with the timestamp, the final delta result and the applications moved. The step is done when all in-scope applications write to RGW and no client is still sending new writes to Swift.
Validate object counts and checksums
Compare object counts, byte totals and checksums between Swift and RGW for every container, using a sample for very large containers and a full comparison for smaller ones. Include metadata and any object expiry or large-object manifests that the applications depend on. Investigate every mismatch before accepting it, because some differences come from tooling rather than data loss. The output is a validation report with pass or fail per container and a list of open exceptions with owners. The step is done when all containers pass or every exception has an agreed resolution.
Decommission Swift after the rollback period
Keep the Swift cluster intact for a rollback period that your organization agrees in advance, based on your recovery and audit needs. During this time, monitor RGW, keep backups of the Swift data and confirm that nothing reads from the old endpoint. After the period ends, take a final archive if your retention policy requires one, revoke Swift credentials, and remove the cluster from monitoring and backup schedules in an approved order. The output is a decommissioning record that lists archived data, revoked access and the date of removal. The step is done when Swift serves no clients and the archive or deletion is documented for auditors.
What drives the cost and duration of a Swift to RGW move
This table lists the main effort drivers in a Swift to RGW move, who carries the cost of each, and whether it is paid once or recurs. Use it to see where your own estimate is likely to grow and which numbers to collect before you ask a partner or your own team for a plan.
| Driver | Why it changes effort | Who carries the cost | One-time or recurring |
|---|---|---|---|
| Accounts, containers and object count | Each container must be copied, verified and mapped to a bucket, so volume and total size drive copy time and validation work | Platform team and partner for tooling and runs; client teams for sign-off | One-time |
| Swift-specific features in use | Features such as temporary URLs, object versioning, large object manifests or custom metadata may need a different approach on RGW | Platform team and partner, with client teams confirming behavior | One-time, unless workflows depend on them permanently |
| Client applications and hard-coded endpoints | Every application that embeds a Swift URL, account format or auth method needs a change, test and release | Client application teams | One-time per application |
| Keystone integration complexity | Token validation, service catalog entries, roles and project mapping for RGW must match the existing identity setup | Platform team, with identity owners consulted | One-time build, then ongoing user and role administration |
| Network path between clusters | Bandwidth, firewalls, routing and TLS between old and new clusters set the speed and reliability of bulk copies | Network and security teams; platform team for configuration | One-time, with ongoing firewall rules until decommission |
| Length of the rollback window | Running both clusters, syncing writes and keeping the old cluster ready for reversal extends operating cost and testing | Platform team for dual operation; partner if retained for support | Recurring for the length of the window |
| Test and validation scope | Checksums, listing comparisons and client regression tests grow with the number of workloads and data classes | Partner or platform team for tooling; client teams for acceptance | One-time |
What usually goes wrong when Swift clients move to RGW
Most failed Swift-to-RGW cutovers trace back to a handful of causes: clients that quietly depended on Swift behavior, endpoints and tokens that were never inventoried, and data that copied without its metadata. Each card names one risk and the check that catches it before users do.
Clients that rely on Swift-only behavior
Some applications use Swift API calls, headers, or response formats that RGW's Swift-compatible interface does not reproduce exactly. Container-level features, account metadata patterns and temporary URL handling can differ in detail. Prevention starts with an inventory of every client and the Swift calls it makes, followed by contract tests that run those exact calls against RGW and compare responses with the current cluster. Ask the Ceph team to confirm current API coverage for each feature you depend on.
Hard-coded Swift endpoints
Clients, scripts, CI jobs and configuration management templates often embed the Swift proxy URL, the account path or the storage URL returned by an old auth flow. These references surface only after the old endpoint is retired, so they fail in batches. Build the inventory from DNS logs, load balancer access logs and configuration repositories, not from the owner list alone. Plan a period where the old endpoint still answers and log which clients still use it before you remove it.
Token expiry and Keystone mismatches
Swift clients authenticate through Keystone and hold tokens with a fixed lifetime. If RGW validates tokens against a different Keystone configuration, or if the token lifetime and renewal behavior differ between the old and new paths, long-running jobs fail mid-transfer. Test with a job that runs longer than the token lifetime, confirm the service account and project mapping for each application, and check that revoked or disabled users lose access on both sides during the overlap.
Incomplete metadata and manifest copies
A straight object copy can drop custom metadata, content types, ACL-like settings, object versions or the manifest structure behind large objects. Swift large objects are stored as segments with a manifest, and a copy tool that reads only the assembled content may write a different layout or none of the expected metadata. Compare a sample of objects field by field, including segment counts, versioning state and custom headers, before accepting any bulk copy as complete.
Writes landing on the old cluster
During cutover, some clients keep writing to Swift after others have moved to RGW. Those objects then exist in one place only, and a later sync overwrites or misses them. Decide the write authority for each container, set a read-only window on the old cluster for the final sync, and verify that no writes arrived during that window. Dual-write is possible for some workloads but adds failure modes, so keep it limited to applications whose owners can confirm idempotent writes.
Unverified data after copy
A successful copy job does not prove the data arrived intact. Partial failures, retries and throttling can leave objects missing or altered without an obvious error. Generate checksums on the source before the copy, compare them on the destination after each pass, and keep the list of mismatches as the acceptance record. Ask the copy tooling owner how it handles retries and whether it can resume from a manifest of completed objects.
Questions teams ask before moving Swift to Ceph RGW
How much does a Swift to Ceph RGW migration cost?
The cost depends mostly on the size and shape of the data, the number of client applications that must change, and how much of the Keystone and network work is new. No fixed figure applies to every move. The one-time cost covers discovery, the target cluster build or review, the data copy, client endpoint changes, testing and cutover. Recurring cost is the infrastructure you run afterward, plus any support retainer you choose. Ask any provider, including DeployOpen, for a written scope that lists the containers, object counts, client applications, identity integration and cutover windows it covers. Fixed-scope quotes follow from that document, so a vague scope produces a vague number.
How long does a Swift to RGW move take?
Duration depends on how much data must be copied, how many clients must be repointed, and how many maintenance windows your organization allows. A small estate with few clients is a very different project from a multi-tenant platform with dozens of applications and large containers. Plan the discovery phase first, because it reveals the real volume and the list of Swift features your applications use. Then size the copy window against your network and the write rate on the source cluster. Ask for a timeline tied to those measured inputs rather than a generic estimate.
What does our team need to provide before the project starts?
The project needs an accurate inventory and access to the systems that define how the cluster behaves. Expect to provide:
- A list of accounts, containers, object counts and total stored bytes, plus any custom metadata in use
- Read access to the Swift cluster, its configuration and its logs, and administrative access to Keystone where RGW will authenticate users
- Named application owners who can confirm which clients use which endpoints and which tests prove a workload works
- Maintenance windows for cutover and a decision-maker who can approve a rollback
Missing owners are the most common cause of delay, because nobody can confirm a workload's behavior.
Can our own team run the Swift to Ceph RGW migration?
Yes, if your team has the skills to operate Ceph, Keystone and the Swift cluster, and time to run the copy and cutover without disrupting production. Many organizations split the work: internal staff own identity, networking and application testing, while an implementation partner handles the cluster build, the copy tooling and the runbook. Whichever model you choose, decide early who holds on-call duty during cutover. DeployOpen plans, implements and documents this kind of work inside your own infrastructure under a written scope, so you can compare an in-house plan against an external one on equal terms.
Do Swift clients need code changes to use RGW?
Often, clients need configuration changes rather than code changes, but some need code changes. RGW offers a Swift-compatible API, so applications that use standard Swift calls may only need a new endpoint and credentials. Applications that depend on less common Swift features, specific response headers, or account and container behavior may need testing or adjustment. Build a compatibility test set from real application traffic, run it against RGW, and record each gap. Confirm each API behavior against the current Ceph Object Gateway documentation before you commit to a cutover date.
How does rollback work if the RGW cutover fails?
Rollback is simplest when the Swift cluster stays intact and clients can switch endpoints back in a single change. Keep the source cluster read-capable until the target has passed agreed tests, and decide in advance how writes made during cutover will be reconciled. If applications write to RGW and then roll back, objects created only in RGW must be copied back or accepted as lost, so this decision belongs in the runbook before the window opens. Run both systems side by side for a defined period, then retire Swift only after the owners sign off.
Does Ceph's license change anything for a Swift replacement?
Ceph's source is licensed under LGPL-2.1 or LGPL-3, and the project does not sell a paid edition. Licensing still needs a review by your legal team, because bundled components carry other licenses and your own distribution or modification practices matter. Ceph's maintained releases also affect planning: Squid (19.2.x) has an estimated end of life of October 31, 2026, and Tentacle (20.2.x) has an estimated end of life of June 1, 2027. Choose the release line that matches your support window, and confirm current dates on the Ceph releases page before you finalize the design.
When it is safe to decommission Swift
Decommission the Swift cluster only after four exit criteria are met and recorded: object counts and checksums have been validated, no client traffic has reached the Swift endpoints for an agreed period, Swift data is retained in a restorable form, and each application owner has signed off in writing. Validation should compare per-account and per-container object counts and byte totals against an inventory frozen at the cutover point, then compare checksums for a sample and for every object you can verify cheaply. Be careful with multipart uploads: their ETags are not plain MD5 digests of the object, so compare against a manifest of part checksums or against hashes computed independently from the source. Record every mismatch and its disposition, because a count match alone can hide replaced or truncated objects.
Traffic silence is the criterion teams most often skip. Confirm from the Swift proxy access logs and the load balancer metrics in front of the endpoints that no requests have arrived for the period you agreed in writing, and make that period long enough to include month-end jobs, backup tools, and scheduled batch processes that run infrequently. Search application configuration for hard-coded Swift URLs and for old credentials, since a forgotten service can resume reads or writes after a long quiet spell. Retain a full copy of the Swift object data, the account, container and object metadata, and the ring and configuration files, and test a restore of a sample into a separate location before anything is deleted. Decide the retention period for that copy in advance, along with who may approve its destruction.
Sign-off turns those technical results into an accountable decision. Each application owner should confirm, in a dated document, which containers and accounts their service uses, that the RGW endpoints and Keystone-based credentials work for their workloads, and that any residual risk is accepted by a named person. Include the security team in that record, since access policies, object versioning and any encryption settings may differ between Swift and RGW. Finally, check the support status of your Swift release before setting the rollback window. The OpenStack releases site lists which series are maintained, and the stable branch policy keeps branches under maintenance for roughly 18 months, after which only SLURP releases may enter an unmaintained phase. If your release is no longer maintained, plan the retention period accordingly and confirm the position with your OpenStack vendor or internal platform team.
How DeployOpen scopes and delivers a Swift to RGW migration
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens and documents self-hosted open-source platforms in infrastructure you control. The cards below follow the order of a typical engagement, from the written scope that sets deliverables and timelines to the support that follows cutover.
Written scope before any work
A Swift to RGW migration starts with an inventory of what the Swift cluster actually serves: accounts, containers, object counts, sizes, large objects, static web hosting, temporary URLs and the applications that call them. The scope document records which of those are in and out, which API features your clients depend on, and the cutover window you can accept. Ask that the deliverables and timelines are written into the agreement before work starts.
Quote follows the scope
DeployOpen does not publish a price list. A quote is produced from the written scope, so the inputs that move cost are the number of containers and objects to copy, the number of client applications to repoint, the number of Keystone projects to map, and whether both platforms run in parallel during cutover. Ask the quote to separate one-time migration work from any recurring support.
Keystone authentication design
Swift users in many OpenStack clusters authenticate through Keystone, which makes that integration the first design decision. The plan covers how RGW validates Keystone tokens, how Keystone projects and roles map to RGW accounts, and how credentials are issued to clients. Confirm the Keystone and RGW versions in your environment before design starts, since the integration details depend on them.
Compatibility gap review
Swift and S3 APIs do not map one to one. The review lists every Swift feature in use, such as container sync, metadata behavior, object expiration and large-object manifests, and checks each against RGW's supported behavior. Anything without an equivalent becomes a documented decision: change the client, accept the difference, or keep that workload on the old cluster for a defined period.
Copy, verify and cut over
Container and object copy runs under a tested tool and a checksum or count comparison per container. Delivery includes a runbook for the final delta copy, client endpoint changes, DNS or load balancer switches, and a rollback path back to Swift. Agree in writing how long both clusters run together and who signs off each cutover step.
Documentation and ongoing support
At handover you receive the architecture, the authentication mapping, the client endpoint inventory, the verification evidence and the operating runbooks. Ongoing support, upgrades and testing are available as a retainer, which suits Ceph release changes and the decommissioning of the Swift cluster after cutover. DeployOpen prepares these records but does not issue audit reports or certifications.
