Thirty Days of Doubt: Rebuilding Trust in Data After the Migration Party Ends

The ribbon is cut, the post-mortem deck is circulated, and the delivery team disperses to its next engagement. For a fortnight, everything appears to work. Then a finance analyst notices that the monthly position no longer ties to the ledger, an operations manager discovers that overnight refresh has slipped by ninety minutes, and someone asks why a former contractor still has read access to the customer warehouse. None of these is a catastrophe on its own. Together they describe the familiar shape of a migration that was declared complete before it was actually finished.

The thirty days after cutover are the least glamorous and most consequential phase of any data migration. They are also the phase least likely to be resourced, because the budget was framed around delivery rather than assurance. What follows is a practical reconciliation programme for UK data teams, designed to be run by a small group of two or three people over four working weeks.

Week one: prove the rows, not the pipeline

The first instinct after go-live is to check that jobs are green. Green jobs tell you that something ran; they say nothing about whether the right rows arrived. Begin instead with row-level reconciliation against the legacy source, held in read-only mode for exactly this purpose.

Select a set of anchor tables: the ones that feed statutory reporting, revenue recognition, or customer-facing commitments. For each, compare record counts, then checksums on a small number of business-critical columns rather than the whole table. A count of ninety-eight thousand against an expected ninety-eight thousand and forty is more informative than a clean dashboard, because it forces a conversation about the forty.

Pay particular attention to three classes of loss that pipelines rarely detect:

• Soft deletes. Legacy systems often carried logically deleted records that extract logic filtered out. Decide explicitly whether their absence is correct.
• Null semantics. An empty string in the old system may have meant 'not applicable'; in the new one it may mean 'unknown'. These are different facts and downstream logic will treat them differently.
• Late-arriving records. If the migration ran against a snapshot, anything that landed between snapshot and cutover sits in a gap that nobody owns.

Document each discrepancy with a disposition: accepted, corrected, or scheduled. A short register in a shared document is sufficient. The point is not perfection but an auditable account of what is different and why.

Week two: follow the permissions and the clock

Access is the quietest source of post-migration risk. Migrations typically preserve the technical ability to reach data while quietly altering the population of people who can. Service accounts may have been recreated with broader grants to unblock delivery. Role mappings may have collapsed several legacy groups into one. Departing staff whose access was scheduled for removal in the old system may find themselves re-provisioned by a bulk import that did not consult the leavers list.

A half-day exercise will usually surface the worst of it. Extract the current entitlement list, compare it against the joiner-mover-leaver record for the preceding six months, and look for two patterns: accounts with access but no current employment relationship, and individuals holding materially more access than their role requires. Both are governance findings, and both are considerably easier to remediate in week two than in the middle of an audit.

The clock deserves equal scrutiny. Refresh timings rarely survive migration intact, because schedulers, time zones, and dependency chains all change. Interview the people who consume the data first thing in the morning: the operations lead who checks stock positions, the finance analyst preparing the daily cash view, the clinician reviewing the overnight admissions summary. Ask what time they actually need the data and what time it now arrives. A two-hour slippage that appears trivial in a technical runbook can quietly invalidate a daily decision cycle.

Week three: map what depends on what

The dependency map drawn during design describes the intended architecture. It is almost never the map that operations inherit. Week three is the moment to build the real one.

Take a sample of five to ten reports or extracts that matter to the business and trace each backwards to its sources. Record every intermediate step: staging tables, transformation scripts, manual adjustments, the spreadsheet someone maintains on the side. The purpose is not to document the estate comprehensively but to expose the informal joins that nobody planned.

Two questions should govern this work. First, which dependencies are undocumented and who would notice if they broke? Second, which dependencies were meant to be retired at cutover and are still running?

Typical findings include a scheduled extract still pointed at a decommissioned server that happens to be reachable, a reporting layer reading from a table that is no longer refreshed, and a reconciliation spreadsheet maintained by one person in a regional office. Each is a latent failure with a name attached.

Week four: account for cost drift and hand over properly

Cloud migrations frequently produce a billing surprise that arrives in the second month. Storage tiers may have been set conservatively during parallel running and never revisited. Duplicate copies retained for validation continue to accrue charges long after validation finished. Query patterns change, and a warehouse optimised for batch loading may be poorly shaped for the interactive use it now receives.

Compare the first full month's consumption against the modelled estimate, line by line, and identify the three largest variances. In most cases one of them will be an oversight rather than a design flaw, and correcting it early prevents it from becoming an accepted baseline.

Finally, the handover. This is the step most frequently reduced to a document drop. A genuine handover involves the operations team owning the reconciliation register, the access review schedule, the dependency map and the cost baseline, and confirming that ownership in writing. It should include a named individual for each, a first review date, and an agreed definition of what 'steady state' means for this platform.

Consider a short closure note circulated to the steering group at day thirty, listing what was verified, what was accepted as different, what remains outstanding, and who owns each item. It takes an hour to write and it converts an ambiguous ending into a defensible one.

The discipline of the day after

Migration assurance is not a technical problem so much as a scheduling one. The checks are well understood; the difficulty is insisting they happen after the celebration, when attention and budget have both moved on. A thirty-day window, four weeks of structured work and a written closure note are modest commitments. They are also the difference between a migration that was delivered and one that can be trusted. For UK data leaders preparing for the next platform change, the argument for building this phase into the plan from the outset is straightforward: the cost of discovery in month two is always higher than the cost of verification in week two.