Why sync layers are under-tested by default
Testing the new cloud system is clearly someone's job, and testing that the legacy system still works is implicitly nobody's job because it's assumed stable. The sync layer sits in the gap between these two ownership assumptions and often gets only the testing time left over once both systems' own teams are satisfied.
Explicitly assigning ownership of sync-layer testing to a specific team, with its own test plan independent of either system's own test suite, closes this gap directly.
Test for the legacy system's actual data, not its documentation
Legacy systems accumulate years of data that doesn't match their own original schema assumptions — fields repurposed informally, encoding inconsistencies, orphaned records from old migrations. A sync layer tested only against clean, documentation-compliant sample data will fail quietly against this real production mess.
Pull a genuinely representative, anonymised sample of real production data for sync testing, specifically including the known-messy edge cases the legacy system's long-tenured operators can usually describe from memory, even if they've never been formally documented.
Design for partial failure and reconciliation
Assume the sync will fail partially at some point — a batch partially processes, a network interruption mid-transfer, a schema mismatch on one record type. Build reconciliation tooling that can detect and resolve drift between the two systems as a standard operational capability, not an emergency response built after the first real incident.
A sync layer with no reconciliation tooling is a sync layer that will eventually drift silently, and the first sign of it will be a business user noticing numbers don't match between systems — the most expensive way to discover it.
The sync layer is new code running against the oldest, messiest data in the organisation. Test it like it's both.MNB Integration Practice
Key actions
- Assign explicit ownership of sync-layer testing to one team
- Test against real, representative legacy data, not clean samples
- Build reconciliation tooling as a standard operational capability
- Assume partial failure will happen and design for detection, not just prevention