Guides

How to Prepare for an AdvancedMD Data Migration

The paid conversion is the smallest and best-defined part of the move. Almost all of the work, and almost all of the risk, sits in what surrounds it, and that part is yours.
Updated July 2026

AdvancedMD’s conversion is the last mile of a migration. Everything that decides whether it goes clean happens before their team opens your file. This is the full scope, start to finish, and it is long because a migration is large. Read it before you export a single record.

One note before the scope: this guide assumes the decision to move is already made. If you are on AdvancedMD today and the migration you are weighing is the one away from it, read the honest math on that move first.

Where AdvancedMD’s part begins and ends

AdvancedMD moves your data into their system through a careful, staged conversion. They call it data conversion, some people call it data migration, and it runs in defined tiers. The smallest tier brings across patient demographics. The next adds appointments. The largest covers full practice management data. Whichever tier you buy, the process has the same deliberate shape. Your old data is analyzed so the new layout can be planned, cleaned of duplicates and errors, tested against a small batch to catch problems early, then loaded in full on a set cutover date.

Read that sequence again, because the important part is easy to miss. The process starts when AdvancedMD receives a file. A clean, mapped, correctly arranged file, with your data already shaped the way their system expects to take it in. Producing that file is your work, done before the conversion begins, and it is most of the work there is.

Everything the tiers were made to carry is structured data that fits a template: who your patients are, who is responsible for their bills, who refers them, when they are scheduled, and who covers them. Everything else is yours to move, or yours to decide about. And the single most expensive fact in any practice management move is this. The transaction history behind your money does not ride along. The charges, the payments, which payment paid which charge, the adjustments, the write-offs, the claim trail, the remittances that came back from payers, the balances themselves. None of it converts into the new ledger by default.

That is true of nearly every move between practice management systems, not a quirk of any one of them. It is simply what a ledger is. Your financial history lives as a web of linked transactions, and that web does not survive being lifted out of one system and set down in another. What you can carry is the shape of who and what. What you cannot carry, on its own, is the money’s whole story.

So a migration is really four separate jobs, and the conversion AdvancedMD runs is the last mile of one of them:

Three of those four are yours. The conversion sits at the tail of the first one. This guide walks all four in plain English, and it dwells longest on the parts that are invisible until they cost you, because those are the parts that decide how a migration goes. Almost all of the work, and almost all of the risk, sits upstream of the part AdvancedMD handles.

A note on who this is for. This applies to any practice moving onto AdvancedMD, whatever the specialty, from primary care to chiropractic, physical therapy, and specialty offices. The four jobs are the same everywhere. The specifics shift by practice, so where an example names a detail, read past it to the shape underneath.

The decisions you make before any data moves

A migration forces a set of choices on you, and every one of them is cheaper to make deliberately, up front, than to discover in the middle of the move. These are decisions rather than tasks, and the work in the rest of this guide is what each one sets in motion. Make them first.

Which patients come across. Your current system holds every patient you have ever seen, including the ones you last saw six years ago and will never see again. You can bring all of them, or only the active ones, or the active ones plus anyone seen in the last few years. Bringing everyone feels safe and costs the most, because every patient you carry is coverage to verify, documents to move, and clutter that lives in the new system forever. Bringing too few means a returning patient looks brand new, with their history stranded in a system you no longer pay for. There is no line that is right everywhere. There is a line that is right for your practice, and you draw it on purpose, with a written rule that a person can apply the same way twice.

How much financial history you keep, and where. This is the choice that follows from the ledger reality above, and it is the one practices most often sleepwalk through. Your open accounts receivable, the money still owed to you, has to be handled. Your closed history, the paid and settled transactions, is a record you may need for audits, refunds, and disputes long after you switch. You have three honest paths and will probably use more than one. Run the open accounts receivable down in your current system, as close to zero as you can get it before you switch, so there is little live money left to strand. Archive the closed history in a form you can still read and search. Or pay a data archiving service to hold it. None of these is wrong. Drifting toward cutover without having chosen is how a practice arrives at go-live still owed real money inside a system it is about to stop using.

Your cutover date, and the freeze around it. A migration ends on a specific day, when the new system becomes the system of record and the old one stops. Around that day sits a window where you cannot keep entering new charges and payments into a system that is being frozen and copied. The date is fixed by the slowest thing you depend on, which is almost always payer enrollment, the slowest part of the whole project and the piece you least control. Choose it backward from the long poles, not forward from optimism. And choose it around your own calendar. The week you go live is a week your throughput drops while everyone learns the new system, so going live the day before your heaviest billing run, or in the middle of your busiest clinical season, turns a hard week into a bad one.

The timely-filing clock, which the freeze can break. Every payer gives you a limited window to submit a claim from the date of service, and that clock does not pause because you are migrating. A freeze that strands a batch of near-deadline claims in a half-open system can push them past timely filing, and a claim filed late is often a claim written off in full. Before you freeze anything, you find the claims with the least runway left and get them out first, so the migration does not quietly age money into the bin.

Whether you run the old system in parallel. Some practices hard-cut. On the date, the old system goes read-only and everything new happens in AdvancedMD. Others run both for a stretch, finishing old work in the old system while starting new work in the new one. Running in parallel is safer, more expensive, and more confusing for your staff, who now live in two systems at once and have to remember which one a given task belongs in. A hard cut is cleaner and far less forgiving. The right answer depends on how much unfinished financial work you will still be carrying on the date, which is another reason to run the old receivables down before you switch.

Who owns each of the four jobs. A migration touches your front desk, your billing team, your clinical staff, and whoever holds the keys to your current system. Someone has to own the data extraction, someone the document move, someone the configuration, and someone the check that proves it all worked. Name them, in writing, before you start. When ownership is vague, the documents are the piece that falls through. Every time. Because they belong to everyone and to no one.

What done means, and how you will prove it. Before you begin, decide what you will check on go-live day to confirm the migration held. Patient counts. Financial balances by aging bucket. Appointment integrity, past and future. Document totals. A test claim that goes out and comes back paid. Write the checklist now, because if you have not defined what proof looks like in advance, you will go live on hope and find the gaps when they cost the most.

