Data platform · Migration framework
A data migration framework in six phases, with a Saudi governance checkpoint in each
A data migration framework is the shared method a migration follows from the first inventory to the day the old system is switched off. This guide sets out six phases, the governance checkpoint Saudi organisations add to each, and 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
- A phased method for moving data, with an exit condition and a sign-off for every phase
- The six phases
- Assess, map, sync, validate, cut over, decommission
- Saudi checkpoints
- Classification, personal data, residency, access and retention
- Who it is for
- Data owners, architects, programme managers and the compliance owner
- How long it takes
- Estimated per project, from the number of systems, data change rate and rehearsals
- Where iblync fits
- Sync and cut-over: continuous replication and parallel running
The problem in plain words
- The usual failure: each team migrates its own way, so nobody can say which phase the project is in or who allowed the next step.
- What a framework changes: every phase has an output, an exit condition and a named person who signs it off.
- Why Saudi organisations need more: classification, personal data and residency are checked during the move, not after it.
- What it is not: a tool. Tools move data; the framework decides when.
What a data migration framework is, and how it differs from a checklist
A checklist records the decisions to settle before a migration starts: what moves, the downtime the business accepts, how you prove the data arrived, and what rollback means. Our database migration decision checklist covers those; this guide does not repeat them.
A data migration framework is the method around those decisions. It puts the work in a fixed order, gives each phase an output, and stops the project moving on until that output is accepted by someone with authority. With several migrations in one programme, it makes the second and third follow the rules of the first. Three properties make it work:
Read more
- Exit conditions, not dates. A phase ends when its output is accepted.
- Named sign-off. One person can say yes at each checkpoint, and not the person who did the work.
- Evidence kept. Each sign-off leaves a record you can show an auditor later.
The data migration process steps: six phases
Each phase has an output and an exit condition. The governance checkpoint that closes it is in the next table.
-
Assess.
Inventory the source systems, their data, its volume and daily change, and everything that connects to them: reports, interfaces, scheduled jobs. Classify the data under your organisation's policy. Output: a classified inventory. Exit: nothing in scope is unclassified.
-
Map.
Write down, field by field, how source data becomes target data: types, keys, code lists, time zones, Arabic character encoding, and the rule for records that do not fit. Decide what is not moving. Output: a mapping document the data owner has read. Exit: every field has a rule and every exception an owner.
-
Sync.
Load the bulk of the data once, then keep the target current while the source still serves the business, throttled so production keeps its capacity. Output: a target close behind the source, with lag measured. Exit: lag stays inside the agreed limit for an agreed period.
-
Validate.
Prove the data arrived complete and unchanged in meaning, with the checks agreed before the move: counts, checksums, field-level samples and one business report run on both systems. Output: a reconciliation report. Exit: the validation owner and the data owner sign it.
-
Cut over.
Rehearse on production-sized data, then switch on the business's schedule: stop writes, apply the last changes, repoint applications, confirm. The source stays available until the last safe moment to go back. Output: the target in production. Exit: business sign-off.
-
Decommission.
Archive or delete what remains on the old system under your retention rules, revoke access, and remove replication paths and old interfaces. Output: a decommissioning record. Exit: no live copy remains where the policy says it should not.
Saudi governance checkpoints at the end of each phase
The questions organisations in the Kingdom usually ask at each gate. Which rules apply to you is for your compliance owner to confirm.
| Phase | Checkpoint question | Evidence that closes it |
|---|---|---|
| Assess | Is every dataset classified under our policy, and do we know which ones hold personal data? | The classified inventory, accepted by the data owner |
| Map | Does any field change meaning, lose precision or lose Arabic characters on the way? | The mapping document and the list of exceptions with their owners |
| Sync | Where will copies of the data sit while it moves, and is each location allowed for its class? | The data flow diagram, including staging areas and the replication path |
| Validate | Has the data been proven complete, and who saw personal data while testing it? | The reconciliation report and the access log for the test environment |
| Cut over | Who approved going live, and when does going back stop being possible? | The signed cut-over approval and the rehearsal timings |
| Decommission | Is the old copy archived or deleted according to retention rules, and is access to it closed? | The decommissioning record and the revoked access list |
Personal data in Saudi Arabia falls under the Personal Data Protection Law, which the Saudi Data and Artificial Intelligence Authority (SDAIA) oversees; SDAIA's National Data Management Office publishes the national data management standards. The National Cybersecurity Authority (NCA) publishes cybersecurity controls. Our overviews of data classification and the PDPL give the general picture; for any control, read the authority's own text.
Choosing a data migration strategy: three shapes and their trade-offs
The framework stays the same; the strategy changes how long sync runs and how cut-over is done.
| Strategy | How it works | Trade-off |
|---|---|---|
| Single cut-over | Writes stop, the data moves, the target goes live in one window | Simple, but all the risk sits in one night, and the window must fit the copy and the checks |
| Phased | The data moves in groups: by business unit, region, module or table set | Smaller windows and earlier lessons, but both systems coexist and interfaces must know which owns what |
| Parallel running | Continuous replication keeps both systems current; the switch happens when the business is ready | Little downtime and a real way back, but replication is monitored and both systems run meanwhile |
Many programmes mix them: a phased plan with continuous replication inside each phase. Choose by the downtime budget and the cost of going back.
Data migration testing: what to test, and when
Testing is not one phase at the end. It starts in the map phase and ends after cut-over, and each layer answers a different question:
- Mapping tests, on a sample: does each rule give what the data owner expects, including empty versus NULL, dates near midnight and mixed Arabic and Latin text?
- Volume tests, on production-sized data: does the load fit the plan, and how far does replication fall behind at peak?
- Reconciliation tests, after sync: counts, checksums on the columns that carry money, identity and dates, and named records checked field by field.
- Application tests: applications, reports and interfaces work against the target.
- Rehearsal of the cut-over and of going back, timed, by the people who will do it.
If test copies hold personal data, decide in the assess phase whether they are masked and who may see them unmasked.
What the data migration plan should contain
The plan is the framework applied to one project. It can be short, but it answers in writing:
- the scope, and what is out of it;
- the strategy and why, against the downtime budget;
- who owns each phase and who signs each checkpoint;
- the validation checks, agreed before data moves;
- the last safe moment to go back;
- where every copy of the data sits during the project, and when it is removed.
Durations go in as estimates with their drivers: systems, volume, change rate, mapping exceptions and rehearsal timings.
Where iblync fits in the framework, and where it does not
iblync is Interkey's own platform for data migration and replication between systems that were not designed to exchange data. Here it carries the sync and cut-over phases: a one-time or phased load, continuous real-time replication including bi-directional synchronisation, and flow control, with throttling so production keeps its capacity and queueing while a target is unavailable. That makes parallel running practical, and with it a short, reversible cut-over. iblync's own site states that an interrupted migration resumes where it stopped and that validation uses checksums and row counts; those checks feed the reconciliation report.
Read more
Where it does not fit: iblync does not classify your data, write mapping rules or sign checkpoints; your data owners do. And if source and target come from one vendor with a supported native migration path, that path is usually cheaper. We will say so.
Relatediblync
How Interkey helps
Interkey runs database migration projects for organisations in Saudi Arabia with this framework: the assessment and classified inventory, the mapping with your data owners, replication and parallel running with iblync where it fits, the reconciliation report, the rehearsed cut-over and the decommissioning record. Where you already have a method, we work inside it.
The team works from Riyadh, in Arabic and English, so mapping reviews and sign-offs happen in the language your owners use. Before work starts we confirm where iblync runs and whether any data leaves your environment, so residency is settled in the assess phase. iblync is quoted per project, against source systems, target systems and data volume.
Relateddatabase migration
Questions buyers ask about a data migration framework
What is a data migration framework?
A shared method for moving data from one system to another, in fixed phases. Each phase has an output, an exit condition and a named person who signs it off before the next phase begins. The six phases in this guide are assess, map, sync, validate, cut over and decommission.
How is a migration framework different from a migration checklist?
A checklist lists the decisions to settle before the migration starts. A framework is the order the work follows afterwards, with the checkpoint that closes each phase. Most projects need both; see our decision checklist.
Relateddecision checklist
Which governance checks does a data migration in Saudi Arabia need?
Usually: every dataset classified, personal data identified, every location the data passes through allowed for its class, access during testing controlled, and the old copy archived or deleted under your retention rules. Your compliance owner confirms which rules apply, against the texts of SDAIA and the NCA.
Can data leave the Kingdom while it is being migrated?
That depends on its class and the rules that apply to you, and it covers staging areas and replication paths, not only the target. The framework answers it in the assess phase. For iblync, Interkey confirms where it runs and whether data leaves your environment before work starts.
How long does a framework-based migration usually take?
It is estimated per project, from the number of source systems, data volume, how much data changes during the move, mapping exceptions and rehearsal timings. Parallel running adds calendar time but shortens the cut-over window.
How is a migration with Interkey priced?
By quotation. iblync is priced against source systems, target systems and data volume, and the services around it against the phases you want us to run. Tell us those and the downtime window, and we reply with a first scope.
Next
Related pages
Next step
Review your migration plan against the framework
Tell us the source and target systems, the rough data volume, the downtime window and the phases you already have. We reply with the gaps we see and a first scope.
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