Data platform · Database transfer
Database transfer: moving a live database to a new server while the business keeps running
A database transfer moves a production database from the server it runs on today to new hardware, a new data centre or a cloud, and ends with applications pointing at the new copy. The copy is rarely the hard part. The hard part is that the database keeps changing while it moves. This guide compares the ways to transfer a database, shows when continuous sync is worth it, and explains where iblync, Interkey's own migration and replication platform, fits.
Published 9 min read
Orientation
At a glance
The whole page in one table, before the detail.
- What it is
- Moving the same database to a new server, data centre or cloud, then switching applications to it
- Typical triggers
- Hardware end of life, a data-centre exit, a move into a cloud region, a version upgrade
- The main choice
- A single outage window, or continuous sync with the old server live until the switch
- What decides it
- Database size, how much data changes each hour, and the downtime the business accepts
- How long it takes
- Estimated per project, from volume, change rate, network path and rehearsals
- Where iblync fits
- Continuous sync between old and new servers, especially across engines or versions
The problem in plain words
- The situation: the server, the data centre or the hosting contract is ending, and the database on it is in daily use.
- Why it is hard: while the data is copied, users keep changing it. A copy taken on Thursday is out of date by Sunday.
- The two honest options: stop the business for a window long enough to copy and check everything, or keep old and new in sync and switch in a short window.
- The real risk: not the copy, but an unrehearsed switch and no way back.
What a database transfer is, and what it is not
In a database transfer the database stays the same database: the engine, the schema and the applications usually do not change; only its home does. Typical reasons are a server at the end of its support life, a data-centre exit with a fixed date, a change of hosting, or a move into a cloud region. An engine version upgrade is often folded in.
Read more
That makes it narrower than a full database migration, where the engine or data model changes and mapping and application work follow. When the destination is a managed cloud database, our cloud database migration guide covers region and service. This guide covers what every move shares: transferring data while it changes, proving it arrived, and switching without betting the business on one night.
Three numbers decide almost everything that follows:
- Size: how much data has to move in total.
- Change rate: how much of it is written or updated each hour, at peak, not on average.
- Downtime budget: how long the business will accept the database being unavailable for the switch.
Why moving a database to a new server needs extra care in Saudi Arabia
For organisations in the Kingdom, a transfer is also a question of where the data is while it moves. The new server, a staging copy, a backup file crossing the network and the transfer tool's logs each hold data, and each has a location. If the database holds personal or classified data, each location should be allowed for its class before the first copy, not after.
Read more
The rules include the Personal Data Protection Law, overseen by the Saudi Data and Artificial Intelligence Authority (SDAIA), and the controls of the National Cybersecurity Authority (NCA), alongside your sector regulator's. Which apply depends on your sector and data, so read the authorities' own texts with your compliance owner. The plan should name every place a copy will sit, who can reach it, and when it is removed.
The second factor is the calendar. Downtime windows are often short and fixed around weekends, month-end closing and peak seasons. A plan that needs a twelve-hour outage may wait months; continuous sync needs only a short window.
RelatedSaudi Data and Artificial Intelligence Authority (SDAIA)National Cybersecurity Authority (NCA)
Ways to transfer a database, and their trade-offs
Each method is the right one somewhere. The table shows where each usually fits.
| Method | How it works | Usually fits when | Trade-off |
|---|---|---|---|
| Backup and restore | A full backup is restored on the new server; writes stop for the last one | The database can be backed up, copied and restored inside the window | Simple, but the outage is the whole copy, restore and check |
| Export and import | Data is exported to files and loaded into the new server | The version or platform changes and a backup cannot be restored | Slow for large data; indexes, permissions and jobs are rebuilt |
| The engine's own replication | The new server replicates the old one and is promoted at the switch | Same engine, compatible versions, a network path between servers | Short outage, limited to what the engine supports |
| Server or storage copy | The virtual machine or storage volume is copied to the new site | Similar platforms, nothing inside the database changes | Moves problems too; the network carries the full volume |
| Continuous replication with a tool | An initial load, then changes applied continuously until the switch | Large or busy database, short window, or different engines or versions | More set-up, but a short switch and the old server as the way back |
When the engine's own replication or a backup and restore fits the window, use it: it is usually cheaper and better supported. Continuous replication earns its cost when the database is too large or busy for one window, or the two servers cannot replicate natively.
How a database transfer with continuous sync runs
When the database cannot stop for long, the transfer follows this order. Each step has a check before the next begins.
-
Prepare the new server.
Configure engine, storage, network and access, test with production-sized data, and confirm the network can carry the initial load in time.
-
Initial load.
Copy the bulk of the data once, throttled so the old server keeps serving users. On a large database this can take days; users are not waiting for it.
-
Continuous sync.
Apply every later change on the old server to the new one, continuously. Measure the lag and agree in advance how much is acceptable.
-
Validate.
Row counts per table, checksums on columns that carry money, identity and dates, and one business report run on both. Pass conditions are agreed first.
-
Rehearse.
Run the switch and the way back on a test copy, timed, with the people who will do it.
-
Switch.
Stop writes on the old server, let the last changes arrive, run the checks, repoint applications. Keep the old server intact until the new one has carried a real peak.
Database transfer checklist: questions to answer before the first copy
| Question | Why it matters | Who answers it |
|---|---|---|
| How large is the database, and how much changes per hour at peak? | Decides whether one window is enough | Database administrator |
| How long may the database be unavailable for the switch? | The downtime budget sets the method | Business owner |
| Does the engine or its version change? | Rules out some methods and adds testing | Architect |
| What else connects to the database? | Reports, interfaces and jobs must be repointed and tested | Application owners |
| Where will each copy of the data sit during the transfer? | Staging, backup files and logs need approval too | Compliance owner |
| How will we prove the data arrived complete? | Agreed pass conditions stop arguments on the night | Data owner |
| What is the way back, and until when? | Without one, the switch is a one-way bet | Project lead |
Our database migration decision checklist goes further for projects where the engine or the data model also changes.
Transfer a SQL database, or transfer data between different databases
Two variants come up often. The first is to transfer a SQL database, such as SQL Server, MySQL or PostgreSQL, to a new server on the same engine, often a newer version. The engine's own tools usually cover most of it; continuous replication is needed when the database is too large or busy for the window, or the versions are too far apart.
Read more
The second is to transfer data between databases that are not the same product, such as a relational system feeding a NoSQL target. That is no longer a simple move: types, keys and structures need a mapping, and both systems may stay live for a long time. Our database synchronization page covers one-way and two-way sync and conflict rules.
Relateddatabase synchronization
Where iblync fits in a database transfer, and where it does not
iblync is Interkey's own platform for data migration and replication between systems not designed to exchange data. In a database transfer it carries the initial load and the continuous sync, with real-time replication and flow control. Throttling limits what the transfer takes from production; if the new server is unavailable, changes queue instead of failing. iblync's own site states that an interrupted migration resumes where it stopped, and that validation uses checksums and row counts.
Read more
Interkey confirms where it runs for each engagement.
Where it does not fit: if the engine's own replication, or a backup and restore, does the job inside your window, that path is usually cheaper, and we will say so. iblync does not set your downtime budget, approve data locations or sign the switch; your owners do.
Relatedreal-time replication
How Interkey helps with a database transfer
Interkey plans and runs database transfers for organisations in Saudi Arabia: the assessment, the choice of method (native where it fits), the new server tested with production-sized data, continuous sync with iblync where needed, the validation report, the rehearsed switch and support after the move. If your team runs the transfer, we can review the plan and take only the sync and the switch.
Support comes from Riyadh, with Arabic-speaking engineers from the first call to the switch. Before work starts we confirm where iblync runs and whether any data leaves your environment.
What drives the cost and the timeline
iblync is priced by quotation, against source systems, target systems and data volume; there is no published price list. Services are scoped by the steps you want us to run, and a transfer with native tools alone costs only the work.
The timeline depends on the database more than the tool: size, peak change rate, the network path, applications and jobs to repoint, rehearsals, and how long both servers stay live. We give an estimated range after the assessment, with its reasons.
Questions buyers ask about database transfer
How do we move a production database to a new server without a long outage?
Load the bulk of the data onto the new server while the old one keeps working, keep the two in sync, then switch in a short window once the checks pass. The outage is the switch, not the copy.
Can we transfer a SQL Server database to a new data centre while users are still working on it?
Yes. Either SQL Server's own replication between the two servers, where versions and network allow it, or continuous replication with a tool such as iblync. Users keep working until the switch.
How long does a database transfer take for an organisation in Saudi Arabia?
It is estimated per project, from the size of the database, how much data changes at peak, the network path between the sites, the applications to repoint and the rehearsals needed. We give a range after the assessment, with its reasons.
Does our data leave the Kingdom while the database is being transferred?
Only if the plan routes it out. Staging copies, backup files and tool logs each have a location, agreed with your compliance owner first. Where iblync runs is confirmed per engagement.
How is a database transfer with iblync priced?
By quotation. iblync is priced against the source systems, target systems and data volume; the services around it against the steps you want us to run. If native tools are enough, you pay only for the work.
Can we go back to the old server if something is wrong after the switch?
Yes, if the plan keeps it. The old server stays intact until the new one has carried a real peak, and the way back is rehearsed before the night of the switch.
Next
Related pages
Next step
Plan your database transfer
Tell us the engine and version, the database size, where it is moving to and the downtime window you can get. The reply comes from the team that would run the transfer.
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