How you will tell people. Your staff need training before the date, not a login on the morning of it. Your patients need to know their portal is changing, their card on file may need re-entering, and their statements will look different. Your referrers need to know how to reach you if anything about intake changes. None of this is hard, and all of it is the difference between a go-live that feels planned and one that feels like something broke. A short communication plan, decided early, saves a week of confused phone calls later.

What you are actually budgeting for. The conversion has a price, and it is the smallest number in the project. The staff hours to clean the data, move the documents, and set up the configuration, the outside help for the parts your team has never done, the overlap period of paying for two systems at once, and the dip in collections during the first weeks are the real cost of a migration. A budget drawn from the conversion quote alone is a budget for one job out of four.

Job one: the structured data

This is the data that lives as fields, the records AdvancedMD’s tiers are made to convert. It is the part everyone pictures when they hear migration, and it runs deeper in every direction than it looks. And it begins before AdvancedMD is involved at all, with prying your own data loose from the system you are leaving.

Getting it out of the old system

Before anything can be cleaned, mapped, or loaded, it has to come out, and the system you are leaving was not made to help you leave. This is the step practices assume will be easy and often is not.

How your data comes out depends on your current vendor. Some hand over a clean, full export on request. Some give you a limited set of reports that do not include everything you need, and getting the rest means escalating, waiting, or paying. Some sit on a database you can query directly. Some do not, and every field you want has to come through whatever export their interface offers. You do not control which of these you are dealing with, and you find out how cooperative your old vendor is only when you ask, so ask early, in writing, and ask for everything, not a sample.

What comes out cleanly and what fights you is its own map. Demographics usually export well. The money and its history often do not, because the same web of linked transactions that will not load into the new ledger also resists coming out of the old one in any form that reconstructs it. Documents may export as a bulk dump with the links to patients stripped away, so you get the files and lose the filing. Custom fields, the places your practice stored something the system did not have a home for, frequently do not come out at all, or come out mislabeled, because they were never meant to travel.

Pull a full test export early, long before your real one, and look at it hard. It tells you what you actually have, in what shape, with what missing, while there is still time to chase the gaps. The practices that get surprised are the ones who assumed the export would contain what they needed and did not check until the file was the only thing standing between them and a cutover date they had already promised.

And mind the contract you are leaving. Your agreement with the old vendor has an end date, a notice period, and sometimes a fee to get your own data out or to keep read-only access after you go. Read it before you set your timeline, because the day your old system goes dark is a day you want to choose, not a day that arrives because a renewal lapsed while you were busy migrating.

The people

Every patient carries a set of demographics that goes well past a name and an address. Dates of birth, the identifiers you know them by such as chart and record numbers, the primary care physician, the demographic detail you are now required to keep, and the rules for how each patient is allowed to be contacted. A patient who has asked not to be called at home, or not to have a voicemail left, is carrying a preference that has to survive the move or you break a promise on day one.

The identifiers deserve a moment, because patients know themselves by their chart number, and it prints on their paperwork and gets quoted on the phone. If those numbers change or get reassigned in the move, you have patients and records that no longer agree on who is who, and a front desk reconciling by hand. Decide early whether the old identifiers come across intact, because it is far easier to carry them than to explain to a patient why their number changed.

Duplicates are the quiet tax of the people file. The same patient entered twice under a maiden name and a married name. Once as a walk-in and once as a scheduled visit. Once with a typo that means two systems will never agree they are the same person. Every duplicate you carry is a split history, with some visits under one record and some under the other, and it does not resolve itself in transit. In the new system it simply arrives as another duplicate, now permanent, unless it is found and merged before the file is handed over. The same is true of the accounts that are not patients at all: staff entered to test something, training records, the account someone made to hold a note. They are clutter you are about to make permanent if you do not clear them first.

Minors carry their own weight. A child’s record ties to a guardian, and the rules about who can see what, who consents, and who gets billed are not the same as an adult’s. That guardian link carries the billing and the contact, so if it breaks in the move, a statement or a message can go to the wrong person. For these records, the consent and privacy settings matter as much as the demographics, and both have to move.

The responsible parties and family accounts

Behind most accounts is a responsible party, a guarantor, who is often a different person from the patient. A parent behind a child. A spouse behind a spouse. An adult child behind an aging parent. The guarantor is its own record, with its own address, contact details, and billing preferences, and it does not come along automatically just because the patient does.

Families tie several patients to one guarantor, and those links carry the billing. If they break in the move, statements go to the wrong person, or two family members each get billed for the other, or a single household that should get one statement gets three. Untangling that after go-live means a patient calls angry about a bill for a relative, and your front desk is piecing the family tree back together while the patient waits. The relationships are as much a part of the data as the names, and they are easy to lose because they live in the links, not in any one field.

Coverage and coordination of benefits

A patient’s insurance is rarely one record. There is a primary, often a secondary, sometimes a tertiary, and the order matters, because the order decides which payer gets billed first and which claims reject for being sent to the wrong place. Each coverage carries a policy number, a group number, the subscriber and the patient’s relationship to them, and effective dates that say when the coverage started and, for old coverage, when it ended.

The effective dates are where quiet damage happens. Coverage that has ended but still looks active will send claims to a payer who is no longer responsible, and those claims come back weeks later, aged and harder to collect. Coverage that is active but arrives incomplete, missing a group number or a subscriber, will reject on the first claim of your first week on the new system. Multiply that across a practice’s worth of patients and a migration that technically loaded can still stall your cash for a month while coverage is corrected one patient at a time.

Coordination of benefits is its own knot. When a patient has more than one plan, the payers care intensely about the order, and the secondary will not pay until the primary has, with the primary’s payment information attached. If the coverage order comes across wrong, or the secondary crossover is not set up, secondary claims sit unpaid and someone has to work them by hand. This is ordinary wherever patients carry more than one plan, a commercial plan behind a public one, or a primary behind a supplement, and getting the order right up front is far cheaper than reworking a backlog of stuck secondaries later.

Coverage is not always a standard commercial insurance card, and the exceptions each have their own rules. Self-pay and discount arrangements are a coverage of a kind, an agreement about what a patient pays, and if the agreement does not travel, the patient gets billed a rate they never agreed to. Workers compensation, personal injury and auto claims, and any special program that bills through a different channel each carry their own setup. None of these are exotic, and all of them break if coverage is treated as a single insurance card.

