Tool · The Migration Engine

The Replatform Migration Engine

Six stages, one engine. Inventory every artifact. Plan the wave structure. Convert with a codified rule library. Validate with deterministic checksums. Reconcile during the parallel run. Report at cutover. Every engagement runs the same kernel — different source, different target, same discipline.

Book a 30-min call Read a sample assessment ↗

How it works

Six stages. One deterministic kernel.

Every migration engagement runs the same six-stage pipeline regardless of source or target platform. Human sign-off gates enforce the stage boundaries that matter.

STAGE 1

Inventory

Read-only metadata sweep of every object in scope — tables, views, UDFs, stored procedures, dbt models, BI artifacts, and documented downstream consumers.

Output: Written inventory with row counts, lineage, and complexity classification per object.

STAGE 2

Plan

Architectural decisions per dataset. Batching strategy, wave sequencing, dependency ordering. A named owner is assigned per artifact before any conversion begins.

Output: Wave plan with dependency map and owner assignments. Reviewed at human gate before proceeding.

STAGE 3

Convert

The codified rule library handles known patterns. Bespoke handlers cover edge cases flagged during planning. Every object is self-classified: auto-ok, needs review, or blocked.

Output: Translated DDL, DML, ETL logic, and BI artifacts. Conversion manifest with classification per object.

STAGE 4

Validate

A deterministic validation harness compares source and target at every level. No model grades its own output — all checks are code-driven.

Row-count parity per table

Schema parity (names, types, nullability)

Float-tolerant numeric checksums

Query-result diffs on agreed test queries

STAGE 5

Reconcile

Both platforms run in parallel during the reconciliation window. Daily diff reports surface any drift between source and target before consumers cut over.

Output: Per-consumer signoff confirmations and a reconciliation evidence package.

STAGE 6

Report

A structured cutover document co-signed by your platform lead and ours. Named sign-offs, reconciliation evidence, known limitations, and the rollback procedure if needed.

Output: Co-signed cutover document. The engagement does not close until both parties sign.

The rule library

Every engagement makes the next one faster.

The conversion layer is built on a YAML rule library. Each rule encodes a known pattern — a source dialect construct, its target-dialect equivalent, and the edge cases that require human review. When a new engagement surfaces a manual fix, that fix becomes a rule before the engagement closes. The library compounds across every migration.

Sources the rule library covers

Amazon Redshift
Snowflake
BigQuery
Teradata
Informatica PowerCenter
SSIS (SQL Server Integration Services)

Bespoke sources (Oracle, MS SQL Server, Hadoop, on-prem PostgreSQL, IBM DataStage) are quoted case by case — the rule-library work happens during the engagement.

What the rules encode

DDL patterns

Data type mappings, constraint translations, partition-scheme rewrites, identity column handling.

DML / query patterns

Function equivalence, window function syntax gaps, date-format token translation, semi-structured access patterns.

Human-review flags

Patterns with no safe automatic equivalent — pseudo-columns, dialect-specific NULL semantics — are flagged and routed to an engineer, never silently converted.

ETL / orchestration

Informatica session-to-notebook translation patterns, SSIS package structure mappings, scheduling equivalences.

Coverage

The six pairs the rule library covers.

These are the migration shapes the team has shipped end-to-end across prior roles — each one carries a codified rule library, deterministic translators, and a reconciliation harness specific to it. Engagements on these pairs are faster because the second migration runs cheaper than the first.

Source	Target	What the rule library handles
Amazon Redshift	Snowflake	DDL translation, DISTKEY/SORTKEY → CLUSTER BY, IDENTITY column handling, SUPER → VARIANT
Amazon Redshift	BigQuery	Slot economics, partition/cluster mapping, Spectrum external tables, query rewrite patterns
BigQuery	Databricks	GoogleSQL ↔ Databricks SQL parity, UDF translation, lakehouse re-architecture, Unity Catalog adoption
Snowflake	Databricks	Time-travel / zero-copy clone replacement, Snowflake JS UDFs → Spark Python, Iceberg interop
Teradata	BigQuery or Snowflake	BTEQ translation, MVIEW rewrites, PRIMARY INDEX → CLUSTER BY mapping
SSIS / Informatica PowerCenter	dbt + Airflow / Dagster	Control flow → DAG topology, lookup transforms → models, Execute SQL Task → Jinja macros

Other shapes are quoted case by case. Teradata → Databricks, cloud-to-cloud (AWS ↔ GCP ↔ Azure), database-to-Postgres, on-prem to managed-warehouse. We will quote and ship these — the rule-library work happens during the engagement rather than amortized across prior packs. Tell us the shape and we will say what is in scope and what is not before any commitment.

Most engagements involve one source and one target. Multi-hop migrations (e.g., Teradata → interim Redshift → final Snowflake) are scoped case by case.

Validation philosophy

Deterministic — no model grades its own output.

The validation harness is entirely code-driven. Row counts, schema column-by-column comparison, float-tolerant numeric checksums, and query-result diffs are all computed by deterministic scripts — not inferred or approximated.

This is a hard boundary. The conversion step uses judgment to handle dialect translation. The validation step uses arithmetic. The two must not be conflated: a conversion that "looks correct" is not the same as a conversion that produces matching counts and checksums under a formal test battery.

Every validation result is written to a signed reconciliation artefact. The engagement does not advance to parallel-run until that artefact is green.

Row-count parity

Source and target row counts match within agreed tolerance per table, per partition where applicable.

Schema parity

Column names, data types, nullability, and ordinal positions compared column-by-column. Type mismatches surface as blocking errors, not warnings.

Float-tolerant checksums

Numeric aggregation checksums use configurable epsilon tolerance so floating-point representation differences don't produce false failures.

Query-result diffs

A battery of agreed test queries is run against both platforms. Results are diff'd row-by-row, order-normalised. Any divergence is a blocking signal.

Read: how we structure the cutover playbook ↗

How to engage

Three ways in.

Start wherever makes sense. Most teams begin with the quick-check, use the X-Ray to get a scoped problem statement, then engage for the full sprint.

FREE

FinOps Quick-Check

Six questions. Runs in your browser. Returns an indicative cloud waste range and the named levers to investigate. No signup, no email gate.

Run the quick-check

FREE — THROUGH Q3 2026

Cloud Cost X-Ray

A live 90-minute review of your warehouse bill. Named levers, savings model, 30/60/90-day plan. Free through Q3 2026 in exchange for permission to publish the anonymized methodology; afterward reverts to a $100 5-day paid diagnostic, credited to execution.

Send me your bill

SCOPED FIXED-FEE

Discovery Sprint → Execution

A structured Discovery Sprint produces a full inventory, wave plan, and effort estimate — before you commit to a full migration. Execution is quoted separately on fixed-fee terms.

Start with a Discovery Sprint

Go deeper

The engine, explained stage by stage.

These posts document specific pipeline stages in production detail — the decisions made, the failure modes encountered, and how the engine handles them.

STAGES 1 + 2