Option zero: do not migrate it
Migrate the history, rebuild the derivations. Decide layer by layer before comparing methods.
Before comparing migration methods, ask whether this platform should be migrated at all.
For a substantial proportion of reporting estates, the honest answer is that rebuilding from upstream sources is cheaper, faster and produces a better result than moving what exists. This is most often true when:
- The layer in question is derived rather than authoritative. Datamarts, aggregate layers, reporting schemas and most ODSs hold nothing that cannot be reconstructed from the systems that fed them. If you can rebuild it in a fortnight from source, migrating it — with all the compatibility, validation and reconciliation work that implies — is poor value.
- The existing model is the problem you were trying to solve. If the business case for the move includes “and then we can finally fix the model”, moving the model first and fixing it later means doing the work twice, and the second half never gets funded.
- The transformation logic is already being rewritten for other reasons.
It is rarely true for the base historical layer. Ten years of history that upstream systems no longer hold is genuinely irreplaceable, and that data is exactly what physical and logical migration methods are good at moving.
The practical shape this takes on most estates is a split decision: migrate the history, rebuild the derivations. That is not a compromise — it is usually the right answer, and it changes your method selection substantially, because the volume you actually have to move is a fraction of the platform’s total size.
Make this decision explicitly, layer by layer, before you compare methods. A team that has decided to rebuild its marts is choosing between different options from a team that has decided to move everything.