Coverage also points at a payer that has to already exist in the new system, set up correctly, before the coverage means anything. That payer setup is a large piece of its own, and it happens when you configure the system. What matters here is that the coverage records are patient data that has to move, and they are only as good as the payer records they lean on.

The schedule

Your calendar is a live thing, booked out weeks ahead and full behind you, and a migration has to freeze it and carry it without losing either direction. Appointments come with their type, their status, their length, and the provider and location each belongs to. That much is obvious. The parts that break are the ones underneath.

Standing patients who come every week carry recurring rules that generate their future appointments, and those rules have to be recreated or the future calendar arrives empty, which for a practice that runs on recurring visits is most of the schedule. Group and class visits, where several patients share one slot, are their own structure that migrations routinely mangle into a single appointment or a pile of separate ones. Telehealth appointments carry the fact that they are telehealth, which drives how they are later coded and billed, and that has to survive the move or the billing behind them goes wrong. Resources such as rooms and equipment, if you book them, are their own layer of the calendar.

There is a decision buried here too. How far back does the schedule need to come, and how far forward. The future is easy to argue for, because those are appointments patients expect to keep. The past is a judgment call, and it interacts with your clinical documentation, because an appointment in the old system is what a note was attached to. Cut the schedule history too short and you can orphan the record of why a patient was seen. There is also the quieter history in the calendar, the no-shows and cancellations, which is where a practice’s understanding of its own attendance lives. If your reporting depends on it, it has to come too, and if it does not, you can leave it, but that is a choice to make rather than a thing to discover missing.

The clinical record

Some of your clinical record is structured data and some of it is a document, and the line between them decides how it moves. The structured part, the fields the system understands as data, can be carried in the conversion. The rest is a file, and it moves with your documents rather than your data. Knowing which is which for your practice is the difference between a clinical history that arrives usable and one that arrives as a wall of attachments.

Treatment plans carry review dates that payers and regulators care about, and a plan whose review date does not travel is a compliance gap waiting to be found. Assessments and outcome measures, the standardized forms many practices use to track progress, may live as structured scores or as scanned forms, and how they come across decides whether a clinician can see a patient’s trajectory or has to open ten PDFs to reconstruct it. The link between a note and the appointment it belongs to is itself a piece of data, and if it breaks, you have notes and visits that no longer point at each other.

None of this loads well if the schedule history it depends on was cut too short, which is why the clinical record and the calendar have to be decided together rather than as separate lists.

The charges, and the money that does not come with them

This is where most of the work and nearly all of the danger live, so read it slowly.

Every charge you have ever posted carries a balance, split between what insurance still owes and what the patient still owes. That balance is the visible surface. Underneath it sits a chain that made the balance what it is: the payments you took and the exact charges each one was applied to, the contractual adjustments, the write-offs and the reasons behind them, the claims you submitted and every resubmission, the electronic remittances that came back from payers explaining what was paid and why, the patient statements you sent, and anything that went to collections. On top of that sit the awkward pieces that never balance cleanly even on a good day, the credit balances you owe back to patients or payers, the unapplied payments sitting on accounts waiting to be posted, and the refunds already in flight.

Almost none of that chain converts into the new ledger. The balances might be summarized and carried as opening figures, at best, and even that is a number reconstructed by hand rather than a record moved intact. A summary balance arrives in the new system without the history that explains it. Which means a patient can open a statement in AdvancedMD, see a figure, call your front desk to ask what it is for, and no one can answer, because the charges and payments that add up to that number were left behind in a system nobody logs into anymore.

That is why the standard, sane path is to finish your open accounts receivable in the old system before you switch. Live money is only safe where its full history lives, and that history stays put in the old system. Any move between systems carries the shape of your data and leaves behind the web of linked transactions that explains each balance, so you keep the live money where that web still is. You run the old receivables down, post the payments as they come, resolve the credits and the unapplied cash, and shrink the pool of live money you are carrying until what remains is small enough to manage by hand. The practices that skip this arrive at go-live still chasing thousands of dollars of aged claims inside a frozen system, with a billing team now trying to do that work in a system they no longer know.

There is a timing trap folded into all of this. Running receivables down takes weeks, and during those weeks new charges keep landing in the old system, so the pool you are trying to empty keeps refilling until you stop billing into it. At some point you draw a line, after which new work goes into the new system and the old one only winds down. Choosing that line, and holding it, is part of the plan. Without it, you are bailing a boat that someone keeps filling.

Everything in this section is a reason the money is a job you plan around, not a file you attach.

Authorizations, in depth

Authorizations are their own record, and for any practice whose payers require prior approval, they are the record that gates your revenue. A payer approves a patient for a set number of visits, over a set date range, sometimes for a specific service, and every visit you deliver draws that approval down. Lose track of it and you deliver care the payer will not pay for.

None of this rides along with the demographics. The approval itself, the number of visits it covers, the number already used, the number remaining, the dates it spans, and the service it applies to are all pieces that have to be carried and re-entered, accurately, before the first claim goes out. An authorization that comes across with the wrong remaining count, or without its date range, or attached to the wrong service, produces a denial on a patient you were certain was covered, and it produces it after you have already provided the visit.

There are shapes within authorizations that make them harder. Some are for an initial course of care and some are concurrent, extending an existing course, and the difference matters to how the payer reads the claim. Some are retroactive, covering care already given. Some limit the units within a visit as well as the number of visits. A practice mid-treatment with a patient is mid-authorization, and the migration has to catch that patient at the right point in their remaining count, not reset them to zero and not assume a fresh approval. This is painstaking, and it is exactly the kind of work that gets skipped under deadline and discovered in a wave of denials three weeks after go-live.

Cleaning it before it moves

None of the data above loads well unless it is right when it arrives. AdvancedMD’s process includes a cleansing step, and it counts on the file being sound when they receive it. The condition of what you hand over decides how the load goes, and most practices have never looked at their own data closely enough to know what condition it is in.

The mess is ordinary and it is everywhere. Duplicate patients and duplicate guarantors. Carriers that termed years ago still attached to active accounts. Dates entered in three different formats by three different people over ten years. Records that were opened and never closed, appointments that were never checked out, charges that were never posted or never resolved. Names in all capitals and names in mixed case and names with a typo that means two systems will never agree they are the same person. Fields used for something other than what they were meant for, because a decade ago someone needed a place to put a note and that field was handy, and now the meaning of that field depends on who filled it in and when.

