Assisted Migration
We convert the estate, your team stays in the driving seat.
Assisted migration is the option most teams take. We do the conversion work, your engineers review it, and by the end your team owns pipelines they helped land rather than a black box someone else built.
The output is ordinary, readable engineering: SQL in version control, dbt models with tests, Airflow DAGs with real lineage. Anyone you hire next year can read it without learning a vendor's visual builder.
What you get
Deterministic transpiling for the bulk of the estate
Joins, filters, aggregations, unions, pivots, and the standard formula tools are converted by parser, not by hand and not by guesswork. This is the structural majority of a typical estate, and it converts predictably.
AI-assisted conversion for the dense logic
The bespoke formula tiles and nested business rules get AI-assisted conversion with a human engineer reviewing every output. Assisted, not automated: nothing ships because a model said it was fine.
dbt models with tests and documentation
Not just SQL in files. Models with schema tests, documented columns, and a dependency graph that renders. The documentation problem gets solved as a side effect of doing the migration properly.
Airflow orchestration matching your schedules
The existing schedule, ordering, and retry behaviour carried over into DAGs, integrated with the same sources the originals depended on, from SAP HANA delta loads to external APIs.
Your team in the loop throughout
Working sessions, code review, and handover as the work lands, not a document dump at the end. The point is that your engineers can maintain and extend this after we leave.
How it runs
- 1
Scope from the assessment
The inventory sets the scope, so the price and timeline are fixed before work starts. Dead and duplicate pipelines are retired rather than migrated.
- 2
Convert in phases
Work lands in phases by dependency order, so each slice is reviewable rather than arriving as one enormous change.
- 3
Review as we go
Your engineers review each phase. Anything that looks wrong gets caught while it is cheap to fix, not at the end.
- 4
Handover
Documentation, working sessions, and the version-controlled repository. You leave the engagement able to change your own pipelines.
Is this the right step for you?
Good fit
- Teams with engineering capacity who want to retain the knowledge in house
- Estates where in-flight development continues during the migration
- Organisations that need the migration phased around a business calendar
Probably not
- Teams with no engineering bandwidth to review. Take the full migration instead
- Estates that have not been assessed. The fixed price depends on the inventory
The other steps
Find out exactly what leaving would cost, before you commit to anything.
End to end delivery, with a diff report on every pipeline before cutover.
Not sure which applies? Read how it works end to end, or check the questions we get asked.
Find out what leaving would actually cost.
The lock-in assessment is free, takes two weeks, and needs read access. You keep the report whether or not you migrate.