Data platform · Migration tools
Database migration tools: what to check before you choose one
Database migration tools move data from one database to another and many of them keep the two in step until you switch. The tool matters less than whether it fits your source, your target and the downtime your business will grant. This page sets out the criteria a Saudi team can use to judge any data migration tool, then shows where iblync, Interkey's own migration and replication platform, fits and where it does not.
Orientation
At a glance
The whole page in one table, before the detail.
- What a tool must do
- Connect to your source and target, move the history, capture the changes made meanwhile, and prove the result
- Criteria that decide
- Connectors, change data capture, throttling, validation, rollback and where the tool runs
- Where iblync fits
- Moves between different database engines, phased migration, and parallel running before cutover
- Where it does not
- A move between two products of one vendor that supplies a supported native path
- Deployment
- Confirmed per engagement, with whether any data leaves your environment
- Commercial model
- iblync by quotation, priced by source system, target system and data volume
In short, for decision makers
- The real choice: not one product against another, but whether a tool can move your data with the downtime you can accept and show that nothing was lost.
- Six questions settle most of it: does it connect to both systems, does it capture changes while the load runs, can it be throttled, how does it prove the result, how do you go back, and where does it run.
- Our answer for different engines: iblync, Interkey's product, delivered with the team that operates it from Riyadh.
- Our answer for same-vendor moves: use the vendor's supported native path. It is usually cheaper, and we will say so.
What database migration tools do, and what they leave to you
Copying rows between engines is the part of a migration that tooling handles well. A data migration tool earns its place on the harder parts around the copy: reading a source that is still taking transactions, catching up with the changes made during the load, converting data types that two engines treat differently, and showing at the end that the target holds what the source held.
Read more
Some decisions stay with you whatever data migration software you pick: which schemas and history move, what the business accepts as downtime, which checks prove the result, and who calls the cutover or the rollback. Our database migration decision checklist walks through those decisions in order. A tool that is chosen before they are made tends to be chosen for the wrong reasons.
Criteria for choosing a data migration tool
| Criterion | What to ask the supplier | Why it matters |
|---|---|---|
| Connectors | Which of our exact source and target versions are supported today, and what happens for one that is not? | An unsupported system late in a project is a delay or a rewrite |
| Change data capture | Which capture method is used for each source: transaction log, triggers or polling? | The method decides the load on the source and whether deletes are seen |
| Throttling | Can the load and the replication be limited during business hours? | An unthrottled catch-up can slow production at its busiest moment |
| Target outages | What happens to changes if the target stops for a while? | Changes should queue and resume, not be lost or stop the run |
| Validation | How does the tool show the target matches: row counts, checksums, samples? | A migration that mangles rows silently is worse than one that fails loudly |
| Rollback | How do we return to the source if the new system misbehaves after cutover? | Rollback is easy before the first write on the target and hard after it |
| Where it runs | Can it run on-premises or in our own cloud account, and does data leave our environment? | Data residency and security reviews often decide this before price does |
| Operation | Are workflows configured or hand-coded, and can our team read and repeat them? | A second migration should cost less than the first |
Ask every supplier the same eight questions, ourselves included, and ask for the answers in writing against your own systems, not a general product sheet.
Kinds of data migration software and where each fits
| Kind of tool | Good at | Watch for |
|---|---|---|
| The database vendor's native tools | Moves within one vendor's products, with the vendor's support | They usually stop at the vendor's own boundary |
| Open source data migration tools | Schema changes, bulk copies and well-understood one-off moves | Who supports them in production, and who owns the scripts afterwards |
| In-house scripts and ETL jobs | Small, simple transfers your team already understands | Scripts written for one project are rarely reused, and changes made during the load are easy to miss |
| Replication and change data capture platforms | Moves between different engines with the source still live, and parallel running | Licensing, where the platform runs, and the capture method for each source |
| Cloud provider migration services | Moves into that provider's own managed databases | Fit for on-premises targets, and whether data must leave the Kingdom on the way |
There is no single best data migration software. Many projects combine two kinds: a schema tool for the structure, and a replication platform for the data and the changes.
How iblync meets the criteria
iblync is Interkey's platform for data migration and replication between systems that were not designed to exchange data. Against the criteria above:
Read more
- Connectors. iblync's website lists sources including MySQL, PostgreSQL, SQL Server and IBM DB2, and targets including Couchbase and Neo4j. Its connector set is actively extended, and custom connectors are built for systems it does not yet cover.
- Continuous replication. After the initial load, changes are applied continuously, including bi-directional synchronization where both sides accept writes. Our change data capture guide explains the capture methods and what each asks of the source.
- Throttling and queueing. Resource use is limited so replication does not compete with production, and changes queue while a target is unavailable.
- Validation. iblync's own site states that validation uses checksums and row counts, and that an interrupted migration resumes where it stopped.
- Rollback. Source and target run in parallel until the business is ready, so switching back stays possible. The zero downtime migration page sets out each phase.
- Operation. Workflows are configured rather than hand-coded, so your team can see, review and repeat them.
Relatediblyncchange data capture guidezero downtime migration page
Where iblync is not the right tool
If both systems come from the same vendor and that vendor supplies a supported native migration path, use that path. It is usually cheaper and better supported. If the move is a small, one-off copy that can run in a weekend outage, a backup and restore may be all you need. iblync earns its place where no such path exists, where the data models differ enough that transformation is real work, or where two systems must keep running in step instead of being moved once.
How a tool is proven and a migration runs
-
Scope.
Source and target systems and versions, data volume, how much of it changes while the work runs, and the downtime window the business will grant.
-
Prove on your data.
A trial on a representative sample, with the acceptance checks agreed beforehand, including dates, numeric precision and Arabic text.
-
Initial load.
The bulk of the data moves once, throttled so it does not compete with production.
-
Replication and parallel running.
Changes since the load are applied continuously while both systems stay live and validation runs.
-
Cutover and handover.
The switch happens on the business's schedule, with the source still in place until the numbers hold.
Cost, data residency and support for migrations in Saudi Arabia
iblync is an Interkey product, delivered with the team that operates it rather than licensed and left. It has no published price list. The quotation follows three things: the source systems, the target systems and the data volume. The effort around it follows the number of applications that connect to the source, how far the data models differ, and how long parallel running must last. Durations are estimated in scoping, once those drivers are known.
Read more
Where the tool runs is settled before the first record moves. Interkey confirms where iblync runs, and whether data leaves your environment, for each engagement. Where the data includes personal data, Saudi Arabia's Personal Data Protection Law, overseen by the Saudi Data and AI Authority (SDAIA), belongs in the same conversation. Support comes from our engineers in Riyadh, in Arabic or English, and the reply to your enquiry comes from the team that would run the migration. The database migration service page describes the full sequence from assessment to handover.
RelatedSaudi Data and AI Authority (SDAIA)database migration service page
Questions buyers ask
Which database migration tool suits a move between two different database engines?
One that connects to both of your exact versions, captures the changes made while the load runs, and proves the result with counts and checksums. iblync is built for this case. If both engines come from one vendor with a supported native path, that path usually fits better.
Are open source data migration tools enough for an enterprise migration?
They can be, for schema changes and simple one-off copies. The questions are who supports them in production, how they handle changes made during the load, and who maintains the scripts after the project ends.
Can the migration tool run inside our own data centre in Saudi Arabia?
The deployment is confirmed per engagement. For your project, Interkey confirms where it runs and whether any data leaves your environment before work starts.
How is a database migration tool priced for a project in KSA?
iblync is quoted per project against the source systems, the target systems and the data volume in scope. There is no published price list. Send us those three and the downtime window, and we reply with a first scope.
How long does it take to test a migration tool on our own data?
It depends on access to the source, the size of a representative sample and how many acceptance checks you need. We estimate it in scoping, as a range with the reasons behind it, rather than quote a fixed figure here.
How does rollback work once users are already on the new database?
Before cutover, rollback is pointing back at the source. With iblync the source stays in place and replication continues while both systems run, so the way back is planned and rehearsed before the switch, not improvised after it.
Next
Related pages
Next step
Check a migration tool against your own systems
Tell us the source and target systems and versions, the rough data volume and the downtime the business will grant. The reply comes from the team that would run the migration.
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