Ceph migration from SAN, NAS or cloud storage

What a Ceph migration involves

A Ceph migration moves data and running workloads from an existing SAN, NAS, VMware datastore or cloud object store onto a Ceph cluster, and each source needs its own mapping. Block LUNs and VMware datastores usually land on RADOS Block Device (RBD) images, shared file systems on CephFS, and objects from S3 buckets or other object stores on the Ceph Object Gateway (RGW). The work is less about copying bytes than about deciding which pool, access method and authentication model each workload gets, and then proving the copied data behaves the same on the other side.

The triggers are usually operational or commercial. Common ones include hardware support ending on an array, capacity growth that outpaces what the current system can add, and a decision to leave a cloud provider for data residency or cost reasons. Each trigger sets a deadline, and that deadline shapes the copy method, the acceptable downtime and how many staged cutovers the team can absorb.

Teams with strong storage and hypervisor skills can often handle small, low-risk moves in-house, such as a few volumes with a known application owner and a generous outage window. A partner is more often used when volumes are large, cutover windows are tight, or the source platform uses mappings the team has not built before. Confirm with your own staff which of these conditions apply before deciding.

What the work includes

The migration runs as a sequence of gated steps, each with a written output the client keeps. The cluster design itself is covered on the Ceph implementation page, so these cards start from a cluster that already exists.

Source inventory and dependency mapping

We catalog every LUN, NFS export, SMB share, VMware datastore and cloud bucket in scope, with capacity, growth, client hosts and change windows. Dependencies such as backup jobs, replication links, fstab entries and application connection strings are mapped, because these are what break at cutover. Confirm early which systems can tolerate a read-only window.

Mapping each source to RBD, CephFS or RGW

Each source is assigned a target interface: RBD for block volumes used by hypervisors or databases, CephFS for shared POSIX file access, and RGW for S3-compatible object data. The mapping records the target pool, access model and any ownership or permission translation. Confirm that every client platform supports the chosen protocol at the version you run.

Copy method and tooling choice

The copy method depends on the source type, data change rate and acceptable downtime. Block devices may need a different approach from file trees, and cloud object data needs a separate transfer path. The tooling decision is recorded with its known limits on sparse files, ACLs, extended attributes and checksum verification, so the team can judge what the copy preserves.

Pilot and bulk copy with delta passes

A pilot copy of representative datasets tests throughput, permissions and application behavior before the full run. Bulk copy is followed by repeated delta passes that carry over changes made while the source stays live, so the final window only covers the remaining difference. Track how long each delta pass takes; a pass that no longer shrinks signals that cutover needs a planned freeze.

Validation of copied data

Validation compares object counts, sizes, checksums on a sampled or full basis, and application-level checks such as database consistency or mount behavior. Results are written into a validation report with the criteria agreed in advance. Confirm who signs off each dataset before cutover begins.

Staged cutover and rollback planning

Cutover moves workloads in ordered stages, starting with lower-risk datasets, so each group can be verified before the next. Each stage has a rollback path that states how to reattach the source, what data written after cutover would be lost or need reconciling, and who makes the decision. Rollback steps are rehearsed where the source is still available.

Handover documentation and operator training

The client receives the copy runbook, the cutover and rollback plans, and a record of every decision made during mapping. Operators are trained on the cluster tools used during migration, including health checks, pool and client access and recovery steps. Ask how training is delivered and whether it covers your own staff on the new platform, not only the implementers.

What drives cost and duration

The table lists the factors that most change the effort and calendar time of a move from SAN, NAS or cloud storage to Ceph, why each one matters and how to keep it under control.

