Capability 01 / Migration
A migration is easy to start and hard to finish. The last 20% — the stored procedures nobody documented, the report that has to match to the penny, the cutover weekend — is where projects stall. That last 20% is the part we are actually good at.
What we move
Different platforms fail in different ways, so the migration is different each time. The destination is always the same: a governed Databricks lakehouse your team can run without us.
Log-based CDC lifts change out of the source without touching the transactional workload. PL/SQL and T-SQL logic is rebuilt as tested transformations rather than lifted verbatim.
We profile the warehouses to find what actually drives spend, then model those workloads on Databricks SQL and serverless jobs before anyone commits to a number.
Decades of BTEQ, macros and workload management, unwound carefully. We keep the semantics the business relies on and drop the platform-specific machinery that no longer earns its keep.
When the team that built it has moved on, we reverse-engineer what the cluster really does, decide what deserves to survive, and move only that. Most estates shrink by half on the way over.
The Python, shell and SSIS that quietly runs the business. We catalog it, find the critical path, and replace it with orchestrated, observable pipelines nobody is scared to change.
Most estates are. The assessment exists precisely to untangle a landscape that grew by accretion, and to tell you honestly which parts are worth moving this year.
Start with an assessmentWhy cutovers stall
They sign off on evidence. The single biggest reason a technically-finished migration never goes live is that no one can prove the new numbers match the old ones. So we build that proof first, and run it continuously.
Every table we migrate is reconciled against its source, row by row, on a schedule, with the results published somewhere your auditors and your CFO can both see. Parity is not a slide. It is a job that either passes or fails.
# Prove equivalence before anyone signs off a cutover.
from quasar.migrate import Reconciler
recon = Reconciler(
source = "snowflake://prod/finance.fact_orders",
target = "uc://prod.finance.fact_orders",
keys = ["order_id"],
# tolerate float drift, never tolerate row drift
numeric_tolerance = 1e-9,
)
report = recon.run(partition_by="order_date")
report.assert_no_missing_rows()
report.assert_column_parity(threshold=1.0)
report.publish("prod.audit.migration_evidence")
# example output: 41,882,113 rows compared - 0 mismatches - 6m 12sHow it runs
We build the workload everyone is most worried about at the start, not the end. Confidence is cheaper to buy early, and it is what keeps a multi-month program funded.
Query logs, schedules, lineage, volumes and spend. The real workload, not the diagram.
AssessmentUnity Catalog model, compute topology, ingestion pattern and cost envelope, reviewed with your architects.
AssessmentOne real workload, end to end, reconciled against the source. This is the proof of concept.
Weeks 3–8The Migration Factory handles the repetitive bulk under human review, wrapped in CI/CD.
Months 2–6Parallel run until the numbers match for long enough to be dull, then flip and train the team.
ContinuousStraight answers
Where it is safe. Our tooling converts the repetitive bulk — DDL, straightforward SQL, stored procedures with predictable shapes — and a senior engineer reviews all of it. We do not hand you a pile of machine-translated code and call it a migration. The hard 20% is done by people.
It stays live. We capture change without disrupting the transactional workload, land it on Delta, and run both systems in parallel. You decide when to switch the old one off — usually after weeks of the reconciliation job passing without drama.
We guarantee you will be able to see whether they do, table by table, on a schedule, with the evidence published. Where there is genuine drift — rounding, time zones, a source bug you were living with — we surface it and let you decide. Silent mismatches are the thing the whole method exists to prevent.
The assessment takes ten business days and tells you. Real migrations run from a few months to the better part of a year depending on the estate. We deliver in increments so you get value before the end, rather than a big-bang cutover you have to pray works.
Start here
Bring your current architecture, data volumes and the workloads that hurt. You leave with a target-state diagram on Databricks, the three changes that would cut the most cost or latency, and an honest answer on whether you need us at all.
No slide deck. No procurement process. One senior architect on the call.