iblync · Object storage migration
Object storage migration: moving buckets and archives without losing a file
Object storage migration moves files, and the metadata and permissions that come with them, from one storage platform to another: from a data centre into cloud object storage, between cloud providers, or into a region inside the Kingdom. The bytes are the easy part. What decides the project is how many objects there are, the network path between the two sides, and proof that nothing was left behind. iblync, Interkey's own migration and replication platform, is used for large-scale object storage migration, and Interkey runs it with you from Riyadh.
Orientation
At a glance
The whole page in one table, before the detail.
- What moves
- Objects in buckets or containers, with their metadata, permissions and, where needed, earlier versions
- Typical moves
- File shares and archives into cloud object storage, between cloud providers, or into an in-Kingdom region
- What decides duration
- Object count rather than total size, the network path between source and target, and any egress limits on it
- How iblync helps
- A throttled bulk copy, then passes for changed objects, with queueing while a target is away and checks against the source
- Deployment
- Confirmed per engagement: where iblync runs and whether data leaves your environment
- Commercial model
- By quotation, priced by source system, target system and data volume
In short, for decision makers
- What it is: moving years of files and backups to new storage while applications keep working.
- What decides the plan: object count, the network and any egress charges, measured on your estate before a date is set.
- What you get at the end: a written check that every object arrived intact, before the old copy is retired.
- Who delivers it: Interkey, with the team that operates iblync, supported from Riyadh in Arabic or English.
What object storage migration involves, and why it is harder than a copy
Object storage keeps data as objects: a file, a key that names it, and metadata such as content type, owner tags and retention settings. Objects sit in buckets (on some platforms, containers), with access set per bucket or per object. An S3 migration, a blob storage migration and a move off an on-premises file store all share the same core: every object must arrive with the right name, content and settings, and the applications that read them must find them in the new place.
Read more
Three things make it harder than a copy. Large estates hold millions of small objects, and each is listed, copied and checked on its own. Data keeps changing while the move runs. And some settings, such as permissions, versions and retention locks, do not map one to one between platforms, so they must be decided, not assumed.
iblync was built for moves between systems that were not designed to exchange data, and large-scale object storage migration is one of the four kinds of work it is used for.
Relatediblync
What decides how long an object storage migration takes
| Factor | Why it matters | What we measure in scoping |
|---|---|---|
| Object count | Each object is listed, copied and checked on its own; a million small objects is a different problem from a few large ones | Objects per bucket and the size mix |
| Network path | The link between source and target, and what else shares it, sets the ceiling | Usable bandwidth at business hours and off hours |
| Egress limits and charges | Some providers limit or charge for data leaving their platform | The source provider's limits and the estimated charge |
| Change during the move | Objects written or deleted after the first copy need further passes | Daily new, changed and deleted objects |
| Metadata, permissions and versions | Settings that do not map one to one need a rule before the move | Which settings must survive, and their target equivalent |
| Production load | A copy that competes with users slows the business | The share of capacity the copy may take, and when |
This is why our iblync page publishes no throughput figure: the number that matters is the one measured on your systems during scoping.
S3 migration, blob storage migration and large file migration: the common cases
Most requests in Saudi Arabia take one of four shapes:
- From the data centre to the cloud. File shares, scanned documents and backup archives move into cloud object storage, often as part of a wider cloud migration.
- Between cloud providers. Buckets move for cost, consolidation or data residency. S3 migration usually means a move to or from Amazon S3 or storage that speaks the S3 interface.
- Into a region inside the Kingdom. Data held abroad moves to an in-Kingdom region, such as Google Cloud's region in Dammam, where policy requires it.
- Large file migration. Video and engineering files are few but large, so the network path decides the plan.
iblync's website lists Amazon S3 among the systems it connects to. For other storage platforms, its site says custom connectors are built for systems it does not yet cover; your source and target are settled in scoping.
Relatedcloud migration
How iblync runs an object storage migration
As with databases: move the bulk once, keep the target in step, then switch when the business is ready.
- Inventory. Buckets, object counts, sizes and settings are listed first.
- Throttled bulk copy. The bulk of the objects moves once, throttled so it does not compete with production.
- Passes for changes. New, changed and deleted objects follow in further passes until cutover.
- Queueing and resume. If the target is away, work queues instead of failing; iblync's own site states that an interrupted migration can resume where it stopped.
- Checks against the source. iblync's own site states that validation uses checksums and counts. We agree which checks prove the move complete.
- Configured workflows. Mappings and rules are configured, not hand-coded, so your team can review them.
For keeping two systems in step longer, see our page on real time replication with iblync.
The cutover: applications, links and the old copy
Moving the objects is half the work. The applications and integrations that read them must point to the new location, and links stored in databases or documents may hold the old path. We list them in scoping and plan their switch.
Keep the source unchanged until the checks pass and the business has worked on the target for an agreed period, then retire it. A replica is not a backup: it copies a deletion as faithfully as good data. If the move is also the start of cloud backup, our cloud backup page covers immutable copies and restore tests.
Relatedcloud backup
How an object storage migration project runs
-
Scope.
Source and target platforms, buckets, object counts and sizes, rate of change, network path, egress terms and the applications that read the data.
-
Rules.
Naming, permissions, metadata, versions and retention mapped between platforms, and the checks that prove the move complete.
-
Bulk copy.
The bulk of the objects moves once, throttled to the limits agreed.
-
Change passes and checks.
New and changed objects carried across; counts and checksums compared with the source.
-
Cutover and retirement.
Applications switch to the target; the old copy is retired once the agreed conditions hold.
What Interkey delivers: cost, data residency and support in Saudi Arabia
iblync is an Interkey product, delivered with the team that operates it rather than licensed and left. We deliver the inventory, the mapping rules, the copy and change passes, monitoring, the checks you accept and the cutover plan. The same engineers support it from Riyadh, in Arabic or English.
When it is the wrong fit: a move between two buckets of the same provider usually has that provider's own supported transfer path, which is cheaper, and we will say so.
Read more
There is no published price list. The quotation follows the source system, the target system and the data volume; egress charges, where the source provider applies them, are billed by that provider and estimated in scoping. Durations are estimated as a range once object count and network path are measured.
Interkey confirms where iblync runs, and whether data leaves your environment, before the first object moves. Where the files hold personal data, Saudi Arabia's Personal Data Protection Law, overseen by the Saudi Data and AI Authority (SDAIA), belongs in the same conversation. Our guide to data residency in Saudi Arabia covers choosing the target location.
RelatedSaudi Data and AI Authority (SDAIA)data residency in Saudi Arabia
Questions buyers ask
Can we move our files and archives to object storage inside Saudi Arabia?
Yes, where the target platform offers an in-Kingdom region, such as Google Cloud's region in Dammam, or to storage in your own data centre. Your classification policy decides which locations each class of data may use.
How long does it take to migrate millions of files to new object storage?
It depends on object count more than total size, on the network path and on how much changes during the move. We measure those in scoping and give the duration as a range, with the reasons, rather than a single date.
Who pays the egress charges when buckets leave our current cloud provider?
Where the source provider charges for data leaving its platform, it bills that charge to your account under your agreement with it. We estimate it in scoping so it is in the budget before the move starts.
How is an object storage migration priced in KSA?
By quotation, against the source system, the target system and the data volume. Object count, settings to map and applications to switch shape the effort.
Can our applications keep reading files while the objects are moving?
Yes. The source stays in service during the bulk copy and the change passes, and applications switch to the target at cutover, one group at a time where possible. The source is kept unchanged until the checks pass.
Do object permissions, metadata and versions survive the move?
Those that have an equivalent on the target do, once mapped. Those that do not map one to one, such as some access rules or retention locks, get a written rule in scoping, and the checks confirm the result.
Next
Related pages
Next step
Plan your object storage migration
Tell us the source and target, the rough number of objects and total size, and whether the data must stay in the Kingdom. The reply comes from the team that would run the move.
Or directly
+966-11-2180999 [email protected]Tawuniya Towers, North Tower, 7th Floor, King Fahad Highway, Olaya, P.O. Box 56835, Riyadh 11564, Saudi Arabia