A migration is done when you have proven the data loaded correctly. The load finishing is only the setup for that proof. Loading the data is the setup for a specific set of checks you run at cutover, and those checks are the difference between knowing the migration held and hoping it did. Skip them and the gaps do not disappear. You just find them later, from a patient who cannot get an answer or a payer who rejects a claim, at the worst possible price. This is what real validation looks like, and why each piece is there. It sits inside the full picture in how to prepare for an AdvancedMD data migration. This is the proof step, in depth.
Why loading the data is not the finish line
It is tempting to call a migration done the moment the data lands, because the hard part looks finished and everyone is exhausted. But a load that completed is not the same as a load that is correct. Records can be dropped, duplicated, or subtly mangled in ways that look fine until something reaches for them, and the whole point of validation is to find those problems now, against known numbers, while they are cheap, rather than months later when a patient or a payer finds them for you. Validation is the step that turns a finished load into a migration you can trust.
Reconcile the counts, entity by entity
Start with the simplest check: did everything come across. The number of patients that loaded should match the number you sent, and the same holds for guarantors, appointments, coverage records, and providers. Do it entity by entity, not as one lump, because a total can look right while one category is short. A count that is off by even a little means something was dropped or duplicated in the load, and it is far easier to catch that now, against a known number you sent, than to notice months later that a slice of patients is missing.
Reconcile the money, to the dollar, by bucket
The financial reconciliation is the one that has to be exact. Whatever balances and open receivables you carried should match what you left behind, and they should match broken down by aging bucket, not as a single grand total. A grand total can match by accident while the buckets underneath it are wrong, and the buckets are what tell you where the money actually is. A balance that is close is a balance that is wrong, so reconcile to the dollar, not to the neighborhood, because close is exactly how a reconciliation passes while hiding an error that surfaces on a patient statement weeks later. The money side of the whole move is covered in what happens to your accounts receivable when you switch systems.
Confirm the schedule, forward and back
Your calendar has to arrive whole in both directions. The future appointments patients expect to keep have to be there, the recurring series that generate standing visits have to have regenerated, and any group or class visits have to have survived as groups rather than collapsing into single slots or scattering into separate ones. The past matters too, where your notes and history hang off it. An empty future calendar discovered on go-live morning is a practice that cannot see its own day, so check the schedule before the day it has to run, not on it.
Match the documents, then open some
Documents need two checks, because volume and usability are different things. First, the totals should line up, so you know the files that were supposed to move actually moved. Then someone opens a real sample of them, for real patients, to confirm they attached to the right chart, carry the right name, and can be found. Totals alone prove volume, not usability, and usability is the entire point of moving them. A count that matches while the files are a pile of look-alike names is a document move that passed on paper and failed in practice. The document job is covered in moving your documents to a new system.
Run the live tests, end to end
The last checks exercise the connections your revenue depends on, before it depends on them. Send a test batch of claims and watch them go out clean, reach the payer, and come back paid. Post a test remittance and confirm the payment lands where it should. Send a test statement and confirm it reads correctly. Run a real-time eligibility check and confirm it returns something. For a prescribing practice, send a test prescription. Each of these is a thing you would far rather find broken in a test than on your first live day, and each depends on setup and enrollment that were done earlier, covered in configuring a new system for a day-one go-live.
Write down what you checked
Validation is a record as much as a moment. Write down what you checked and what it showed, because months later, when a question arises about whether something came across, the answer is either a documented check you ran at cutover or a shrug and an afternoon of investigation. The practices that validate well keep the proof, because the proof is what lets them say, with confidence rather than hope, that the migration held. It also tells you, if a problem does surface, whether it was there at cutover or crept in afterward.
Validation is your go or no-go
The checks above do double duty. They are also the criteria for the decision you make before the switch becomes final. A cutover has a moment where you look at whether the load is clean and the configuration is ready and decide to proceed or to hold, and that decision needs criteria set in advance, because a go-live call made on the day under pressure, with a date already promised, is a call that says go no matter what the data says. Agree, before the weekend, on what the counts, the money, and the live tests have to show for you to proceed, and on what would make you hold. The practices that stop when they should stop are the ones who decided in advance what stopping would look like.
What skipping validation costs
Skip the checks, or reduce them to a glance, and every migration failure still happens. The difference is who finds it and when. Instead of catching a short balance against a known number at cutover, you hear about it from a patient weeks later. Instead of finding a payer whose setup rejects a whole claim type in a test, you find it in a wave of denials in your first live week. Instead of noticing a missing slice of patients today, you notice it months from now when one of them returns. Validation is cheap. The alternative is the same problems, discovered by the people you least want to discover them, at the price that hurts most.
A validation checklist
At cutover, these are the checks to run.
- Patient, guarantor, appointment, coverage, and provider counts reconcile to the numbers you sent, entity by entity.
- Carried balances and open receivables reconcile to the dollar, broken down by aging bucket, not as a grand total.
- Future appointments, recurring series, and group or class visits are all present and intact.
- Document totals line up, and a real sample opens to the right chart with the right name.
- A test claim goes out and comes back paid, a test remittance posts, a test statement reads correctly, and an eligibility check returns.
- Everything checked is written down, and the go or no-go criteria were agreed before the weekend.
If these pass, the migration held, and you can prove it. If they do not, you found out now, which is the whole reason to run them.
Common questions
What does it mean to validate a data migration?
It means proving the data loaded correctly. A load that finished and a load that is correct are different things. Validation is a set of checks run at cutover: reconciling record counts and financial balances, confirming the schedule and documents, and running live test transactions.
How do I check that a migration worked?
Reconcile record counts entity by entity against what you sent, reconcile balances to the dollar by aging bucket, confirm the schedule forward and back, match document totals and open a sample, and run live tests: a claim, a remittance, a statement, and an eligibility check. Then write down what you found.
How do I reconcile financial balances after a migration?
Match the balances and open receivables you carried to what you left behind, broken down by aging bucket rather than as a grand total. A grand total can match by accident while the buckets are wrong. Reconcile to the dollar, because a balance that is close is a balance that is wrong.
What should I check about the schedule after a migration?
That the future appointments patients expect are present, that recurring series regenerated, and that group or class visits survived as groups rather than collapsing or scattering. Check the past too, since notes hang off it. An empty future calendar found on go-live morning is a practice that cannot see its day.
How do I validate that documents migrated correctly?
Two checks. Confirm the totals line up so the files that should have moved did, then open a real sample for real patients to confirm they attached to the right chart, carry the right name, and can be found. Totals prove volume, opening them proves usability.
What live tests should I run at go-live?
Send a test claim and confirm it goes out clean and comes back paid, post a test remittance, send a test statement, and run a real-time eligibility check. For a prescribing practice, send a test prescription. Each exercises a connection your revenue depends on before it has to.
Why reconcile to the dollar instead of the total?
Because a grand total can match by accident while the aging buckets underneath it are wrong, and the buckets are what tell you where the money is. A balance that is close hides an error that surfaces later on a patient statement. Reconcile to the dollar, by bucket, not to the neighborhood.
Should validation criteria be set before cutover?
Yes. The validation checks are also your go or no-go criteria, and they have to be agreed before the weekend. A go-live decision made on the day under pressure, with a date already promised, says go no matter what the data shows. Decide in advance what would make you hold.
What happens if I skip migration validation?
The failures still happen, but a patient or a payer finds them instead of you, later and at a higher price. A short balance surfaces on a statement, a payer setup surfaces as a wave of denials, a missing slice of patients surfaces when one returns. Validation trades that for a check.
Why write down the validation results?
Because validation is also a record. Months later, when someone asks whether something came across, the answer is either a documented check from cutover or an afternoon of investigation. The written proof also tells you whether a problem was there at cutover or crept in afterward.
When is a migration actually done?
When the checks pass and you can prove it: counts reconciled, money reconciled to the dollar by bucket, schedule and documents confirmed, and live tests coming back clean. A completed load is not yet a finished migration. Validation is the step that closes the gap between the two.
Where this leaves you
A migration is done when you have checked that the data landed correctly and can prove it, and the load finishing is only the setup for that check. Run the counts, reconcile the money to the dollar, confirm the schedule and documents, and test the live connections, and you go live knowing the migration held instead of hoping.