Bidirectional database sync: two systems taking writes, kept in step

It is not a backup: two-way sync spreads every change, including a mistaken delete, to both sides. Nor does it remove the decision about ownership. Two systems taking writes will sooner or later change the same record, and the rule for that moment must exist before the first write. Our page on database synchronization with iblync sets out the three kinds of sync side by side.

• Move in stages. Departments, services or reports switch one at a time, on the business's schedule rather than at the end of a transfer window.
• Keep the way back. If the new system misbehaves, users return to the old one and their recent work is already there.
• Prove before you switch. Validation runs while both systems are in use, so the go or no-go decision rests on real figures.

Parallel running has an end date. The longer both sides take writes, the more conflicts and lag there are to watch, so the plan names what must be true to retire the old system. The zero downtime migration page sets out each phase up to the final cutover.

• Ownership. Which system owns each type of record, and where possible each field. Clear ownership prevents most conflicts.
• Conflict resolution. When the same record changes on both sides, which change wins: the owning system, a priority rule, or a review queue for a person to decide.
• Loop prevention. A change applied from one side must not be read back as a new change and sent home again.
• Mapping. How fields, codes, dates and Arabic text map between two data models designed apart.
• Acceptable lag. How far one side may fall behind before someone is alerted.
• Deletes. Whether a delete on one side removes, archives or only flags the record on the other.

When it is the wrong fit: if both systems come from one vendor with a supported native replication path, that path is usually cheaper, and we will say so. If one system can stay read-only, one-way replication is simpler.

There is no published price list. The quotation follows the source systems, the target systems and the data volume; the effort follows how many record types need writes on both sides, how far the data models differ, and how long parallel running lasts. Durations are estimated in scoping as a range.

Interkey confirms where the sync runs, and whether data leaves your environment, before the first record moves. 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. The database migration service page describes the wider sequence from assessment to handover.