Driver	Why it changes cost or effort	How to keep it down
Data volume and daily change rate	Total bytes set the copy time, and a high daily change rate means more delta syncs before cutover can happen. Both drive the number of copy passes and the cutover window.	Measure used capacity and write rates per volume before scoping. Cut data you do not need to move, and archive cold datasets separately.
Number of workloads and mapping complexity	Each LUN, share, datastore or bucket needs a target decision (RBD, CephFS or RGW), a pool and an access model. Shared or interdependent workloads multiply the planning.	Group workloads by target type and dependency. Start with a small, low-risk set to prove the mapping before moving the rest.
Client and hypervisor count	Every host or hypervisor that mounts the old storage needs reconfiguration, driver checks and testing, and some must be patched or upgraded first.	Inventory clients with their OS, kernel, hypervisor version and mount method. Standardize client versions before the move where possible.
Cutover window tolerance	A short allowed outage forces tighter delta syncs, more rehearsals and more rollback preparation. A tolerant window allows a simpler single-pass copy.	Agree the acceptable downtime per workload in writing. Group workloads into waves by how much outage each can take.
Network path and throughput between old and new storage	Copy speed depends on the bandwidth and latency between source and Ceph nodes. Routed paths, shared uplinks or firewalls can slow copies and extend the window.	Map the copy path end to end and test sustained throughput before scheduling. Use a dedicated migration network where the design allows it.
File semantics such as ACLs and locking	NAS data carries POSIX or SMB permissions, extended attributes, and lock behavior that may need translation or validation on CephFS. Mismatches cause subtle access errors.	Inventory ACL and locking use per share. Test representative applications on CephFS before cutover and document any behavior that changes.
Object features such as versioning and metadata	Cloud buckets may use versioning, object locks, lifecycle rules, custom metadata or tags. Each one needs an RGW equivalent or a documented gap, and tooling must match the API calls used.	List the S3 features and API calls each application uses. Confirm RGW support for each feature in the release you plan to run before committing to a design.
Integrations and backup tooling	Backup jobs, snapshot schedules, monitoring, identity and automation must point at Ceph and be retested. Old backup catalogs may reference the previous storage.	Inventory every tool that touches the storage. Plan repointing and restore tests as part of each wave, not as a final step.
Number of environments	Each environment (for example development, test and production) repeats the copy, validation and cutover work, and drift between them adds rework.	Use the same runbooks and automation in every environment. Migrate non-production first to refine the process.
Compliance evidence needed	Auditors may expect records of data integrity checks, access changes, change approvals and restore tests. Collecting this evidence adds documentation and review effort.	Agree the evidence list with your assessor early. Capture checksums, logs and sign-offs as part of the runbook rather than reconstructing them later.

Migration phases and outputs

The sequence moves workloads onto Ceph in controlled stages, so each phase ends with a documented result that the next phase depends on.

Inventory sources and workloads
We catalog the SAN LUNs, NAS shares, VMware datastores or cloud buckets in scope, with their owners, access patterns, capacity, and dependencies on hosts and applications. The output is a migration inventory that the client signs off as complete for the agreed scope.
Map each workload to a Ceph interface
For every workload we decide whether it moves to RBD block devices, CephFS, or RGW object storage, and record the pool, replication or erasure-coding choice, and any client changes required. The output is a per-workload mapping decision record that the client approves before build work begins.
Check network and target readiness
We verify that the Ceph cluster, its network paths, client hosts, and authentication are ready to receive data, including throughput tests and the bonded link design. The output is a readiness report with open items, and migration does not start until the blocking items are closed.
Run a pilot on a non-critical workload
We move one low-risk workload end to end, including client remapping, application testing, and rollback, to prove the copy method and runbook. The output is a pilot report listing measured results, defects found, and runbook changes made before bulk work.
Copy in bulk with repeated delta passes
We perform the initial full copy, then run repeated delta passes that capture changes made on the source, so the remaining difference shrinks before cutover. The output is a copy log per workload showing the last delta pass, which sets the window for the cutover.
Validate against agreed checks
We compare each migrated dataset with the source using the checks agreed in the scope, such as object counts, checksums, permissions, and application-level tests. The output is a signed validation record per workload, and a workload is not cut over until its record is complete.
Cut over in stages and observe
We switch production workloads group by group, keep the source available for rollback, then monitor cluster health and application behavior for an observation period agreed in advance. The output is a cutover record, and decommissioning of the old storage starts only after the client accepts the observation results in writing. Ask for the timeline in the written scope.

What teams keep in-house and what they outsource

This table splits a SAN, NAS or cloud-storage move to Ceph into its working parts and shows who usually keeps each part, what a partner typically takes over, and which skills it needs, with application owner sign-off kept in-house throughout.

