Interkey products
Data migration and replication across heterogeneous systems
Iblync is Interkey’s Saudi-built platform for moving data between systems no vendor supplies a path between — and for keeping them in step once the migration is over, so the cutover is not a single irreversible night.
Orientation
Platform characteristics
The whole page in one table, before the detail.
| Product | Iblync, an Interkey product, built in Saudi Arabia |
|---|---|
| Migration | One-time and phased migration between source and target systems, including database modernisation |
| Replication | Continuous real-time replication, including bi-directional synchronisation |
| Flow control | Throttling and resource-consumption control; queueing while a target is unavailable, and processing the queue when it recovers |
| Operation | Low-code migration workflows rather than hand-written per-project transfer scripts |
| Deployment | Cloud or on-premise |
| Commercial model | Quote only: priced per source system, target system and data volume |
Why it exists
Why moving data is the hard part
Every serious platform decision runs into the same obstacle. The database is chosen, the licence agreed, the architecture signed off — and then someone asks how twelve years of production data gets into the new system without losing anything and without taking the business offline.
The reasons are consistent: a migration that silently mangles rows is worse than one that fails loudly; the downtime window a business will grant is a few hours on a weekend, not the days a bulk export wants; and source and target rarely share a data model. Vendor tooling stops at the boundary, which is precisely where a migration happens.
Capabilities
What the platform does
Grouped by the outcome a project is trying to reach. Most engagements use the first two; the third is what separates a migration that survives a working week from one that does not.
| Capability | What it is for |
|---|---|
| Migration | Moving data to a target that was not designed to receive it: database modernisation, platform consolidation, a move to or from cloud. Workflows are configured rather than hand-coded, which makes a second migration cheaper than the first. |
| Replication | Continuous real-time replication, including bi-directional synchronisation where both sides accept writes. That is what supports parallel running: old and new both live, in step, for as long as the cutover plan requires. |
| Flow control | Throttling and resource-consumption control, so replication does not compete with production for capacity. When a target becomes unavailable, changes queue rather than fail. |
| Connectors | A connector set that is actively extended, with custom connectors built for systems it does not yet cover — so an unsupported system is a connector to build, not a reason the project cannot proceed. |
Benchmarks
Product benchmark figures
These are the platform’s own benchmark measurements against defined scenarios — what Iblync has been measured doing, not a service level committed to on your data. Volumes, schema complexity, network path and existing load all move these numbers, so treat them as the starting point for a scoped test against your own systems.
| Scenario | Volume | Benchmark result |
|---|---|---|
| Structured data replication | 100 GB | Under 1 hour |
| Large-scale object storage migration | 1 TB | Under 5 hours |
| Bi-directional sync | 10,000 TPS | Real time |
| NoSQL migration | — | Under 30 minutes |
How a move runs
From the old system to the new one, without the outage
The shape that makes a large migration survivable is not a faster bulk copy. It is running both systems at once, in step, until the business is ready to switch, and keeping the option to switch back.
-
Source system
The production database, still serving the business at full load
-
Initial load
The bulk of the data moved once, throttled so it does not compete with production
-
Continuous replication
Changes since the load applied continuously, with queueing if the target goes away
-
Parallel running
Both systems live and in step, for as long as validation and the business require
-
Cutover
The switch happens on the business’s schedule, with the source still there
The cutover is a decision, not an event you cannot reverse: replication continues while both systems run, so the switch happens when the business is ready rather than when the transfer window ends.
Deployment
Where it runs, and what that decides
Interkey product
Built in Saudi Arabia, delivered and operated by Interkey
Migration and replication
One platform for the move and for what follows it
Cloud or on-premise
Including deployments where data never leaves the environment
Next step
Scope a migration or replication project
Tell us the source and target systems, the data volumes and how much downtime the business will grant, and the reply comes from the team that would run it.