You do not need to fix every one of these to move. You need to know which ones matter, which ones will reject or misroute on the other side, and which ones are cosmetic. That triage is a skill, and it is the difference between a load that lands clean and a load that technically succeeds and then generates a month of cleanup no one budgeted for. The cleaning also has a deadline that is not the cutover date. It has to be done before the file is handed over for conversion, because once the data is in flight, the mess is coming with it.

The items that hide in plain sight

A few things carry real weight and never show up in a quick look at your data.

Stored payment cards usually cannot move. The card numbers on file, and the recurring payment plans that run on them, generally do not transfer, for the same security reasons that protect them. So patients have to re-enter their cards, or the recurring payments quietly stop, and the first sign you get is a drop in patient collections a month after go-live that nobody connects back to the migration. If a meaningful share of your patient revenue runs on cards on file or payment plans, this is a project of its own, with its own patient outreach, not a footnote.

Patient portal accounts are their own small migration. Patients have logins, messages, and a view of their own balances and records in your current portal, and the new system’s portal is a different front door. Whether their history follows them, whether they have to re-register, and what they see when they first log in are all things to handle on purpose, because a patient who logs in after go-live to a portal that has forgotten them is a patient who calls, or worse, assumes their records are gone.

Patient alerts and account memos are the flags your front desk relies on, the ones that say do not schedule this patient, or that an account is on a collections hold, or to call the guarantor rather than the patient. Some carry expiration dates. To your current system they mean something. To a fresh system they mean nothing, unless someone carries them across on purpose. The cost of losing them lands on your front desk, flying blind on exactly the patients where knowing something mattered most.

Self-pay, discount, and financial-hardship agreements are promises you made about what a patient pays, and they live in the account as much as any balance does. If they do not travel, the patient gets billed the standard rate, feels the practice went back on its word, and your front desk spends the call apologizing and reconstructing an arrangement that already existed. None of these items announces itself. All of them are found either before the move, on purpose, or after it, by the patient.

Job two: the documents

Your structured data lives as fields. Your documents live as files instead, and in most practices they are the single largest volume of anything you own. They sit entirely outside the tiered conversion and do not ride along with the demographics. The document move is the job that quietly decides how your first months feel, because it is the one your clinicians touch every time they open a chart.

Think about what is actually in there. Scanned intake forms and signed consents. Clinical notes and their attachments. Treatment plans and assessments that live as forms rather than data. Insurance cards and photo identification. Correspondence with patients and payers. Explanations of benefits. Release-of-information forms. Prior records from before your current system that you scanned in when the patient first arrived. Every one of those is a file, and every one of them has to end up in the right place in the new system to be worth anything.

The work is exact, and that is what makes it heavy. Each file has to be tied to the correct patient, given a name that says what it is, and filed into a structure that keeps it findable a year from now when someone needs it for an audit, an appeal, or a records request. Ten thousand documents that all import as a string of identical file names, attached loosely or not at all, are not records you can use. You have moved the mess, not the medicine. When a chart request comes in and the answer is buried in a thousand files that all look alike, the migration has technically preserved the document and practically lost it.

The document types are not equal, and treating them as one pile is how the important ones get buried. Clinical documents are what a provider needs mid-visit and what an audit will ask for. Legal and consent documents are what protects you when a patient or a regulator questions what was agreed. Financial documents, the explanations of benefits and the correspondence with payers, are what you need to win an appeal or defend a balance. Each of these has a different reader and a different moment it gets pulled, and the filing structure has to make each one findable by the person who will need it, rather than merely present somewhere in the system.

There are edges that catch people. Documents attached to patients you decided not to bring across are now orphaned, and you have to decide whether those patients come after all or those records go to the archive with the rest of the history you left behind. Duplicate scans, the same insurance card uploaded three times over three years, multiply the volume without adding anything, and someone has to decide whether de-duplicating is worth the effort or whether you carry the duplicates. Records under legal hold, tied to a dispute or a request in progress, cannot be archived away casually and have to be tracked through the move. And whether the documents arrive searchable, so that text inside a scanned page can be found, or arrive as flat images that can only be found by their file name and folder, changes how usable the whole archive is for years.

Retention is the rule underneath all of it. You are required to keep records for a set number of years, and that requirement does not care that you changed systems. Whatever you archive rather than move still has to be kept, readable and retrievable, for as long as the rule says, and a records request that lands two years after go-live has to be answerable from wherever those documents ended up. An archive you cannot search is an archive that fails the moment someone needs it.

This is the job that bites late, and it bites for a specific reason. It is usually noticed at or after go-live, when a provider opens a chart mid-visit and the history is not there. The volume makes it slow. The matching makes it unforgiving. And because it belongs to everyone and to no one, it is the job most likely to be underestimated at the start and discovered at the worst possible time. It needs its own owner, its own timeline, and the same care as the data, and it should be running in parallel with everything else from the beginning, not queued for after the data is done.

Job three: configuration for a day-one go-live

The new system has to be set up before your data lands in it, because the data points at the setup. A charge needs its procedure code and its fee schedule to already exist. An appointment needs its type and its provider. A claim needs the payer, the enrollment, and the billing rules in place. If the setup is not there first, the data has nowhere correct to land, and the load either fails or succeeds into a system that cannot do anything with what it just received.

There is a real difference between turning an office key on and setting it up so the practice’s numbers work on your first day. The first is a switch anyone can flip. The second decides whether your first month of claims goes out clean or comes back to be reworked. This is also the largest of the four jobs by hours, and the one where knowing AdvancedMD specifically, rather than practice management in general, matters most, because every setting has a right answer for how your practice actually bills, and the wrong answer does not announce itself until a claim rejects. Here is what that setup covers, and why each piece matters.

Providers, and the credentialing behind them

Every provider who renders services needs their own record, with the correct national provider identifier, taxonomy, and the individual settings that control how their charges and claims behave. That is the easy half. The hard half is that a provider record is only as good as the provider’s standing with each payer, and that standing does not live in the software at all.

