Six data foundation gaps that derail transformation

Transformation programmes are usually announced with a technology story and abandoned with a data one.

The pattern repeats closely enough to be predictable. New platform selected, integration partner engaged, timeline agreed. Six months in, the programme is running late — not because the platform is wrong, but because the data being migrated into it turns out to be in worse condition than anybody said out loud.

This is a checklist for finding that out early, when it is still a scoping conversation rather than a delay.

Gap 1 — Data quality nobody has measured

Everyone knows the data is imperfect. Almost nobody knows by how much, which means it cannot be planned around.

Three numbers, per critical dataset, turn an opinion into a plan:

• Completeness — what percentage of records have the fields the new process actually requires?
• Consistency — how many records disagree with the same entity in another system?
• Currency — how old is the oldest record still treated as accurate?

Measuring these takes days, not months. Skipping them shifts the discovery to the migration, where it costs a great deal more.

Gap 2 — Silos that are organisational, not technical

Data silos are usually described as a systems problem. More often they are an ownership problem wearing a systems costume.

The test is straightforward: ask two departments who owns the customer record. If both answer “we do”, the integration project ahead of you is really a governance negotiation, and no amount of middleware resolves it.

Technical integration without that agreement produces a shared system that both sides continue to use differently — which is the same silo with a larger licence fee.

Gap 3 — Governance that exists as a document

Many organisations have a data governance policy. Fewer have governance, in the sense of decisions actually being made and enforced.

Three questions separate the two:

• Who decides what a field means when two departments disagree?
• What happens when a system writes data that violates a rule — is it rejected, flagged, or silently accepted?
• When did someone last review who has access to what?

If the honest answer to any of those is “nobody” or “we don’t know”, the policy is documentation rather than governance.

Gap 4 — Security and privacy treated as a later phase

For a Swiss or DACH programme, this gap is the one that changes architecture rather than just adding work.

revDSG/nDSG applies to personal data processed in Switzerland; GDPR applies wherever EU data is involved. Both require you to know where data sits and who can access it — and as covered in AI architecture: why data governance decides the outcome, the access question is the one that gets missed.

Two more that surface late and hurt:

• Retention. Transformation programmes love to migrate everything. Some of it you are obliged to delete, and migrating it forward re-starts the problem in the new system.
• Sub-processors. Your new platform has suppliers of its own. That chain is part of what you have to document.

Gap 5 — Integration capability that does not exist yet

Most programmes assume integration as a solved step. It is usually the largest unplanned cost.

The realistic questions, asked early:

• Can each source system expose its data through a stable interface, or does extraction mean a database read nobody supports?
• Is there an agreed identifier that lets records be matched across systems? If not, that reconciliation is a project of its own.
• What happens when the two systems disagree during the period both are live?

Where the answer is “the old system cannot expose this cleanly”, the integration question has become a modernization question — see application modernization.

Gap 6 — Skills assumed rather than confirmed

The last gap is the quietest. A plan is built assuming the team can deliver data engineering, pipeline operation and governance alongside its existing work.

That is usually two roles too many, and the shortfall appears at the worst point — mid-programme, when replacing the assumption takes a hiring cycle you do not have.

The realistic split: keep internally what requires knowledge of your business, and bring in externally what requires having done it several times before. That is the shape most dedicated team engagements take.

How to use this

Run it as a two-hour session before the programme is costed, with the six gaps as the agenda and a rule that “we think it’s fine” is not an answer — either there is a number or it is an open risk.

The output is a short list of things to measure. It is much cheaper than finding the same list in month six, and it materially changes what the programme should be scoped to do.

If you want a second pair of eyes on that assessment, book a call. No obligation.