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 | Confirmed per engagement; see the deployment questions below |
| Commercial model | Quote only: priced per source system, target system and data volume |
In short
What Iblync is, and who it is for
Iblync is Interkey’s Saudi-built platform for data migration and replication between systems that were not designed to exchange data, and for keeping them in step afterwards. It covers one-time and phased migration, continuous real-time replication including bi-directional synchronisation, and the flow control that decides whether either survives contact with a production workload.
It is for the people who own that data: database and platform architects, data engineering teams, and the technology leaders signing off a modernisation against a fixed cutover date. The product is delivered with the team that operates it rather than licensed and left.
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. |
Throughput
What decides throughput on your estate
Iblync is used for four recognisable shapes of work. How fast each one runs is decided by the estate it runs on, not by the tool, so this page publishes no throughput figure: the number that would matter is the one measured on your systems during scoping, and any other number is someone else’s hardware.
| Scenario | What moves the result |
|---|---|
| Structured data replication | Row volume and how much of it changes while the migration runs, index and constraint work on the target, and how much bandwidth the replication is allowed to take from production. |
| Large-scale object storage migration | Object count rather than total size — a million small objects is a different problem from a few large ones — plus the network path between source and target and any egress limits on it. |
| Bi-directional sync | Transaction rate, and the conflict rules: when both sides accept writes, what happens to a record changed in both places is a design decision before it is a performance one. |
| NoSQL migration | How far the source and target data models diverge, and therefore how much transformation sits between them. A document store that maps cleanly is a different job from one that has to be remodelled. |
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
It is run through configured workflows rather than code, so the migration is something your own database team can see, review and repeat. The migration guide sets out how a project of this kind runs, phase by phase. When this is the wrong fit: a move between two products from the same vendor usually has a supported native path, and that path will be cheaper.
Evaluation
What an evaluation conversation covers
Iblync is quoted rather than listed, priced against the source systems, the target systems and the data volume. Everything below moves that shape, so a first conversation is mostly these questions — and most of them can be answered before it.
- Which source and target systems are in scope, and whether the vendor already supplies a supported path between them
- Whether this is a one-time move, a phased migration, or continuous replication that outlives the project
- The data volume, and how much of it changes while the migration is running
- The downtime window the business will actually grant, as opposed to the one in the plan
- How the source and target data models differ, and what has to be transformed between them
- What will be accepted as proof that the migration completed correctly
- Where the platform runs, and whether data may leave the environment at any point
Buyer questions
What buyers ask us
Direct answers to the questions that come up in real evaluations. Anything missing, ask us at the bottom of the page.
What kinds of migration is Iblync built for?
Moves between systems that were not designed to exchange data — a database modernisation onto a different engine, a move between heterogeneous platforms, or a consolidation where several sources land in one target. It also covers the case that is not a migration at all: continuous replication between systems that both stay in production, including bi-directional synchronisation.
The platforms on either side of the move are a separate question from the move itself. Where the destination happens to be one Interkey also implements — Couchbase, for instance — the same team can carry both, but Iblync does not assume it and does not require it.
Does the business have to go offline during the migration?
The pattern Iblync is built around is designed to avoid that. Source and target run in parallel and are kept in step by replication until the business is ready to switch, so the cutover becomes a decision rather than a single irreversible night, and switching back stays possible. How long parallel running continues, and what triggers cutover, are settled during scoping rather than assumed.
When is Iblync the wrong tool?
When both systems come from the same vendor and that vendor supplies a supported native migration path, that path is usually cheaper and better supported — use it. Iblync earns its place where no such path exists, where the data models differ enough that transformation is real work, or where the two systems have to keep running in step rather than being moved once.
How is Iblync priced?
By quotation, against the source systems, the target systems and the data volume in scope. There is no published price list, because those three variables move the answer too far for one to be meaningful. Scoping the systems and the volume is what produces a number.
What do you need from us to scope a migration?
The source and target systems, a rough data volume, and the downtime window the business will grant. That is enough for a first useful conversation. Schema differences, acceptance criteria and the deployment questions follow, and the migration guide sets out how a project of this kind runs phase by phase if you would rather read before asking.
Read next
Explore related solutions
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.
-
Interkey product
Built in Saudi Arabia, delivered and operated by Interkey
-
Migration and replication
One platform for the move and for what follows it
-
Data-boundary questions settled first
Where the platform runs, and whether data leaves the environment