Model complexity dimensions
What to measure before choosing a method. More decisive than volume.
Extracted from Complexity, not volume. Append new dimensions here as they emerge.
Which means the complexity assessment has to come first, and it needs to be more than a table count. What I would actually measure:
- Dependency depth and ordering. How much of the estate can load independently, and how deep is the longest chain that cannot? This is the single strongest predictor of difficulty.
- Uniformity. One repeated shape, or hundreds of distinct ones? Uniformity is what makes automation and parallelism cheap.
- Statefulness. Append-only history is easy. Sequences, surrogate key generation, slowly changing dimensions and in-place updates all carry state that has to arrive intact and consistent.
- Non-data objects. Views, materialised views, procedural code, grants, synonyms, scheduler definitions. These do not appear in a volume estimate and are frequently the reason a migration stalls.
- Physical and feature exotica. Partitioning schemes, compression, LOBs, index-organised tables, encryption, and anything with no direct equivalent on the target. One unsupported feature can invalidate an entire method.
- Referential and consistency requirements. At what points must integrity hold, and what is allowed to be temporarily inconsistent during the move?
Score these honestly and the method choice largely makes itself. Score them optimistically — or skip them and go straight to the recommended toolset because it is the recommended toolset — and you find out during the second aborted attempt.