Every data migration VE3 has delivered has, sooner or later, come down to one question asked in a slightly worried voice: what happens to our reporting while we switch over?

It's the right question, and most programmes answer it far too late. Here's the truth we'd want any leader to start from: for most organisations the warehouse isn't a system, it's a dependency. Statutory submissions run on it. Funding decisions lean on it. Daily operations assume it's there. You don't get to take that offline for a weekend and hope. Which is why we'll state the principle plainly - data migration business continuity is not a phase you bolt on at the end. It's a design constraint you accept on day one, or you've already lost.

And the stakes are climbing. Reporting cadences are tightening - the shift to in-year statutory collection under HESA Data Futures pulled a whole sector out of comfortable annual cycles - while peak windows like admissions and Clearing compress enormous load into a handful of weeks. Migrate carelessly into one of those, and the cost isn't a technical inconvenience to explain away in a stand-up. It's a missed regulatory deadline with your name on it. So here is how VE3 keeps reporting running while everything underneath it changes.

The principle: you earn the cutover, you don't schedule it

Everything below flows from one idea, and it's worth internalising before the tactics: you migrate the capability while keeping the legacy platform trustworthy and available until the new one has genuinely earned its place. Note the word - earned. Trust comes from evidence, not from the fact that the project plan says cutover is due on the 14th. Build the programme around that distinction and continuity stops being a worry and becomes a property of the design.

Map the reporting calendar before you touch anything

We'd start here, and it's not with technology. Before sequencing a single piece of work, map the organisation's reporting calendar in full: statutory deadlines, regulatory windows, financial close, and the operational peaks where concurrency spikes. That calendar is the master constraint everything else bends around. Cutovers, code freezes and go-live dates get planned into the gaps, never across the deadlines.

We've watched teams treat the calendar as a detail to reconcile later. It isn't. A cutover sequenced into a peak reporting week is a self-inflicted wound; the same cutover dropped into the quiet stretch between cycles is barely noticed. Same work, entirely different outcome - and the only variable is whether someone respected the calendar first.

Run old and new in parallel - this is non-negotiable

If there's one technique VE3 would never let a programme skip, it's parallel running. For a defined period, the legacy warehouse and the new platform run side by side, fed the same data, producing the same outputs. The legacy system keeps serving live reporting the entire time, so there is never a moment where the organisation is flying blind. Parallel running is what converts "we're fairly confident the new platform is right" into "we've proven it is" - and those are very different sentences to be saying the week before a statutory submission.

Reconcile relentlessly, and make the data owner sign

Parallel running is only worth as much as the comparison you make off the back of it, and this is where corners get cut under time pressure. Don't. Reconcile old and new across every layer that matters, each with an explicit, agreed tolerance: structure and schema, row counts, column-level content, key integrity, and - the one the business actually cares about - the real metrics and the most-used reports, compared side by side.

Then hold the line on the rule that protects you: nothing is approved for cutover until the technical layers stay steady for an agreed period and the relevant data owner has personally signed off the report comparison. Reconciliation isn't a tick-box at the end of the project. It's the evidence base for the entire transition, and it's what lets you decommission the old platform without a knot in your stomach.

Cut over in waves, never in one leap

We'll be direct about the big-bang cutover: it's the approach that produces the horror stories, and it's almost never necessary. Move to production domain by domain, in calendar-aware waves, so risk is contained to one area at a time and each wave is planned around its own reporting cycle. Cut the finance domain over after year-end; move the student domain outside the admissions peak. Each wave is reconciled and signed off before the next begins, so when something does surface - and on a real estate, something always does - it surfaces small, contained and recoverable, rather than everywhere at once on a single terrifying weekend.

Keep the legacy alive, read-only, as your safety net

Resist the urge to switch off the old platform the moment a wave goes live. Keep it available in read-only mode for a defined period after each cutover, so that if a material issue emerges you can fall back to a known-good source while you resolve it. Decommissioning happens when trust is genuinely established - not on the day cutover completes. This is the difference, in practice, between a cutover that's a reversible decision and one that's a leap off a cliff with the rope still being tied.

Plan the rollback before you need it - not during

Put bluntly: a rollback you improvise under pressure is not a rollback, it's a panic. Before each wave, document the rollback plan explicitly, with clear recovery objectives - how fast you can revert, and how much data you could lose in a worst case. The modern tooling is genuinely good here; version control and warehouse time-travel make reverting both code and data far more controlled than anything the legacy estate offered. And there's a softer benefit that matters more than people admit: a documented, tested rollback is what lets nervous stakeholders actually approve the cutover. Confidence is a deliverable.

Communicate, govern, and stay close after go-live

Continuity is as much organisational as technical, and this is where good engineering programmes still come unstuck. Nobody should ever be surprised by a cutover. Agree the sequence and the freeze windows through a change-governance forum, and communicate plainly to the teams who own the affected reports. Then, immediately after each go-live, VE3 stays close - a period of heightened hypercare, with real monitoring and a direct line to the delivery team - so the inevitable first-week questions get answered before they harden into incidents.

A word on statutory and regulated reporting

Statutory reporting raises the stakes for a simple reason: the deadline is fixed by someone other than you, and missing it has consequences you can't negotiate. Whether it's in-year returns under HESA Data Futures, performance reporting in a regulated sector, or financial and compliance submissions, the discipline is the same. Identify the immovable deadlines first. Never cut over near them. Reconcile the statutory outputs explicitly as part of sign-off - not as a general assurance, but line by line. And keep the legacy available until the new platform has produced a clean submission cycle of its own. We wouldn't retire the old system a day before that.

The mistakes we see again and again

For all the nuance, the failures are remarkably consistent: the big-bang cutover with no fallback; going live into a peak or statutory window; rushing or skipping the parallel run; decommissioning the legacy before trust is earned; treating rollback as an afterthought; and springing the switch-over on a business that wasn't prepared for it. Every safeguard above exists because VE3 has seen the cost of its absence.

Get this right and the headline is wonderfully boring: the migration happened, the deadlines were met, and most of the organisation barely noticed. In this particular discipline, boring is the highest compliment there is.

Migrating around a fixed reporting calendar? Talk to VE3 about a continuity-first migration plan that sequences cutover around your statutory and peak windows.