A provider has to be credentialed and enrolled with a payer before that payer will pay their claims, and enrollment is tied to the practice, the location, and often a specific effective date. A provider who moves to a new group, or a new location, is not automatically enrolled there just because they were enrolled somewhere else. If the enrollment is not in place, or the effective date is wrong, the claims for that provider deny, and no amount of correct setup in the system fixes a credentialing gap outside it. A migration is a common moment for these gaps to surface, because the move exposes assumptions about who is enrolled where that no one had checked in years.

Many practices add a layer here that trips them up. Care is often delivered by one provider and billed under another, an assistant or an advanced-practice provider working under a supervising or billing physician, and depending on the payer the claim goes out under the supervisor, or under the rendering provider with the supervisor attached, or the rendering provider is not billable to that payer at all. That relationship is a piece of setup, and it has to match each payer’s rules, provider by provider and payer by payer. Get it wrong and you either bill in a way the payer rejects or, worse, bill in a way the payer pays and later claws back. This is exactly the kind of practice-specific, payer-specific knowledge that a generic setup misses and a wave of denials reveals.

Locations and places of service

Every location needs its own record with its own identifier, and every location’s claims carry a place-of-service code that tells the payer where the care happened. That code has to be right, because payers price and pay differently by place of service, and a claim with the wrong one can pay incorrectly or reject.

Telehealth is where the place-of-service setup bites, because a telehealth visit carries a different place-of-service code and often a modifier, and the rules for how telehealth is coded have shifted repeatedly and vary by payer. If your telehealth visits are set up to code the way in-person visits do, or the way last year’s telehealth rules said, the claims go out wrong from day one. This is setup that has to reflect current payer rules, not the rules that were true when your old system was configured, which may have been years ago.

Payers, and the identifiers each one needs

A payer is not one setting with a name. Each one needs the identifier your claims actually go out on, and that is not always the same as the identifier used for real-time eligibility checks, and for some payers institutional claims use a different setup again. Get the claim identifier wrong and every claim to that payer rejects. Get the eligibility identifier wrong and your front desk’s coverage checks come back empty, so nobody knows what a patient owes at the time of service. Each payer also carries its own rules, its copay expectations, whether it needs claims split or bundled a certain way, and its quirks that your billing team has learned over years.

Setting up your payers correctly is one of the pieces that pays back the most across the whole migration, because a single payer configured wrong is every claim to that payer, delayed, and a busy practice may bill a long list of payers, each with its own correct answer. This is also where the institutional knowledge in your billing team has to be captured rather than assumed, because the person who knows that a particular payer needs a particular quirk is the person whose absence turns a clean setup into a month of rejections.

Fee schedules, contracted rates, and discounts

Your fees are not a single number. There is what you charge, and there is what each payer has contracted to allow, and those contracted rates differ payer by payer. If the new system does not know the contracted rates, it cannot tell you when a payer underpays, and underpayments are the leaks that never announce themselves, because a claim that pays less than it should still pays, and nothing flags it. Setting up the fee schedules, including the contracted rates for each payer rather than one default fee, is what lets the new system catch a short payment instead of banking it as normal.

Many practices carry a discount or self-pay schedule on top of this. A practice that adjusts fees, whether by a cash rate, a membership, or a hardship discount, has a schedule of its own, and it has to be set up so that the right patient is charged the right adjusted rate. The patient-level agreements about who gets which rate, the ones recorded on each patient’s account, only work if the schedule itself exists in the configuration for them to point at. Two halves of the same thing, and both have to be present or the discount silently reverts to full fee.

Codes, modifiers, and the meaning that can shift

Everything you bill leans on shared reference lists. The procedure codes you use, the diagnosis codes, the places of service. These have to exist and match how the new system expects to see them, and every charge and every claim you carry points at them. If two of your codes meant slightly different things in the old system than they will in the new one, the meaning shifts under your data without anyone deciding it should.

Modifiers are where this gets sharper. A modifier changes what a code means to a payer, marking a telehealth visit, a service delivered under supervision, a reduced or extended service, or a repeat procedure, and payers can be strict about which modifiers they require and which they reject. The rules for which modifier goes with which code for which payer are their own body of knowledge, and they have to be set up to match how each payer actually wants the claim, not a general default. Add-on codes, the ones that only exist attached to a primary service, have their own rules about pairing. Get the coding setup wrong and clean-looking claims reject for reasons that take a payer’s explanation to decode.

Financial classes, adjustment reasons, and aging

Underneath your reporting sit the categories that make the numbers mean something. Financial classes group your payers so you can see how you are doing by payer type. Adjustment and write-off reason codes record why money left the ledger, which is the difference between a write-off you chose and one that signals a problem. Aging buckets define what counts as thirty, sixty, ninety days old, which is how you see where money is stuck.

These are easy to treat as defaults and expensive to get wrong, because they shape every report you will run to judge whether the practice is healthy. If the financial classes do not match how you think about your payers, or the adjustment reasons collapse distinct problems into one bucket, the reports come out technically correct and practically useless, and you find out only when a number you trusted turns out to have been hiding something.

Scheduling setup

The calendar is the machinery that runs your appointments, and all of it has to exist before the appointments load: the appointment types and their default lengths, the statuses an appointment moves through, resources such as rooms and equipment, the scheduling rules and provider availability that decide who can be booked when, and group and class structures for practices that run them. Without it, the appointments arrive with nowhere to sit. The reminder and recall rules that bring patients back, and that a practice leans on to keep patients coming back, are part of this setup too, and a practice that goes live without them loses the quiet machinery that was keeping its schedule full.

Clinical templates and documentation setup

Your clinical documentation runs on templates, and the templates your providers use every day have to be set up so that from the first visit they are documenting the way they always have, not fighting a blank system. Practices document in specific shapes, an intake, a visit or progress note, a treatment or care plan, a discharge summary, each with its own structure, and each of those templates has to exist and work before a clinician sits down with a patient on go-live morning. Treatment plans carry review cycles that have to be set up so the system prompts a review when one is due, because a missed review is a compliance finding. Assessment tools, if your clinicians score them in the system, have to be configured to capture and track the scores. A provider who spends go-live week wrestling a documentation setup that does not fit how they work is a provider seeing fewer patients, and the cost of that lands straight on the schedule.