Migration part	Usually kept in-house	Typically taken over by a partner	Skills required
Source inventory	Storage team confirms which LUNs, NAS shares, VMware datastores or buckets are in scope and who owns each	Discovery scripts, capacity and I/O profiling, dependency mapping, and a written inventory of volumes, sizes and change rates	Storage, hypervisor, application
Application owner testing	Application owners define test cases, run them in non-production and give sign-off	Test environment setup, test data copies, and tracking of defects found during dry runs	Application, storage
Mapping decisions	Architecture owners approve whether each workload maps to RBD, CephFS or RGW	Mapping options per workload, pool and device class proposals, and trade-off notes for each choice	Storage, application, security
Network and hardware checks	Network team approves VLANs, bonded links and switch changes	Review of MTU, bandwidth, latency tests and the hardware recommendations against the planned OSD and journal layout	Network, storage
Copy execution	Operations approves change windows and the copy method chosen	Scripting and running rbd export or import, rsync, or S3 copy jobs, with throughput logging and retries	Storage, hypervisor
Validation	Application owners confirm data and behavior match what they expect	Checksum or manifest comparison, object counts, permission checks and performance baselines	Storage, application
Cutover	Change board approves the cutover and the application owner confirms go-live	Staged cutover runbook, DNS or mount changes, and on-call support during the window	Storage, hypervisor, network, application
Rollback	Application owner decides when to roll back and accepts the data state	Documented rollback steps, retained source copies and tested reversal procedure	Storage, hypervisor, security
Decommissioning	Data owner approves retirement of SAN, NAS or cloud copies and any retention needs	Secure erase or deletion procedure, licence and contract wind-down support, and evidence of removal	Storage, security
Operating the new cluster	Internal platform team takes ownership of daily operations, capacity and upgrades	Initial runbooks, monitoring setup, knowledge transfer and optional retainer support	Storage, network, security

What goes wrong and how to prevent it

Most storage moves from SAN, NAS or cloud object storage to Ceph fail in predictable places. Each card below names a risk and a check to run before cutover.

Metadata lost in translation

Permissions, ACL entries, file locks, timestamps, S3 object versions, tags and user metadata do not map one-to-one onto RBD, CephFS or RGW. Build a per-dataset mapping table before the copy starts, then check sample files and objects on the target for owner, mode, timestamps, versioning state and tags.

Single copy pass and throughput gaps

A single copy taken from live data is stale before it finishes, so the cutover window grows with every write made during the run. Plan an initial bulk copy, then incremental passes, and agree a short final freeze. Measure sustained throughput between source and target, not link speed alone, and throttle copy jobs so production latency stays within agreed limits.

Sizing from source capacity alone

Source capacity is usable space, while Ceph consumes raw capacity. Replicated pools multiply each object, erasure coding adds parity overhead, and free space is needed for recovery after a failed host or drive. Size the target from usable capacity after this overhead, and ask for the arithmetic in writing.

Client and hypervisor version mismatch

Kernel RBD clients, CephFS mounts, hypervisor drivers and S3 SDKs each support a range of Ceph releases, and a client outside that range can fail or lose features after cutover. Inventory every client and hypervisor version, check it against the release notes for the target, and test one workload per client type before moving production.

Untested restores and cutover rollback

A copy that has never been restored is an unverified backup, and a cutover without a tested return path leaves no safe option when validation fails. Restore sample volumes, filesystems and buckets to a scratch area, compare checksums, and rehearse the rollback, including how writes made on Ceph would return to the source.

Target release near end of life

The Ceph releases page lists Squid's estimated end of life as October 31, 2026, and Tentacle's as June 1, 2027, so a cluster built on Squid today could need an upgrade soon after go-live. Choose the newest maintained release your clients support, confirm end-of-life dates at build time, and schedule the upgrade path before cutover.

How the work changes by starting point

SAN block LUNs usually map to RBD images, which keeps the block semantics your hosts expect. The plan turns on how the LUNs are presented today and whether consumers can tolerate a short cutover.

Mapping choice: Each LUN becomes an RBD image in a replicated or erasure-coded pool, chosen with the workload's write pattern in mind. Confirm the host OS and multipath driver support before you commit.
Copy approach: Common options are host-side block copy, or a snapshot-based incremental sync where the platform supports it. Confirm what your current array and hosts can do.
Validation focus: Compare device sizes, partition tables, file system checks and application-level data checks, not just byte counts.
Main pitfall: Teams underestimate the number of hosts, multipath configurations and boot-from-SAN dependencies that must be re-pointed in the same window.
Illustrative example: A database host with three LUNs may need all three copied to a consistent point in time, so the cutover order matters.

What you need to provide

Gaps in client inputs are a common cause of schedule changes in a storage migration, so the prerequisites below should be settled before the migration plan is fixed. The written scope lists exactly what the client must provide, and it is the reference point if a delay is later traced to a missing input. Source access and inventory. The team needs read access to the SAN arrays, NAS filers, VMware datastores or cloud buckets being moved, along with their configuration exports: LUN and volume maps, export and share definitions, bucket policies and lifecycle rules. An accurate workload list with named owners, mapped to the volumes or buckets each one uses, is what turns a storage inventory into a cutover plan.

