Choose change scope per asset, not by migration slogan.
Rehost/Replatform/Refactor Strategies and Why Moving Tables Without Semantics Preserves Technical Debt
Separate rehost, replatform, and refactor choices while preserving governed warehouse semantics.
Learning outcomes
Distinguish rehost, replatform, and refactor by the amount of implementation and semantic change introduced.
Choose strategy per workload/object rather than forcing one migration pattern across the estate.
Explain why “same tables on a new engine” can preserve hidden debt and bypasses.
Separate infrastructure modernization from metric-version changes.
Build a reversible strategy record with evidence, dependencies, and acceptance tests.
Chapter 29 begins from the governed AtlasMart state through
Chapter 28:
10 current paid lines, 8 orders, 12 units, 820 USD gross
revenue, 495 USD cost, and 325 USD gross profit, with source waterline 208. The sales fact
grain remains one paid order line;
gross_revenue_usd.v1 remains paid line amount in
USD under its governed filters and UTC time semantics. A
platform migration is not permission to redefine those
contracts.
The mandatory lab is free/local/synthetic and was executed with Python 3.13.5 and SQLite 3.46.1. SQLite supplies tables, views, transactions, UPSERT and query-plan evidence, but it does not implement stored procedures, cloud roles, CDC connectors, or managed-warehouse cost controls. Stored-procedure behavior and access roles are therefore represented as explicit metadata/policy fixtures, while SQL correctness and restart/idempotency behavior are executed locally. Time zone is UTC; no production credentials or personal data are used.
1. Problem frame: three migration words hide different risks
AtlasMart can move the legacy EDW to newer infrastructure with almost no logical change, adopt a new engine while adapting physical features, or redesign the model and pipelines. Those choices are commonly called rehost, replatform, and refactor. The names are useful only when the migration record states exactly which contracts are preserved, which implementation changes are introduced, and which consumer behaviors are allowed to differ.
2. Define the three strategy classes
| Strategy | Primary change | AtlasMart example | Main benefit | Main migration risk |
|---|---|---|---|---|
| Rehost | runtime/hosting location | same schema and report SQL on new VM/container | fastest infrastructure exit | moves hidden debt unchanged |
| Replatform | engine/platform while retaining core model | same fact grain/metric contract, new indexing/storage/security implementation | use platform capabilities | engine semantics differ |
| Refactor | data model/pipeline/semantic architecture | replace hidden procedure with explicit tested semantic contract | remove debt and improve operability | larger change surface and harder rollback |
The useful unit of choice is not “the whole warehouse.” A stable finance report may be replatformed first while a brittle manual mart is refactored. The strategy record should therefore be attached to assets or bounded workstreams with dependencies.
3. Preserve semantics independently from implementation
AtlasMart's gross_revenue_usd.v1 means 820 USD in
the current fixture. Replatforming may change indexing,
partitioning, compute isolation, or SQL syntax, but v1's filter
and unit contract remain unchanged. If the business wants to
include internal test transactions, that is a separate metric
proposal—v2—with its own consumers and migration
plan. Combining infrastructure migration and metric redefinition
makes parity failures ambiguous.
{ "metric": "gross_revenue_usd.v1", "grain": "aggregate over one paid order-line fact", "filter": "status='paid' AND is_test_order=0", "time_zone": "UTC", "unit": "USD", "legacy_result": 820, "modern_result": 820, "breaking_candidate": "define v2 separately; do not alter v1 during infrastructure move"}4. Strategy decisions need a dependency and rollback dimension
A refactor that removes a legacy procedure is not safe merely because the replacement SQL returns 820 USD once. The team must know which scheduled jobs invoke the procedure, whether retries were idempotent, whether historical backfills used different logic, and which reports expect its output shape. Rollback also differs by strategy: a rehost can often switch connection routes; a refactor may require dual-write or compatibility views until the new contract is stable.
| Decision field | Example value |
|---|---|
| asset | finance daily revenue pipeline |
| current dependency | erp.orders → legacy.sales_line → procedure → reports |
| chosen strategy | replatform serving + refactor hidden filter into tested contract |
| semantic contract | gross_revenue_usd.v1 unchanged |
| acceptance | old/new daily controls exact; security no bypass; p95 within threshold |
| rollback | route reports back to legacy copy; keep legacy load alive during observation window |
5. Controlled failure: “lift and shift” as debt elimination
Move sales_line, procedure text, broad analyst
permissions, and every report exactly as-is, then claim the
legacy problems are solved because the infrastructure is
newer.
Diagnosis: rehost can be a valid tactical strategy, but it preserves semantics and defects together. Hidden filters remain hidden. Broad bypass permissions remain broad. Operational coupling remains coupled. The migration may reduce infrastructure risk while leaving data-product risk unchanged.
Repair: classify which debt is intentionally preserved, which must be remediated before cutover, and which will be scheduled after. Make the temporary state explicit with owners and retirement dates.
6. Local lab: record a mixed strategy
strategy = { "legacy.sales_line": { "mode": "replatform", "preserve": ["one-paid-order-line grain", "source_seq<=208", "history"], "change": ["physical index", "new database file"] }, "sp_refresh_finance_sales": { "mode": "refactor", "preserve": ["status='paid'", "is_test_order=0", "UTC day"], "change": ["hidden rule -> explicit tested semantic contract"] }, "rpt_exec_revenue": { "mode": "rehost-compatible", "preserve": ["gross_revenue_usd.v1"], "rollback": "route to legacy report" }}for asset, decision in strategy.items(): assert decision["preserve"]print("strategy records:", len(strategy))# Expected: strategy records: 37. Performance and cost are acceptance dimensions, not strategy labels
“Cloud,” “serverless,” “replatformed,” or “refactored” does not
automatically mean faster or cheaper. The executed local
benchmark uses 180,000 deterministic rows, one query, one warm
SQLite cache, and concurrency 1. It is evidence about one
physical index change only. The old plan scans the table; the
new plan searches idx_new_product_date. In this run
the measured p95 changed from 8.0677 ms to
0.1669 ms. That does not predict a managed
cloud warehouse, but it demonstrates the required method: same
data, same result, disclosed cache/concurrency, and before/after
evidence.
8. Verification checklist
- Every asset has an explicit strategy rather than inheriting a program-wide slogan.
- Semantic contracts are versioned separately from infrastructure changes.
- Preserved technical debt is named, owned, and time-bounded.
- Rollback complexity is assessed before strategy approval.
- Performance/cost claims use equivalent workload semantics.
All destructive actions target only a disposable
atlasmart_ch29_lab directory. Never point these
commands at a production warehouse. Reset with
python -c "import shutil; shutil.rmtree('atlasmart_ch29_lab',
ignore_errors=True)"
and rerun the fixture from a clean directory.
9. Production judgment and bridge
Rehost, replatform, and refactor are change-scope descriptions, not maturity rankings. A low-change strategy can be safer for a critical report; a refactor can be justified where hidden logic or operational fragility is the dominant risk. The next lesson turns the strategy into migration mechanics: historical backfill, dual loads, parallel run, CDC waterline, cutover, and reconciliation.
Knowledge check
Does rehost remove hidden semantic debt?
Show answer
No. Rehost primarily changes hosting/runtime placement. It can be useful, but hidden business logic and permission design generally move with the workload unless separately remediated.
When should a metric definition change during platform migration?
Show answer
Only as an explicit, separately versioned semantic change with its own tests and consumer migration. Infrastructure parity should first preserve the existing metric.
Can different warehouse assets use different migration strategies?
Show answer
Yes. Strategy should follow dependency, risk, change scope, and rollback needs rather than one label for the entire estate.
What does the local p95 benchmark prove?
Show answer
Only that the indexed SQLite fixture improved this disclosed query under this local cache/concurrency environment while preserving results. It does not generalize to another engine or workload.
Authoritative references
- SQLite — Transactions for the local atomicity model used in the executable harness.
- SQLite — UPSERT for the local idempotent replay example.
- SQLite — EXPLAIN QUERY PLAN for the local plan evidence; its output format is explicitly not a stable application API.
- Kimball Group — DW/BI resources for dimensional modeling, business process/grain discipline, and lifecycle-oriented warehouse delivery.
- Big Data Academy — Data Warehousing and Dimensional Modeling curriculum for this course's stable AtlasMart contracts and chapter sequence.