Billing rules, claim scrubbing, and statements

The checks that catch a bad claim before it goes out are their own configuration, and they are what protects your clean claim rate on day one. Claim scrubbing rules, the tests a claim passes before submission, have to be set up to match the payers you bill and the errors you tend to make, or claims go out with problems that a properly configured system would have caught. Your statements have to be set up to look right, say the right things, and follow the cycle you intend, or the first statements out the door confuse patients and generate a wave of calls. The dunning cycle, how and when overdue balances are followed up, is part of this, and a practice that goes live without it either chases nothing or chases everyone at once.

Electronic connections and the enrollments that set your timeline

Some of the setup does not depend on you at all, and that is what fixes your whole timeline. These are the connections that let money and information move electronically, and each one runs through an outside party on its own schedule.

Sending electronic claims requires enrollment with a clearinghouse. Receiving electronic remittances, the payment detail that posts automatically, requires enrollment with each payer, and each payer moves at its own pace. Receiving payments electronically requires its own enrollment and bank verification. Real-time eligibility checking has to be connected and configured. Electronic prescribing has to be set up, and for controlled substances it requires a stricter enrollment with identity proofing that takes longer, which matters for any practice whose providers prescribe them. Lab interfaces, if you use them, are their own connection. The patient portal has to be stood up and connected. Payment processing has to be wired to your bank.

Every one of these involves an approval that arrives when it arrives. The lead times run into weeks, and they do not move faster because your go-live date is close. They are the long pole in the entire project. They get started first, before the data work, or they become the reason your date slips. Every practice that has to push its go-live pushes it for one of these, and the ones that plan well start the enrollments the day the decision to migrate is made, not the week they hope to go live.

Users, roles, permissions, and access

Every person who touches the system needs an account with the right permissions for their role. The front desk should see what the front desk needs and not the rest. Billing needs its access, clinicians theirs, administrators theirs. Set up too loosely and you have a privacy problem, because medical records are sensitive and the rule is that people see the minimum their job requires. Set up too tightly and your staff cannot do their jobs on go-live morning and the day turns into a scramble of access requests while patients wait.

The access controls that protect sensitive records, the audit logging that records who looked at what, and any sign-on and verification requirements your practice uses are part of this setup, and they are worth getting right before go-live rather than after a question arises about who saw a record they should not have.

Bringing more than one practice together

If you are moving more than one practice onto a single AdvancedMD instance, every list above has to be reconciled across all of them before anything loads. Two offices rarely code the same procedure the same way, name the same payer the same way, classify the same balance the same way, or structure the same note the same way. Merging them means deciding, once, how the combined group will run, and settling those differences on paper before the load is far cheaper than untangling them after, when the data from several practices is already mixed together in one system and no one can tell which office’s convention a given record followed. For a group that is acquiring practices and standardizing them, this reconciliation is the actual work of the migration, and the data conversion is the easy part at the end of it.

Why configuration runs alongside, not after

Because the setup has to be ready before the data arrives, this job runs at the same time as the first two, not after them. That overlap is the thing calendars miss. A migration looks like a sequence when you draw it, data then documents then go-live, and in practice it is three jobs running at once against a date that is fixed by the slowest enrollment. The data cannot be tested until the setup it points at exists. The documents cannot be filed until the patients they attach to are loaded. Everything leans on everything, which is why migrations that look simple on a timeline run long in the room, and why the practices that finish on time are the ones who started all three jobs together instead of in a line.

Cutover: the weekend it all converges

Cutover is the moment all three jobs meet. The structured data loads, the documents are in place, and the configuration is live and waiting for them. It is a single, planned event, and it lands better the more of the deciding you did in the months before it. What follows is the shape of a cutover, not a script, because the exact steps belong to whoever runs your move. Knowing the shape is what lets you tell whether the plan you are handed is a real one.

The freeze, and the last mile in the old system

There is a point where the old system stops being the place work happens and becomes a thing being copied. Before that freeze, you get the old system into the cleanest state you can. The receivables are as low as you got them. The near-deadline claims are out. The data is cleaned and the final export is ready. During the freeze, new work has to go somewhere, and where it goes depends on whether you are running a hard cut or keeping the old system live in parallel. A freeze with no plan for the work that arrives during it is how a practice ends up with a gap in its records for the exact days it was migrating.

Go, or no-go

A cutover has a moment of decision before the switch becomes final, where you look at whether the load is clean and the configuration is ready and decide to proceed or to hold. That decision needs criteria set in advance, the same checks that will tell you the migration held, because a go-live decision made on the day under pressure, with a date already promised to staff and patients, is a decision that says go no matter what the data says. The practices that hold when they should hold are the ones who agreed, before the weekend, on what would make them stop.

Rollback, and the contingency you hope not to use

Ask what happens if the load is wrong. A migration that has no answer for that question is a migration betting the whole practice on nothing going wrong, which is not a bet you make with your revenue. Whether the answer is a clean rollback to the old system, a hold and re-load, or something else, it has to exist before cutover, so that a problem discovered on go-live morning is a problem with a plan rather than a crisis.

Telling patients, staff, and referrers

The people affected by the switch should hear about it before it happens, not discover it. Staff need to have trained on the new system before the date, so go-live morning is the first real day and not the first look. Patients need to know their portal is changing, their card on file may need re-entering, and their statements will look different, so the first unfamiliar bill does not read as a mistake. Referrers need to know how to reach you if anything about intake changes. This is the cheapest part of the whole migration and one of the most visible, because a go-live that was communicated feels planned, and one that was not feels like something broke.

Proof it worked: validating the migration

A migration is done when you have proven the data loaded correctly, and that proof is a specific set of checks you run at cutover. Loading the data is only the setup for those checks. Skip them and you will still find the gaps. You will just find them later, from a patient or a payer, at the worst price. Here is what real validation looks like, and why each piece is there.

Reconcile the counts, entity by entity. The number of patients that came across should match the number you sent, and the same holds for guarantors, appointments, coverage records, and providers. A count that is off by even a little means something was dropped or duplicated in the load, and it is far easier to find that now, against a known number, than to notice months later that a slice of patients is missing.