Network paths, change windows and target decisions. Confirm the network routes between source and Ceph hosts, the bandwidth available during copy, and the change windows in which each workload can stop or switch. On the Ceph side, the client must decide the target release (the Squid and Tentacle release notes and their end-of-life dates should be checked at decision time), and the pool and bucket layout: which data goes to RBD, CephFS or RGW, and which failure domains and replication settings apply. Classification, retention and testing owners. Data classification and retention requirements determine what can be copied, what must be encrypted, and what must be deleted at the source after cutover. Each application needs a named owner who can run functional tests and sign off a migrated workload. Finally, agree rollback criteria in writing before cutover: the conditions that trigger a return to the source, and how long the source remains intact.

Frequently asked questions

What drives the cost of a Ceph migration from SAN or NAS?

The main drivers are the volume of data, the number of workloads, and how each one maps to RBD block, CephFS file or RGW object storage. Cost also rises with the amount of change that must be absorbed during cutover, the validation you require, and how many cutover windows your change process allows. Who pays for what: DeployOpen plans, scopes and implements the migration in your environment, while your team provides access, application owners and change approvals. The migration effort is one-time. Ongoing support is a separate, recurring agreement. Ask for a fixed-scope quote with written deliverables and assumptions.

How long does a migration onto Ceph take?

The timeline is set by the amount of data to copy, the bandwidth between the old platform and the new cluster, the number of workloads and their dependencies, and the validation effort each one needs. The number of cutover windows your change calendar allows also matters. Engagements are fixed-scope, so the schedule is agreed in writing before work starts and should be broken into phases with named milestones. Ask for that phase plan in the written scope rather than a single end date.

Can our own team run a Ceph migration without outside help?

A capable team can, provided it already operates Ceph in production and has moved data at comparable volume. The hard parts are usually the mapping decisions for each workload, copy-tool selection, validation criteria, and rehearsing cutover and rollback. Ask yourself whether those skills and the time for them are already available. An outside partner can take on some or all of that work under a written scope, and your team can keep ownership of the parts it prefers to run.

Does the migration need downtime, and can the old storage stay online?

In most staged plans, the source stays online while the bulk copy runs, so applications keep working. Changes made after the copy are captured in one or more incremental passes. Each workload then needs a short final window for the last sync and reconnection. The length of that window depends on the change rate and how the application handles reconnection. The old storage remains the system of record until acceptance. Confirm the copy method supports incremental sync for your source type.

Does Ceph keep file permissions and object metadata after migration?

It depends on the source and the copy method. Ownership and mode bits can usually be carried into CephFS, while access control lists, NFSv4-style permissions and vendor-specific attributes may need translation or may not transfer. For object data, standard HTTP and S3 headers map to RGW, but custom metadata and tags need checking. Confirm this during a pilot using a representative sample of files and objects, and compare results against written acceptance criteria before the production copy begins.

What happens if a cutover fails partway through?

The plan should define the rollback path before the window opens. Typically that means the source stays intact until acceptance, the cutover steps are rehearsed, and the criteria for stopping and reverting are written down. Failures are usually handled per workload, so one application can roll back without affecting others. Ask for the rollback procedure, the decision owner, and the rehearsal results as part of the written scope. DeployOpen does not guarantee a cutover outcome, but it plans for recovery.

How DeployOpen scopes, delivers and hands over

DeployOpen plans, builds and hands over Ceph migrations inside infrastructure you control, moving data from SAN, NAS, VMware datastores or cloud object storage onto the Ceph interfaces that fit each workload. Work is agreed in a written, fixed-scope plan before any data moves.

How we scope

Inventory source volumes, file shares, VMware datastores and buckets, with sizes, change rates and the applications that depend on them.
Map each workload to RBD, CephFS or RGW, and record the access model, identity source and client protocol it needs.
Agree in writing the migration waves, cutover windows, rollback criteria and the systems in and out of scope.

How we build

Confirm the cluster design first, including dedicated drives per OSD, WAL and DB placement on shared SSDs for HDD-based OSDs, and bonded network links across two switches.
Choose copy methods per workload, such as block-level copy for RBD targets and file-level sync for CephFS, and test them on a non-production copy.
Validate each wave with checksum or record-count comparisons, application test scripts and agreed performance baselines before the staged cutover.

How we hand over

Document the final cluster layout, pool and device class design, cephadm service placement and the migration runbook as delivered.
Walk your operators through health checks, alert meanings, rollback steps and how to add capacity to the cluster.
Hand over validation evidence for each migrated workload, with a list of open items and the owner for each one.

How we support

Agree whether post-cutover support is a separate retainer, covering monitoring review, patching and upgrades on a maintained Ceph release.
Ask for a quote that lists the scope, deliverables, assumptions and any items you must provide, such as network access and maintenance windows.
Confirm with the vendor and your own environment which Ceph release, licensing and support terms apply before the build starts.