iblync · Migration
Zero downtime migration: what it means, and how iblync keeps production running
A zero downtime migration moves a database to a new system while the business keeps using the old one. iblync, Interkey's own platform, is built around that pattern: the source keeps serving at full load, data is loaded in a throttled bulk copy, and continuous replication keeps both systems in step until the business is ready to switch. This page says what that removes, and what the final switch can still ask of you.
In short
- The pattern: source and target run in parallel and are kept in step by replication until the business is ready to switch.
- What it avoids: a long outage while a bulk export is copied. The source stays in service during the load and the replication.
- What it does not promise: that no moment of change exists. A final sync and the switch of writes are planned steps, and we agree their window with you.
- Rollback: because the source is still there and replication continues while both run, switching back stays possible.
- How it is bought: by quotation, by source system, target system and data volume.
What "zero downtime" can honestly mean
iblync's website says it can migrate billions of records with zero downtime. Interkey's own migration method is more specific, and it is the one to hold us to. The downtime window a business will grant is usually a few hours at a weekend, not the days a bulk export wants. The aim of the design is that the business does not go offline for the move: the long part of the work, loading history and catching up on changes, happens while production runs.
Read more
What can remain is a short, planned step at the end. In Interkey's cutover sequence, writes are paused or queued in an agreed window while the last changes drain to the target, and then checks run before reads and writes move. Whether your application can avoid even that step depends on the application. We say so in scoping, with a number for the window, instead of promising none.
What stays live in each phase of a migration
| Phase | What happens | What the business sees |
|---|---|---|
| Source in service | The production database keeps serving at full load | No change |
| Initial load | The bulk of the data is moved once, throttled so it does not compete with production | Production runs; extra load is limited by throttling |
| Continuous replication | Changes since the load are applied continuously; changes queue if the target goes away | No change |
| Parallel running | Both systems live and in step for as long as validation and the business require | No change; reads can move first, service by service |
| Final sync and cutover | Writes paused or queued in the agreed window while the last changes drain; validation gates; reads, then writes, switch | A planned window, sized in scoping |
Replication continues while both systems run, so the switch happens when the business is ready, not when a transfer window ends. The source stays in place afterwards until the numbers hold through a real peak.
How you know the data arrived intact
A migration that silently mangles rows is worse than one that fails loudly. iblync's own site states that validation runs during migration, with checksums and row counts. In our cutover sequence the pass conditions are agreed before the night:
- row and document counts;
- checksums on agreed samples;
- application health checks;
- error rates and latencies against thresholds, not impressions.
A named person on your side holds the go or no-go. Calling rollback is defined in advance as the process working, not failing, and the rollback is rehearsed before the real cutover.
What to settle before you plan for zero downtime
- The downtime window the business will actually grant, as opposed to the one in the plan.
- How source and target data models differ, and what has to be transformed between them.
- How much of the data changes while the migration runs.
- What will be accepted as proof that the migration completed correctly.
- Where the platform runs, and whether data may leave your environment. iblync's site says it deploys on any cloud platform or on-premises.
- Whether the vendor already supplies a supported native path between the two systems. If so, it is usually cheaper and better supported.
Our decision checklist goes through these questions in order, and the migration service page describes the full sequence from assessment to handover.
Buying iblync for a migration in Saudi Arabia
iblync is an Interkey product, delivered with the team that operates it. It is priced by quotation: source systems, target systems and data volume. To scope, we need the source and target, a rough volume and the downtime window you can grant. The reply comes from the team that would run the migration, in Arabic or English.
Questions buyers ask
Is a zero downtime migration really possible?
The long part of a migration can run while production stays live. iblync's site states zero downtime. On our side, we plan a short final sync and switch window and agree its length with you, because what your application can tolerate decides 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, kept in step by replication, until the business is ready to switch.
Can we switch back if something goes wrong?
Yes, that is part of the plan. Replication continues while both systems run and the source stays in place, and the rollback is rehearsed before the cutover.
How do you prove nothing was lost?
Validation uses checksums and row counts, and we agree the pass conditions before the cutover. A named person on your side makes the go or no-go call.
When is iblync the wrong choice?
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.
How is it priced?
By quotation, against the source systems, target systems and data volume in scope. There is no published price list.
Next
Related pages
Next step
Plan a migration with production staying up
Tell us the source and target systems, the data volume and the downtime window the business will grant. The reply comes from the team that would run it.
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