Reconcile the money, bucket by bucket, to the dollar. Whatever financial figures you carried, the balances and the open receivables, should match what you left behind, broken down by aging bucket rather than as a single 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 is. A balance that is close is a balance that is wrong, and close is how a reconciliation passes while hiding an error that surfaces on a patient statement weeks later.

Confirm the schedule is whole, forward and back. The future appointments patients expect to keep have to be there, the recurring series 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. An empty future calendar discovered on go-live morning is a practice that cannot see its own day.

Match the documents, and open some. The totals should line up, so you know the files that were supposed to move actually moved, and 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 whole point of moving them.

Run the live tests, end to end. 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 exercises a connection that has to work before your revenue depends on it, and each is a thing you would much rather find broken in a test than in production.

Write down what you checked and what it showed. The validation is also a record. 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, that the migration held.

Job four: the weeks after go-live

Go-live is a start line. The migration got your data into AdvancedMD, and then the real test begins, because a migration is only as good as the first month of operating that follows it. This is the job practices forget to plan for, having spent all their energy getting to the date, and it is where a clean migration and a rough one start to diverge.

The gaps that survive validation show up here, under the weight of real volume. Claims that looked fine in a test batch reject in bulk against a payer whose setup was subtly wrong. A balance that reconciled at cutover starts to drift because a piece of the configuration handles a routine case differently than the old system did. Authorizations that were carried with the wrong remaining count produce denials on patients everyone assumed were covered. The reports read strangely, because the numbers are drawn from configuration choices made under deadline that no one has pressure-tested against reality yet.

There is a human gap running alongside the technical one. Your staff trained on the new system for a few sessions, and now they meet the parts they never covered with a real patient standing in front of them and a waiting room filling up. Throughput drops while everyone learns, which is normal and temporary and still shows up as fewer patients seen and slower billing in the first weeks. A practice that planned for that dip rides through it. A practice that assumed day one would run at full speed feels it as a crisis.

If you chose to run the old system in parallel, this is where the two-system tax comes due. The old receivables are still being worked in the old system while new work happens in the new one, and someone has to hold both in their head, remember which balance lives where, and keep the two from contradicting each other. This is manageable if it was planned and miserable if it was not, and it is a strong argument for having run the old receivables as low as possible before the switch.

This is the stretch where a set of eyes that knows the system earns its place, watching the claims actually pay, the balances actually reconcile, and the numbers actually hold, and catching the quiet problems while they are still small and cheap. The distance between the data loaded and the practice runs clean is exactly where a first month of cash is won or lost. The practices that treat go-live as the finish line are the ones still finding migration problems six months later, in the form of aged claims and a cash gap nobody can quite explain, long after anyone thought to connect it back to the move.

How long a migration takes, and why it slips

There is no single number for how long an AdvancedMD migration takes, and anyone who gives you one without seeing your data is guessing. The honest answer is that it scales with a few things and it is floored by one.

It scales with how much data you carry, how many payers you bill, and how many documents you have to move. A single-provider practice with a handful of payers and a clean data set is a different project from a ten-provider group with decades of history, a wall of payers, and a basement of scanned charts. A larger patient list is more coverage to verify. A longer payer roster is more setup and more enrollment queues to sit in. A deep archive of documents is a matching job that can run for months by itself. None of that compresses just because you want a date.

It is floored by payer enrollment. Sending claims and receiving electronic remittances requires enrollment with a clearinghouse and with your payers, and those approvals arrive on the payer’s schedule, not yours. Electronic prescribing for controlled substances adds its own slower enrollment. This is the piece that most often sets the earliest date a migration can realistically finish, and it is almost always underestimated, because it is invisible until you are waiting on it. You cannot start it late and make it up later. It is the long pole, and the whole timeline hangs from it.

Here is the shape of it, so you can plan. First come the decisions, then you start the enrollments, because they are the slowest thing and every day you wait on them is a day added to the end. Then, in parallel, you get the data out of the old system, clean it, and set up the configuration, several jobs running at once, none of them waiting for the others. The documents move alongside. When the setup is far enough along, a test batch loads and you check it. Then, on a planned date, the cutover, followed by the weeks of stabilizing when you find out what the tests did not.

The reason practices underestimate all of this is simple and expensive. They see the data conversion, they get a tidy quote for it, and they price the whole migration off that one number, because it is the one piece with a clear price on it. The conversion is the part with a price precisely because it is the well-defined part. The three jobs around it, the deciding, the extraction, the document move, the configuration and enrollment and validation, are most of the effort and rarely show up on the first invoice anyone looks at. A migration planned off the conversion price alone is a migration planned off the smallest piece of it.

The cost of rushing is not abstract. A date set by optimism instead of by the enrollments means going live before you can send claims, which means a month with no cash coming in while the practice is fully open and fully staffed. That is the most expensive way to be early. Set the date backward from the slowest thing you depend on. A migration that finishes a few weeks later than you hoped costs far less than one that goes live before it can bill.

The ways migrations go wrong, and how each one shows up

Migrations fail in a small number of recognizable ways. Each one has a moment it becomes visible, and by then it is usually expensive. Knowing the shape of each is how you catch it while it is still cheap.

The budget for one job. The practice priced the whole migration off the conversion quote, because that was the number with a price on it, and had no plan or budget for the extraction, the documents, the configuration, and the validation. It shows up as a project that keeps costing more than expected and a team that is out of hours halfway through, and it is felt as a scramble for time and money that was never allocated.

The enrollment surprise. The payer and clearinghouse enrollments were started late, because they were invisible until someone went looking for them. It shows up as a go-live date that slips, then slips again, because the practice literally cannot send claims until approvals it does not control come through. It is felt weeks before go-live, as a date coming apart for a reason no amount of effort can speed up.

The stranded receivables. The practice went live with real money still owed inside the old system and no plan to work it there. It shows up as aged claims that no one is chasing, in a system the billing team has half-forgotten, while they also learn a new one. It is felt a month or two later, as collections that came in lower than they should have, with the reason buried in the switch.

The unexplained balance. Summary balances were carried into the new system without the transaction history that explains them. It shows up the first time a patient calls to ask what a charge is for and the front desk cannot answer, because the charges and payments that add up to it are in a system nobody opens. It is felt as a steady drip of calls the practice cannot resolve, and patients who trust the bill a little less each time.

