Skip to content
Confidirect

Data and analytics engineering

Analytics engineering in dbt, legacy-to-cloud migrations with reconciliation, and the automation and integrations that keep pipelines running unattended.

Pipelines fail quietly. Reports drift. A migration finishes and nobody is quite sure whether the numbers still reconcile. Most of the cost in data engineering is not writing the first version; it is keeping it trustworthy after the people who built it have moved on.

This service line covers the build and the discipline around it: modelling, migrations, orchestration, integrations and the tests that catch problems before a decision-maker does.

What you get

Delivered, not recommended

  • Warehouse and semantic models in dbt with tests, documentation and lineage.
  • Migration plans with reconciliation: the old and new numbers are compared, and the differences are explained before cut-over.
  • Automation and integrations across Microsoft 365, Salesforce and internal systems, so pipelines run unattended.
  • CI for data: pull-request checks, scheduled runs and alerting through GitHub Actions or the platform's native tooling.

From the work

Automated

Forecast refresh, previously manual

Forecasting pipelines that replaced manual work

New Zealand government · same engagement

Forecasts were produced through manual processes: exports, re-keying and hand-built refreshes that depended on the people doing them and left little time for the forecast itself.

The manual processes were replaced: refreshes ran unattended, and the time that used to go into the mechanics went into the forecast instead.

Read the note

Questions

Asked before the first call

Which platforms do you work with?

Snowflake and Databricks for warehousing, dbt for modelling, Power BI for reporting, and the Microsoft 365 and Salesforce ecosystems for automation and integration. If your stack is different, the first conversation is the place to check fit.

How do you handle a migration without disrupting reporting?

Old and new run side by side for a period. Every report that matters is reconciled between the two, and the differences are documented and explained before anything is switched off.

Will my team be able to maintain what you build?

That is the point of the build. Models are documented and tested, the orchestration is visible, and handover includes working sessions with the people who will own it.

Next step

Start with the problem, not the service line.

Describe what is not working in a few lines. I reply personally with an honest view of whether this is the right engagement, or whether none of them is.