What Happens to Your Data When You Modernize a Legacy System?

One of the harder parts of modernizing a legacy system is figuring out how much of the business actually lives inside it.

Take a claims system that's been in place for fifteen years. Over time, developers have added rules for which claims need additional review, how documents get routed, and how exceptions are handled. Some were documented. Others were added to solve a problem and never revisited. The people who wrote them may be long gone.

When it's time to replace the system, getting the data across accurately is a major priority. But the rules governing that data need to make the trip too.

A claim can have all the right information and still move through the wrong process. A required review gets missed, the claim gets paid, and nothing in the new system flags a problem. The records are where they belong, and the numbers add up.

That's why modernization needs the people who understand how the business actually operates. 

They often know the exceptions and unwritten rules that the data alone cannot tell you.

‍

What actually happens to your data during a system migration?

A migration moves your records, and whether it also moves the behavior attached to them depends on how much of that behavior was written into the old application.

Most of the work happens in a mapping document, which lists what each field in the old database becomes in the new one. Building it is more interpretive than it sounds. A developer reads a column, works out what it holds from the values inside, and picks a destination. Many columns have an obvious match, and the ones that don't often end up with a default value or in a free-text field that nothing reads.

Relationships are the harder case. If two records were connected through a reference the old application kept track of, and the database itself never enforced it, there may be nothing for a mapping script to follow. The records all arrive. The connection between them doesn't, and no error gets raised, because nothing was technically violated.

Some of this is well documented in the public sector. The Department of Veterans Affairs has been moving off its legacy health record since October 2020, and it publishes its own harm accounting. By August 2025 it had logged 4,601 cases where the new records system played a role in patient harm, 10 of them catastrophic and 46 major, with six confirmed deaths. In one case in Columbus in September 2022, a prescription the system identified as belonging to a 77-year-old cancer patient had been routed to a veteran in another state. He received his antibiotics 36 hours late and died eight days later, and the VA classified the delay as catastrophic.

Problems like that don't present as system failures. They present as records sitting in the right place pointing at the wrong people, which operations monitoring isn't built to notice.

‍

Which records should you migrate and which should you leave behind?

Deciding what moves is a business question, and it helps to answer it before the migration gets scoped, because every record that comes across has to be checked by a person.

The default is to move everything, which is understandable. Deleting records feels riskier than carrying them, and the cost of carrying them doesn't show up until verification starts. Going by category usually produces a shorter list:

• Active records. Anything an open workflow touches. These move first and get checked most carefully.
• Closed records inside retention. These stay available, though an archive the new system can read will often do.
• Closed records past retention. Confirm the obligation with legal, then stop paying to carry them.
• Duplicates, test data and discontinued programs. Keep the history reachable, and skip rebuilding the rules that served it.
• Anything the team can't identify. A table whose purpose the team can't state is worth a conversation before it moves.

Whatever does come along is worth cleaning first, at least in the fields the new system will make decisions with. A phone number stored four different ways is read by a person, who interprets all four correctly without noticing. A status code is read by a rule, and a rule applies whatever it finds, so a code meaning two things in two systems can approve something the old process would have held. Clean the identifiers, the status codes and the dates that drive a workflow, and do it before the move, because messy data landing in a new system becomes the new system's problem. Settling whether you're doing a rebuild or refactor first makes the scope easier to set.

‍

How do you verify migrated data against the old system?

Verification works best in batches, compared against the old system while it's still running.

A row count is usually the first check and a reasonable place to start. It doesn't tell you much on its own, though, because a migration can move every record and still change what some of them mean. The checks that tend to find real problems compare decisions rather than volume:

1. Counts broken out by category. Record counts per status, per product line, per year, so a gap shows up where it happened.
2. Financial and quantity totals. Balances, claim amounts and inventory counts, reconciled to the cent.
3. Field-level sampling. A few dozen records per category, read side by side by a person who knows what they should say.
4. Business rule replay. The same inputs run through both systems and the decisions compared, which is the check most likely to catch a status code the new system reads differently.
5. Deliberate edge cases. The oldest record, the largest, the one with blank fields, the one your team already knows is strange.
6. Referential integrity. Confirm child records still point at the right parents, including the connections the old database never enforced.

Running these per batch keeps the cost manageable, and it means the old system stays available longer than most schedules assume.

‍

Who signs off before the business relies on migrated data?

The people who can confirm the data is right are the ones who work with it every day, and they're usually not part of the migration team.

A developer can confirm the records transferred, and that's a real claim about the move. Whether a balance is correct, or a status still means what it used to, is a different question, and the person who handles those claims every week can answer it. They also tend to know the exceptions, which is the part no amount of reconciliation will surface on its own.

Asking whether the data looks fine won't get you much, partly because the person you're asking knows the go-live date too. Something specific works better:

• The record counts for their area match what they expected
• The balances, totals or quantities are correct
• Status values still mean what they meant in the old system
• The exceptions they already know about still look the way they should
• They can find a record they know well, searching the way they normally would

Put the result in writing, with a date, per category. It's a small amount of paperwork that gives the team something to point at later.

When that step gets skipped, the verification still happens. It just happens later, through the people using the system. A former VA primary care doctor described renewing a morphine prescription in the new record and finding it had recorded double the dose she entered. The patient caught it, because the pills were a different color.

‍

How does Big Pixel protect client data during a rebuild?

We treat the migration as its own piece of work, with its own plan and its own testing, rather than as a step inside the build.

The mapping gets reviewed with the client before anything moves, so the interpretive calls in it come from people who know the business rules. Each batch is reconciled against the source while that source is still live. Old and new run side by side while each piece is proven, and every release is coordinated to protect existing data. We also keep a restore path that works without the new platform, since a backup you can only reach through the system you're migrating to isn't much of a backup.

For ComplianceDashboard we replaced a twelve-year-old platform with a custom compliance management system, and it started with a deep audit of the old one. Lesley Marling, VP at ComplianceDashboard, says the team "took the time to explain complicated features in a way that allowed us to make informed decisions." That matters on a migration, because the client is the one who has to confirm the data is right.

We believe that business is built on transparency and trust, and that good software is built the same way, which during a migration means you read the reconciliation results yourself.

‍

What should you check before decommissioning a legacy system?

Before the old system goes dark, it's worth confirming you can answer a question about last year using only the new one.

• Every data category has a written sign-off with a name and a date
• A read-only copy or full export of the old system is retained for a stated period
• Your team can produce an audit trail for a record that migrated

All of this adds time to a schedule that's probably already tight, and on a project with a regulatory date some of it may have to narrow. Sampling can focus on the categories carrying money or protected data, and rule replay on the workflows an auditor would ask about. The sign-off is the part worth keeping at full strength, because the old system is the only place that can settle a disagreement about what a rule used to say.

If you're scoping a modernization now, the first step is a small one. Pick one category of data, pull fifty records from each system, and sit down with the person who works with them. They'll tell you in an hour what a reconciliation report would take weeks to find.