The document dump. The files were imported in bulk without being matched, named, and filed. It shows up when a provider opens a chart mid-visit and the history is not there, or a records request lands and the answer is buried in a thousand identical file names. It is felt at the point of care and in the compliance office, which are the two worst places to discover it.

The coverage backlog. Coverage came across incomplete or with stale effective dates. It shows up as claims rejecting through the whole first week on the new system, each for a missing group number or a subscriber or a payer no longer responsible. It is felt as a month of cash stalled while coverage is corrected one patient at a time, which reads like the new system is broken when the data was the problem.

The authorization wave. Authorizations were not carried, or came across with the wrong remaining counts or date ranges. It shows up as denials three weeks in, on patients everyone was sure were covered, for visits already delivered. It is felt hardest by practices whose payers cap visits or require approval, as care given that will not be paid for.

The credentialing gap. A provider was not actually enrolled with the payers at the new group or location, or an effective date was wrong, and no setting in the software fixes a gap that lives outside it. It shows up as every claim for that provider denying, regardless of how clean the configuration is. It is felt as a provider working full days whose work is not getting paid, sometimes for weeks, until the enrollment is sorted.

The supervising-provider misbill. Supervised claims, care delivered by one provider and billed under another, were coded without matching each payer’s rules. It shows up either as rejections, when the payer will not accept the claim as billed, or as clawbacks, when the payer pays and later takes it back after review. The second is worse, because it feels like income until it is reversed, sometimes long after it was spent.

The go-live on hope. Validation was skipped, or reduced to a glance, because the date was promised and everyone wanted it done. It shows up as every one of the failures above, discovered not by a check the practice ran but by the patient or payer who hit it. It is felt as a go-live that seemed fine for a week and then unraveled, at a price far higher than the check would have cost.

A readiness checklist

You are ready to start the move, not finish it, when the decisions are made and the preconditions are set. Before your real export leaves the old system, these should be true.

If most of these are not yet true, you are not ready to export. You are ready to plan, which is the cheaper place to still be.

Common questions

What is the difference between data conversion and data migration?

Data conversion is the process AdvancedMD runs to load your prepared file into their system. The migration is the whole project around it: getting your data out, deciding what moves, cleaning it, moving documents, configuring the system, cutting over, and validating. The conversion is the last step of it.

Does AdvancedMD migrate my historical financial data?

Mostly no. The tiered conversion moves your structured records, but the transaction history behind your balances, the payments, adjustments, claims, and remittances, generally does not convert into the new ledger. The standard path is to run your open receivables down in the old system first and archive the closed history.

Will my patients’ balances be correct after the migration?

A carried balance arrives as a summary only, without the transaction detail behind it, so the number moves but its history usually does not. That is why live money is safest worked down in the old system first. Otherwise a patient asking what a charge is for needs the archived old system.

Can I keep my old system after I switch?

Usually yes, and you often should, at least read-only for a period. Questions about old balances, claims, and records do not stop when you go live, and the answers live in the system you are leaving. Check your contract for the notice period and any fee before you set your timeline.

How long does an AdvancedMD data migration take?

There is no single answer. It scales with how much data, how many payers, and how many documents you have, and it is floored by payer enrollment, which runs into weeks on the payer’s schedule, not yours. Plan the date backward from those enrollments, not forward from a target.

When should I start the payer enrollments?

As early as possible, ideally the moment you decide to migrate. Enrollments are the slowest part of the project and the one you least control, so every day you wait is a day added to the end. They set your earliest possible go-live date, so they belong at the front of the plan.

What does AdvancedMD’s data conversion include?

It loads your structured data through defined tiers, from patient demographics at the smallest up to full practice management data at the largest, in a staged process of analysis, cleansing, testing, and a live cutover. Your documents and detailed financial history sit outside the tiers and are handled separately.

Do my scanned documents come across in the conversion?

No. Clinical charts, intake forms, insurance cards, and correspondence live as files, which is a separate job from the structured data conversion. Each file has to be tied to the right patient, named, and filed so it stays findable, and that work runs in parallel and needs its own owner.

How are authorizations handled?

They are carried and re-entered as their own records, not pulled along with the demographics. The approval, the visits used, the count remaining, the dates, and the service all have to move accurately, especially mid-treatment. For practices whose payers cap visits, the remaining count is the high-stakes piece.

Do provider credentialing and enrollment transfer automatically?

No. Credentialing and payer enrollment live outside the software, tied to the practice, the location, and often an effective date. A provider is not automatically enrolled at a new group just because they were enrolled elsewhere, and if enrollment is missing, the claims deny however the system is set up. Confirm it early.

What about telehealth and supervising providers?

Telehealth visits carry their own place-of-service code and often a modifier, and the rules vary by payer and change often, so the setup must match current rules. Care billed under a different provider than delivered it, such as incident-to, also varies by payer. Both are common denial sources when the setup misses them.

Can I migrate more than one practice into one AdvancedMD account?

Yes, and the real work is reconciling the practices before anything loads, because two offices rarely code, name payers, or classify balances the same way. Deciding once how the combined group will run, and settling those differences on paper first, is far cheaper than untangling mixed data afterward.

What most often delays a migration?

Payer and clearinghouse enrollment. The approvals that let you send claims and receive electronic remittances arrive on the payer’s timeline, and they are the piece practices most often underestimate, because they are invisible until you are waiting on them.

Each part of a migration, in depth

This page is the whole scope in one place. Each of the parts below has its own guide that goes deeper into what it takes, where it goes wrong, and how to keep it from setting your date or stranding your cash.

Who does this

AdvancedMD moves a clean, mapped file into their system safely and on a schedule. That part works, and it is the smaller part. Getting to that clean file, prying your data out of the old system, deciding what happens to the money that will not move with it, carrying the documents into a shape you can actually use, setting the system up so your first day runs clean, and proving the whole thing held, all of that takes someone who knows where every piece is supposed to land in AdvancedMD before your data ever gets there. That knowledge is the difference between a migration you survive and a migration you barely notice.

PracticePath is not affiliated with, endorsed by, or sponsored by AdvancedMD. AdvancedMD® is a registered trademark of Global Payments. All references to AdvancedMD are for informational purposes and to identify the software environment our services support.