Solutions
Four situations estates arrive in, and what we build for each
The system is always tailored, but the problems repeat. These are the four shapes of work we take on most often, along with the honest symptoms that tell you which one you are in.
Use case 01
Platform and warehouse migration
A migration is rarely blocked by moving the rows. It is blocked by the parts nobody can fully describe: the derived column whose logic lives in a stored procedure, the source that encodes missing values three different ways, the report that has quietly been wrong for two years. The system has to surface those before it moves anything.
You are probably here if
- The cutover plan depends on a reporting freeze the business will not agree to.
- Legacy transformation logic is only partly documented and the people who wrote it have moved on.
- A previous attempt stalled in reconciliation because differences could not be explained quickly enough.
- Parallel running is planned, but nobody has agreed in writing what counts as a match.
What the system does
- Profiles the legacy estate and reconstructs the effective transformation logic from the data as well as from the code.
- Maps legacy schema to target model field by field, with a confidence score and the supporting evidence attached to each mapping.
- Runs both platforms in parallel and reconciles on the full population, explaining each difference rather than counting them.
- Holds the cutover gate until reconciliation is clean, then keeps the harness in place as the ongoing regression check.
Use case 02
Legacy pipeline modernization
Most estates do not need a different platform. They need the pipelines they already depend on to stop consuming the team that maintains them. Modernization here means replacing brittle, hand-held transformation with a system that maintains itself inside limits you set, without pausing delivery while the work happens.
You are probably here if
- A large share of engineering capacity goes on keeping existing pipelines alive rather than building anything new.
- Business rules are spread across scripts, scheduled jobs and stored procedures with no single owner.
- Schema changes at a source are discovered downstream, usually by someone reading a report.
- Nobody will change a transformation because the blast radius cannot be established in advance.
What the system does
- Extracts the rules currently buried in scripts and rewrites them as versioned, testable artefacts with named owners.
- Replaces scheduled optimism with change detection at ingestion, so drift is caught before transformation runs.
- Introduces replay, so a rule change can be tested against historical runs before it reaches production.
- Migrates pipeline by pipeline, leaving the legacy path live until the new one reconciles against it.
Use case 03
Data quality remediation
Quality problems are rarely random. They are the residue of systems merged, replaced or extended without a shared definition. Remediation that only clears the current backlog leaves the mechanism intact, so the backlog returns. We correct the records and then close the path that produced them.
You are probably here if
- The same reconciliation break is corrected by hand every period.
- Acquired or inherited systems use different identifiers for the same customer, policy or product.
- Two reports disagree, and settling which one is right takes longer than producing either.
- Quality is measured after publication, when it is measured at all.
What the system does
- Profiles every source to establish what the data actually contains, including the conventions nobody wrote down.
- Proposes normalisation and matching rules with the evidence behind them, applied only once your team has reviewed them.
- Quarantines records it cannot resolve, with the failing rule attached, rather than passing them through or silently dropping them.
- Moves the checks upstream of publication, so bad records are stopped at the boundary instead of reported afterwards.
Use case 04
Analytics enablement
Analysts who spend the week reshaping exports are not doing analysis. Enablement means the modelled, validated, documented data they need is already waiting, and that it is trustworthy enough that nobody rebuilds it in a spreadsheet to be sure.
You are probably here if
- Analysts keep private copies of the data because the shared version cannot be relied on.
- The same metric is calculated three different ways in three different places.
- Every new question needs an engineering ticket and a place in a queue.
- Dashboards break quietly, and the first signal is a person noticing something looks wrong.
What the system does
- Lands a conformed model per domain, with definitions agreed in writing and versioned alongside the transformation rules.
- Validates freshness, volume and distribution before publication, so a broken upstream does not become a confident dashboard.
- Publishes lineage, so an analyst can trace any field back to its source column without asking an engineer.
- Onboards new sources as a mapping exercise against the existing model rather than as another pipeline build.
Engagement models
Four ways to work with us, all of which end with you owning the system
The model changes who operates the system and for how long. It does not change who owns the rules, the code and the documentation at the end, which is always you.
- Model 01
Discovery engagement
A fixed-scope profiling and design phase. We connect read-only to your sources, establish what is actually there, and deliver the target model, transformation rules, validation thresholds and escalation policy as a written design with a costed build plan.
Suited to
Teams that need a defensible plan and an honest scope before committing budget. The design is yours whether or not we build it.
- Model 02
Build and transfer
We build the system against your estate, run it in supervised mode until it earns autonomy source by source, then hand it over with documentation, runbooks, deployment configuration and full access. We stay available through an agreed stabilisation period.
Suited to
Organisations with an engineering team that intends to own the system permanently.
- Model 03
Operated system
We build the system and then run it as an ongoing service, with agreed availability, exception handling and reporting into your team. Ownership of the code and the rules still transfers to you, so the arrangement can end without a rebuild.
Suited to
Estates where the internal team is small, the workload is seasonal, or the transformation work is not the team's core mandate.
- Model 04
Partner delivery
We work behind consultancies and systems integrators as the autonomous transformation layer inside a larger programme, under your delivery governance and to your client-facing commitments.
Suited to
Partners who own the client relationship and the wider programme, and need the data transformation workstream to be predictable.
Not sure which of these describes your estate?
Most are a mixture. Describe what is actually happening and we will tell you which shape of work it is, and whether a discovery engagement is worth running at all.