The founder has built migration packs for these six pairs across prior engagements — meaning a codified rule library, deterministic translators, and a reconciliation harness specific to each, carried into every Replatform engagement. Other pairs are quoted case by case.
Cloud-to-cloud (AWS ↔ GCP ↔ Azure) and database moves to Postgres are bespoke — we still do them, but you pay for the bespoke rule-library work in the engagement, not for an off-the-shelf pack.
Every migration starts with the paid Discovery Sprint (₹2 – 3 L / $3 – 5k, 10 business days, 100% upfront). The Sprint delivers an inventory, a wave plan, an effort range, and a fixed Execution quote against a written Appendix A. Execution is milestone-billed (30% upfront / 40% mid / 30% on hypercare exit). Sign Execution within 60 days of the Sprint deliverable and the Combo discount applies — 5% off Execution.
Per wave, you receive a signed reconciliation report containing row-count parity, schema parity, deterministic checksum diffs on every table, and query-result diffs on a target sample of analytical queries. The report is generated by deterministic code — no model grades its own output. You keep it forever; your auditor reads it without us in the room.
We do not handle app-code rewrites against new APIs unrelated to the data layer, network procurement, end-user training programs, or vendor contract negotiation. If those are needed, we hand off to your team or a partner — never bundle billing for work that is not migration engineering.
What does "signed reconciliation evidence" actually mean? What document do we sign at cutover? ▾
Per wave you receive a reconciliation report: row-count parity per table, schema parity (column types, nullability, defaults), float-tolerant checksums on every migrated table, and query-result diffs on a target sample of analytical queries (typically the top 50 by frequency and the top 20 by cost). The report is generated by deterministic code — no model grades its own output. At cutover, your platform lead and ours co-sign the final reconciliation report; you keep it forever; your auditor reads it without us in the room.
We have been burned by a previous migration partner that left us with broken downstream consumers. How do you avoid that? ▾
Three structural safeguards. First, Discovery enumerates downstream consumers explicitly — dashboards, reverse-ETL feeds, ML pipelines, customer-facing reports — and each lands in the wave plan with a named owner. Second, the parallel-run phase keeps source and target alive in lockstep with daily diff reports until the consumer owners sign off individually. Third, the 90-day Scope Warranty: anything in-scope we missed during Discovery, we absorb during execution at the fixed fee. The economic incentive is aligned — surprises cost us, not you.
What source and target platforms do you cover today? Can you do Teradata → Databricks? ▾
Six pairs the founder has shipped end-to-end across prior roles carry a codified rule library: Redshift → Snowflake, Redshift → BigQuery, BigQuery → Databricks, Snowflake → Databricks, Teradata → BigQuery / Snowflake, and SSIS / Informatica → dbt + Airflow / Dagster. Teradata → Databricks is bespoke today; we will quote it but the rule-library work is built into the engagement rather than amortised across prior packs. Cloud-to-cloud (AWS ↔ GCP ↔ Azure) and database-to-Postgres are also bespoke.
How do you handle the parallel-run phase? How long is realistic? ▾
Parallel run is structured per wave, not per project. A typical wave parallel-runs for 2 – 4 weeks: source and target both populated, reconciliation reports generated daily, consumer owners signing off per-dashboard / per-pipeline. Aggressive timelines compress to 1 week if reconciliation comes out clean on day one; conservative regulated estates extend to 6 – 8 weeks per wave. Cutover only happens after the consumer owners individually sign off — not on a calendar date.
What is the typical project duration for a Snowflake → Databricks or BigQuery → Databricks at our size? ▾
Discovery Sprint is 10 business days fixed regardless of size. Execution is sized off the Discovery inventory. Mid-market data estates (200 – 800 tables, 1,000 – 5,000 dbt models, 20 – 60 downstream consumers) typically execute in 12 – 20 weeks. Smaller estates (under 200 tables) compress to 8 – 12 weeks. Larger estates (>1,000 tables, regulated, many consumers) extend to 24 – 32 weeks and wave more aggressively. The Discovery deliverable carries the specific number for your inventory with the reasoning shown.
Who owns the bug that surfaces in week 3 of cutover — you or us? ▾
It depends on what the bug is. If it is a translation error or a reconciliation miss on something in Discovery scope, we own it under the 90-day Scope Warranty at the fixed fee. If it is a downstream consumer behaving differently because of a legitimate platform semantics change that was documented in the Discovery report (e.g. Snowflake-style time-travel not existing on the target), the fix is yours but we support the consumer owner. If it is net-new scope (a table or pipeline that did not exist when Discovery closed), it is a change order priced before the work starts. The Discovery report makes the boundary explicit so this conversation is not improvised at week 3.
Do you sign a fixed-fee contract upfront or is it T&M with caps? ▾
Fixed fee. Discovery is fixed (₹2 – 3 L / $3 – 5k, 10 business days, 100% upfront). Execution is fixed against the written Appendix A produced by Discovery, milestone-billed 30% upfront / 40% mid / 30% on hypercare exit. Change orders for net-new scope are written and priced before any work begins; nothing is billed against a running clock. We do not run T&M because it misaligns the incentive — we are paid to ship the migration, not to bill hours.