Proving a data warehouse migration

We build the reconciler before the converter

A migration is finished when equivalence can be demonstrated to someone who was never on the project.

Talk to us about a migration
See the five phases

We sequence the work around that definition. Before any code is converted, we agree with the client, in writing, what “the same results” means. That agreement becomes the acceptance criterion for the whole programme. We build the mechanism that proves equivalence first, and the mechanism that moves and translates the data second.

When the converter comes first, a programme can reach cutover without anyone having agreed what a correct result looks like.

Agreed first, in writing

Equivalence criteria

Built first
1

The reconciler

Proves the old and new systems give the same results

Built second
2

The converter

Moves and translates code, tables and reports

Reconciliation built before conversion, with equivalence criteria agreed above both.

The risk a Head of Data carries is not a slow migration. It is one that cannot be proved.

Why the order matters in a regulated environment

For a bank moving a data warehouse from an on-premises solution to cloud, reporting to the national regulator and to the European Central Bank continues throughout the migration. The old system and the new one have to answer the same questions, for the same reporting periods, until the new one can be trusted.

In that setting, a discrepancy between the two systems becomes a compliance issue, with a reporting deadline attached.

The five phases

1

PHASE

01

Define equivalence

Before anything moves, four questions get answered and written down:
  • Same to the last unit of currency, or within an agreed tolerance?
  • Same for the current reporting period, or for the full history held in the source?
  • Same for the regulatory submission, or for every internal report built on top of it?
  • Who signs that it matched: the client’s test lead, or ours?

Settled at the start of a programme, these questions take a working session. Left open until the end, they can take months to resolve.

PHASE

02

Build the reconciliation

An automated comparison between the two systems, designed against the definitions agreed in phase 1. It runs repeatedly throughout the programme, and each run records what matched and what did not, instead of returning a single pass or fail.

PHASE

03

Convert

Code, tables and reports move to the new platform. Most migration tools, and most of the attention in the market, focus on this phase: speed, automation, AI assistance. On its own, conversion does not show that the new system produces the right results.

PHASE

04

Run in parallel

Both systems process the same reporting periods side by side until the results agree, and keep agreeing. The parallel run is rarely in the original business case. It costs far less than the alternative: finding a discrepancy after cutover, when the source system has been decommissioned and there is nothing left to compare against.

PHASE

05

Accept

We run the criteria agreed in phase 1, produce the evidence, and the client’s own test lead signs. The programme closes when the result has been demonstrated, rather than on a go-live date.

What a test lead actually signs

Four kinds of evidence, defined before conversion starts:

Row counts

Reconciled per source and per period. Totals per table can hide offsetting differences that cancel each other out.

Balance totals

That tie to the regulatory submission, not to an internal report built on top of it.

A documented exception list

What differs, why it differs, and who accepted it.

A repeatable run

So the proof can be produced again after go-live, for an auditor or for the regulator.

When these are agreed before conversion, they work as acceptance criteria.

When they are first put together at cutover, they tend to become points of dispute.

Where this comes from

Our consultants run this pattern on data warehouse migrations for banks, moving from on-premises solutions to cloud while regulatory reporting continues. We deliver into banking data teams in Romania, Poland, Austria, Germany and Switzerland.

  • 🇷🇴 Romania
  • 🇵🇱 Poland
  • 🇦🇹 Austria
  • 🇩🇪 Germany
  • 🇨🇭 Switzerland

Our consultants work embedded in the client’s own data teams, and delivery is supported by five ISO certifications:

  • ISO 9001 – Quality Management
  • ISO 27001 – Information Security Management
  • ISO 20000-1 – IT Service Management
  • ISO 27701 – Security Techniques
  • ISO 22301 – Business Continuity Management System
More information
What a client is left with
A set of acceptance criteria the client can run themselves, after our team has left.

The migration can be proved again without the people who performed it.

We always deliver. Expert Data Services.

We help you stay on top of your data for a successful business, so buckle up and ride the data journey with us.

Talk to us about a migration you are planning

Case studies

Migrating Without Missing a Beat: A New Data Warehouse Foundation for a Banking Controlling Team

Client: Leading Banking Institution
When the migration to the new DWH began, IDS took on the task of carrying that Datamart — and the business logic behind it — onto the new platform.
Read more

From Hadoop to Databricks: Scaling a Banking Data Platform Beyond Its Limits

Client: Banking Client
IDS Consulting was brought in to provide hands-on technical support and consultancy for the migration to Databricks.
Read more

From Days to Minutes: An 8-Year Data Warehouse Transformation for a Leading Telecom Operator

Client: Leading Telecom Operator
IDS Consulting was brought in not for a single fix, but as an ongoing extension of the client’s Data Warehouse team. The mandate: modernize how data moved through the platform, and keep it evolving safely as the business — and the underlying infrastructure — kept changing around it.
Read more

Network Analytics, Migrated to the Cloud

Client: A national telecom operator
IDS architected a cloud-native network analytics platform on BigQuery and Dataflow, built for streaming ingestion at telco scale, replacing nightly batch loads with near-real-time processing of network events.
Read more

Subscriber Analytics, Migrated from Cognos to Power BI

Client: A regional mobile network operator
IDS’s BI team was engaged after a referral from a data platform vendor, specifically for its documented migration path from Cognos to Power BI.
Read more

Governance Foundations Before a Core Migration

Client: A Tier-1 CEE retail & corporate bank
IDS was introduced through the bank’s existing Data Platform & Engineering vendor shortlist, specifically for governance-first migration experience in regulated environments.
Read more

Tell us about the migration you are planning

Where is your data warehouse today, where is it moving, and which reporting has to keep running during the move? We will come back to you with how we would define equivalence for your programme.
Contact