Most data migration guidance assumes you are moving static, closed records. Case-management migrations are rarely that simple. A meaningful share of the records you need to move are still open: cases mid-review, documents awaiting sign-off, workflows halfway through a multi-stage approval. Get this wrong and you do not just lose data, you lose continuity of active work.

This is one of the hardest parts of any legacy replacement programme, and one of the least written about. Here is a practical playbook for doing it well.

Why open-case migration is different

Migrating a closed archive is a data problem. Migrating open cases is an operational problem wearing a data problem's clothes. Every open case has state: a current status, an assigned owner, pending tasks, partially completed reviews, and often documents sitting in a workflow queue. Move the data but lose the state, and staff arrive on the new system to find cases that look migrated but behave as if they have started from scratch.

The two migration approaches most commonly used for this kind of cutover are worth understanding clearly.

Hard cutover sets a fixed date, shuts down the legacy system, loads the data, and goes live with no overlap. It works well when data is clean, rehearsed, and downtime is tolerable, but it concentrates all risk into a single event.

Soft cutover, or parallel running, keeps both systems live for a defined period, letting staff validate the new system against the legacy one before the old system is switched off. It costs more in effort and duration but distributes risk rather than concentrating it. For active, open caseloads carrying regulatory or statutory weight, parallel running is almost always the safer route, and it is the pattern most public sector and regulated migrations now default to.

The playbook

1. Profile before you plan

Before deciding on a migration approach, get a genuine picture of the data: how many open cases, what stage each is at, what document volumes are attached, and where the inconsistencies and duplicates already sit. Legacy systems accumulate data quality issues over years, and migration is the point at which every one of them surfaces. Clean and standardise before you move, not after.

2. Map, don't assume

Field-by-field mapping between the legacy system and the new data model is unglamorous but essential. Case status values, in particular, rarely translate one-to-one. A status that means "awaiting senior review" in the old system may not have a direct equivalent in the new one, and that gap has to be resolved deliberately, not discovered in production.

3. Migrate in rehearsed phases, not a single leap

Run test migrations before the real one. Validate completeness and accuracy at each stage using automated checks, not manual spot-checks: record counts, field-level reconciliation on the highest-risk data, and referential integrity between related records such as cases, documents and contacts.

4. Run a genuine parallel period

For live regulatory or statutory caseloads, build in enough time to run the incumbent and new systems side by side. This is where the real value of the approach shows up: reconciling outputs between the two systems catches errors a technical test cannot, because it exposes cases where the business logic, not just the data, behaves differently.

5. Define exit criteria before you start, not at the end

Decide in advance what "ready to decommission the legacy system" actually means. A sensible exit condition includes a defined reconciliation threshold, a minimum period with zero unresolved critical defects, and a signed-off reconciliation report. Cutting over because a deadline has arrived, rather than because the exit criteria have been met, is how migrations quietly go wrong after go-live rather than during it.

6. Plan the rollback you hope never to use

Every migration plan needs a rollback path, however unlikely it is to be needed. For open cases specifically, that means being able to return staff to the legacy system without losing any work completed during the transition window.

7. Communicate like it is a service change, not a system change

‍ Staff working on open cases need to know, precisely, what happens to their in-progress work, when it happens, and what to do if something looks wrong on the other side. Migration communication that focuses only on "the new system is coming" and not on "here is what happens to what you are working on right now" tends to generate avoidable anxiety and support tickets.

What good looks like at the end

A well-run open-case migration is largely invisible to the people doing the casework. Their in-progress cases are where they left them, their tasks are still assigned, their documents are attached and correctly versioned, and the audit history behind each case is intact and traceable back through the legacy system if anyone ever needs to check it.

That invisibility is the actual measure of success. Migrations that generate noise, confusion or lost work in the weeks after go-live were rushed at the planning stage, not the execution stage. The organisations that get this right spend more time than feels necessary on profiling, mapping and rehearsal, and noticeably less time firefighting afterwards. Visit our solution for more.