Four options, not three
Rebuild, physical transport, logical migration, extract–land–load — and why synchronisation is not a fifth.
| Approach | Choose it when | What it costs you | What you must prove |
|---|---|---|---|
| Rebuild from upstream | The layer is derived, or the model is being changed anyway | Full re-implementation of the logic that produced it | That upstream still holds what you need, and that the rebuilt output reconciles with the old |
| Physical transport (TTS with incrementals) | Oracle source, eligible release, physical design carries forward, a controlled read-only period is acceptable | Strict compatibility and self-containment rules; provisioning constraints on the target | Compatibility, self-containment, target support, and that the read-only window fits |
| Logical migration | Oracle source, object-level selection needed, or the outage must be short | Object-by-object compatibility and error handling; replication complexity if online | Object compatibility findings, a consistent starting point, and a designed catch-up |
| Extract, land and load | Non-Oracle source, or the data needs substantial reshaping or repair | You build and operate the extraction, file control and reconciliation yourself | A bounded extract design, landing capacity, a schema contract and a tested restart |
Continuous synchronisation is not a fifth option. It always needs an initial load, so it pairs with one of the above to shorten the final outage or allow a period of coexistence.