Interkey products
Iblync is Interkey’s Saudi-built platform for data migration and replication across heterogeneous data environments. It moves data between systems that were never designed to talk to each other, and it keeps moving it once the migration is over.
Orientation
The whole page in one table, before the detail.
| Product | Iblync, an Interkey product, built in Saudi Arabia |
|---|---|
| Category | Data migration and replication across heterogeneous data environments |
| 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 |
| Connectors | A connector set that is actively extended, with custom connectors developed where a system is not yet covered |
| Typical scenarios | Database modernisation, hybrid and parallel-database running, disaster recovery, backup optimisation |
| Commercial model | Quote only: priced per source system, target system and data volume |
Why it exists
Every serious platform decision eventually runs into the same obstacle. The new database is chosen, the licence is agreed, the architecture is signed off, and then someone asks how twelve years of production data gets from the old system into the new one without losing anything and without taking the business offline to do it. That question is where modernisation programmes stall.
The reasons are consistent. Data integrity is the first: a migration that silently drops or mangles rows is worse than one that fails loudly. Downtime is the second, because the window a business will actually grant is usually a few hours on a weekend, not the days a bulk export and reload wants. Then compatibility, because the source and target rarely share a data model, and the transformation between them is where the real work sits. Vendor tooling tends to cover the vendor’s own products and stop at the boundary, which is precisely where a migration happens. And the cost of doing it by hand, in bespoke scripts written for one project and thrown away afterwards, is what makes organisations postpone the modernisation entirely.
Iblync exists for that gap: heterogeneous environments, where the source and the target are different products from different vendors and no one supplies a supported path between them.
Capabilities
Grouped by the outcome a project is trying to reach, rather than by feature. Most engagements use the first two; the third is what makes the difference between a migration that survives a working week and one that does not.
Moving data from a source system to a target that was not designed to receive it: database modernisation, platform consolidation, a move to or from cloud. Migration workflows are configured rather than hand-coded, which is what makes a second migration cheaper than the first instead of another bespoke project.
Continuous real-time replication between systems, including bi-directional synchronisation where both sides accept writes. This is what supports hybrid and parallel-database running: the old system and the new one both live, in step, for as long as the cutover plan requires.
Throttling and resource-consumption control, so replication does not compete with production for the same capacity. When a target becomes unavailable, changes queue rather than fail, and the queue is processed when it recovers. Volume in transit adjusts as conditions change instead of holding one fixed rate.
A connector set that is actively extended, with custom connectors developed for systems it does not yet cover. That is the honest form of the claim: not that every database is supported, but that a system outside the current set is a connector to build rather than a reason the project cannot proceed.
Benchmarks
These are the platform’s own benchmark measurements against defined scenarios. They describe what Iblync has been measured doing, not a service level it is being committed to on your data: volumes, schema complexity, network path and the load the source and target are already carrying all move these numbers. Treat them as the starting point for a scoped test against your own systems, which is what Interkey would propose before any commitment.
| 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
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.
Where it is used
Migration is the entry point; most of these keep running long after it.
Moving off a system that is expensive, unsupported or no longer fits the workload, onto one that does, without a big-bang cutover. The parallel-running period is what makes the decision reversible, which is usually what makes it approvable.
Continuous replication to a second environment, so recovery is a matter of pointing at a system that is already current rather than restoring a backup and discovering how old it was. Queueing on the target side means a network interruption does not turn into a gap in the copy.
Two systems that both have to be right at once: an old application still in service alongside a new one, or on-premise alongside cloud during a phased move. Bi-directional sync is what makes that period workable rather than a freeze.
Where a backup strategy has become the thing that dictates the maintenance window, replication changes what has to be copied and when, which is often cheaper than buying a faster backup target.
Deployment
Iblync deploys in cloud or on-premise, and for most Saudi organisations that is a data question before it is an architecture question. Data in transit between a production system and its replica is the same data, under the same rules, and a migration tool that requires it to leave the country or leave the site is a tool that does not get approved. On-premise deployment keeps the whole path inside the environment that already holds the data.
Operationally the platform is designed to be run through configured workflows rather than code, which matters more than it sounds: it means the migration is something the organisation’s own database team can see, review and repeat, rather than a script that only its author understands. Interkey delivers and operates it either way, and the migration guide sets out how a project of this kind is actually run, phase by phase.
Why Interkey
Iblync is Interkey’s own product, built in Saudi Arabia. For a migration that matters, that changes the two things a customer usually cannot get: a connector for an unusual source system is a development request rather than a support ticket to another timezone, and the people who built the platform are reachable during the cutover weekend.
The product also sits inside a practice rather than on its own. Interkey runs the data platform work around it, including the Couchbase implementations that are often the target of one of these moves, and the application-side engineering that decides whether a modernisation actually finishes: a database migration usually arrives attached to an application that has to be changed with it.
From the insights library
The phases, the validation discipline and the failure modes of a real migration programme.
PracticeWhere migration, replication and the platforms on either side of them sit together.
PartnerFrequently the target of one of these moves, with an honest table of when it is the wrong answer.
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
In Saudi enterprise technology since 1999
CR 1010156897
Next step
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.
Or directly
+966-11-2180999 info@interkey.com.saTawuniya Towers, North Tower, 7th Floor, King Fahad Highway, Olaya, P.O. Box 56835, Riyadh 11564, Saudi Arabia
Elsewhere