On-Prem to ExaCC: A Migration Method Decision Framework by Database Size

An enterprise consolidating a dozen databases onto a single ExaCC rack finds no single migration method fits all of them. A 100 GB reporting schema, a 10 TB OLTP core, and a 100 TB archive database each demand a different approach - despite landing on identical target infrastructure.

• Database Size: Determines whether logical (row-level) or physical (block-level) transfer is realistic within the available window.
• Network Bandwidth: Sustained throughput between source and ExaCC bounds both bulk transfer time and redo transport lag for online methods.
• SLA / Downtime Tolerance: The business-defined acceptable outage window narrows the field of viable methods independent of size.

None of these three factors works in isolation, which is exactly why they're drawn radiating from a single decision rather than as a checklist to work through top to bottom. A 10 TB database with generous bandwidth and a relaxed SLA might comfortably use a physical online method, while the same 10 TB database over a constrained link and a tight SLA might be forced toward a different approach entirely – the method choice sits at the intersection of all three, not any one of them alone.

Figure 1 · Three inputs feed one method decision, reported back to a single choice

1. Measure Real Bandwidth, Don't Assume ItA stated 10 Gbps link rarely delivers that throughput sustained for redo transport under production load.
2. Tier Your Migration Wave by SizeMigrate smaller, lower-risk databases first to validate the pipeline before tackling the largest ones.

Read this pyramid as a starting point rather than a rulebook, because size alone never fully determines the right method – bandwidth and SLA still narrow the choice within each tier. What the shape does capture correctly is the general direction of travel: as a database grows, the field of realistic options narrows toward physical, incremental methods, because logical row-by-row approaches simply run out of runway once the dataset crosses into multi-terabyte territory.

Figure 1 · As database size grows, the base of viable methods narrows

3. Revisit the Matrix Per Database, Not Per ProjectA consolidation project migrating twelve databases may use four different methods - that's expected, not a sign of an inconsistent plan.

Green cells mark a strong fit, amber marks a workable but not ideal fit, and red marks a tier where the method typically breaks down in practice. Reading across a row shows how far each method's comfort zone extends; reading down a column shows every viable option for a given database size. GoldenGate's row stays green across every tier for a structural reason: because it replicates continuously rather than transferring a fixed dataset in one pass, its outage-window advantage doesn't erode as data volume grows the way every other method's does.

Figure 3 · A fit rating for each method across four common size tiers

4. Build SLA Into the Method Choice ExplicitlyDocument the accepted downtime for each database before selecting its method, not after.