A migration forces a set of choices on you, and it runs as four separate jobs. Every one of them is cheaper made deliberately, up front, than discovered in the middle of the move. This is the single readiness list to run before your data leaves the old system.
It follows the way a migration actually splits: the decisions, the data, the money, the documents, the configuration, the enrollments, the credentialing, the timeline, and the proof. Each area points to a deeper guide when you want the detail. It all sits under how to prepare for an AdvancedMD data migration.
How to use this checklist
This is a list for the start of a migration, not the end. You are ready to begin the move, not to finish it, when the items below are true.
Work down it before your real export leaves the old system. Treat anything still open as a decision to make now, rather than a surprise to hit later. If most of these are not yet settled, you are not behind. You are at the planning stage, which is the cheaper place to still be.
The decisions, written down
A migration turns on a handful of choices, and each is cheaper made on purpose than discovered mid-move.
- The rule for which patients come across is written down, specific enough that two people would apply it the same way.
- The cutover date is chosen, and the freeze window around it is planned, including where new work goes during the freeze.
- You have decided whether to run the old system in parallel for a stretch or to hard-cut on the date.
- Each of the four jobs has a named owner, in writing. That includes the documents, the piece that falls through when ownership is vague.
The data is ready to leave
Before the real export, you know what you have and it is fit to move.
- A full test export has been pulled from the old system and examined, so you know what comes out cleanly, what fights you, and what is missing.
- The data has been cleaned: duplicates merged, terminated insurance companies and dead test accounts cleared, before the file is handed over.
- You have confirmed how your data actually comes out of the old system, and what the export includes.
The money has a plan
The financial side is the most expensive thing to leave to chance, because balances move but the history behind them usually does not.
- You have decided how far to run down the open receivables, the money still owed to you, and by when, so little live money is left to strand.
- A billing cutoff line is set and the team knows it, so the receivables you are emptying stop refilling.
- Credits, unapplied payments, and refunds in flight, the ones already being processed, are resolved rather than carried across.
- The near-deadline claims, the bills you send the insurer, are identified, so a freeze cannot age them past timely filing, the insurer’s deadline for sending a claim.
- Where the closed history will live is decided, and confirmed readable and searchable for the full retention period.
The detail is in what happens to the money owed you when you switch systems. If you are still weighing which system to move to, start with what practice management systems do and what to weigh before you switch.
The documents have an owner and a plan
The largest volume you own sits outside the conversion and needs its own track.
- The documents have a named owner and their own timeline, running in parallel from the start.
- A test export has been checked to see whether the patient link and document type come with each file.
- The filing structure is decided, by document type and by who will need each kind.
- You have decided whether the archive will be searchable text or flat images.
- Orphaned files, duplicate scans, and any records under legal hold are accounted for.
The detail is in moving your documents to a new system.
The configuration is far enough along
The new system has to be set up before the data lands, because the data points at the setup.
- Insurance companies, the payers your claims go out to, are set up with the right claim and coverage-check identifiers, not one assumed to cover both.
- Fee schedules hold each insurer’s contracted rate, and any discount or self-pay schedule exists.
- Codes, modifiers, and places of service match how you bill, including current telehealth rules.
- Financial classes, adjustment reasons, and aging buckets, which sort balances by how old they are, reflect how you read your numbers.
- Scheduling, clinical templates, claim scrubbing (the automatic check a claim passes before it is sent), statements, and user permissions are set up, not left as defaults.
The detail is in configuring a new system for a day-one go-live.
The outside enrollments are filed
These run through outside parties on their own clock, so they set your timeline and have to start first.
- Every electronic connection is inventoried: claims, payment reports (the insurer’s electronic explanation of a payment), payments, coverage checks, prescribing, labs, and the portal.
- All of them are filed, not queued for later, with an owner tracking each queue.
- Controlled-substance prescribing enrollment is started, if your providers write them, since it is usually the slowest.
- The bank verification for electronic payment is underway, not assumed instant.
The detail is in filing your outside enrollments when you switch systems.
The credentialing is confirmed
A provider’s standing with each insurer lives outside the software, and no setup fixes a gap in it.
- Each provider is confirmed enrolled with each insurer, at each location, with the effective dates right.
- You have not assumed a provider is enrolled at a new location just because they were enrolled somewhere else.
- Where care is delivered by one provider and billed under another, the rules are matched insurer by insurer.
The detail is in provider credentialing and enrollment across locations.
The timeline is real
A date holds when it is set from the drivers, not from hope.
- The go-live date is set backward from the slowest enrollment in sight, with room to spare.
- It is set around your own calendar, not the week of your heaviest billing run or your busiest season.
- The parallel jobs, the data, the documents, and the configuration, are scoped and owned, not assumed.
The detail is in how long a practice management migration takes.
You know how you will prove it worked
Decide what proof looks like before go-live, or you will go live on hope.
- The validation checklist is written: the counts and financial buckets you will reconcile, the schedule checks, the document checks, and the live tests you will run.
- The go or no-go criteria are agreed before the cutover weekend, so a date that turns out wrong can be held rather than forced.
The detail is in validating a system migration.
The people are told, and the budget covers four jobs
The cheapest parts of a migration are also the most visible when skipped.
- Staff are trained on the new system before the date, not handed a login on the morning of it.
- Patients know their portal is changing, their card on file may need re-entering, and their statements will look different.
- Referrers know how to reach you if anything about intake changes.
- The budget covers all four jobs and the overlap period, not the conversion quote alone.
The one-line readiness test
If most of the items above are true, you are ready to export. If most are not, you are not behind. You are at the planning stage, and planning is far cheaper than discovering the same gaps in the middle of the move. Run the list before the file leaves the old system, and the migration becomes a plan you execute rather than a series of surprises you absorb.
Common questions
What should be on a practice management migration checklist?
The decisions written down, the data ready to leave, the money planned, the documents owned, the configuration set up, the enrollments filed, the credentialing confirmed, the timeline set, and the validation planned. Every item is a readiness gate to clear before your data leaves the old system.
When should I start a migration checklist?
At the beginning, before any data moves. The checklist is a readiness list for the start of a migration, not a finish line. Working down it early turns the choices a migration forces into decisions you make on purpose, rather than surprises you hit in the middle of the move.
What decisions do I need to make before migrating?
Which patients come across, what happens to your financial history, when you cut over and how the freeze works, whether you run the old system in parallel, and who owns each of the four jobs. Each is cheaper made deliberately up front than discovered mid-move.
What are the four jobs in a migration?
Moving the structured data, moving the documents, configuring the new system so the data has somewhere correct to land, and the weeks after go-live. The paid conversion is the tail of the first one, and three of the four are yours to run.
How do I know if I am ready to export my data?
When the decisions are written down, the data is cleaned and test-exported, the money and documents have plans and owners, the configuration and enrollments are underway, and the validation is planned. If most of that is not true, you are ready to plan, not yet ready to export.
What is the most common thing left off a migration plan?
The three jobs around the paid conversion: the extraction, the document move, and the configuration, enrollment, and validation. Practices price and plan off the conversion quote, the one piece with a clear price, and the rest, which is most of the work, gets underestimated.
Who should own each part of a migration?
Name an owner in writing for the data extraction, the document move, the configuration, and the validation, and a lead for the enrollments and credentialing. When ownership is vague, the documents are the piece that falls through, because they belong to everyone and to no one.
What financial steps belong on the checklist?
Decide how far to run open receivables down and by when, and set a billing cutoff line. Resolve credits, unapplied payments, and refunds in flight, identify near-deadline claims before any freeze, and decide where the closed history lives. Balances move, but the history that explains them usually does not.
How do I set a go-live date on the checklist?
Set it backward from the slowest enrollment in sight, with room to spare, and around your own calendar rather than your heaviest billing run or busiest season. Committing a date before the long-pole enrollments are filed is naming a guess, not a plan.
What should the validation part of the checklist include?
The counts and financial buckets you will reconcile, the schedule checks forward and back, the document totals and a sample to open, and the live tests. A claim out and back, a payment posted, a statement, and a coverage check. Plus go or no-go criteria agreed before cutover.
What happens if I skip the checklist and just start?
You hit the decisions in the middle of the move instead of before it, when they are more expensive and there is less time. The money strands, the documents fall through, and the date slips or forces a go-live that cannot bill. The checklist trades surprises for a plan.
Where this leaves you
A migration is only as clean as the planning that precedes it, and this list is that planning in one place. Settle these before your data leaves the old system, and the move becomes something you run on your terms instead of something that runs you.