Migrating from Office Ally

Short answer

Moving off Office Ally is not one migration — it is at least two, depending on how your billing operation actually uses the platform. If your team runs claims through Service Center and does everything else in a separate tool, the migration is largely an EDI enrollment project: stand up Medi, re-enroll your payers through Stedi, and run a two-week parallel period to confirm ERAs are landing correctly. If your team runs patient records, scheduling, and billing in Practice Mate, you have a data extraction project sitting in front of the enrollment project. The two are fundamentally different in scope, and conflating them is the most common planning error. The data that Office Ally gives back is real but narrow: patient demographics export in CSV, claim history exports as Excel-compatible reports, and ERA files download as 835 or readable text. Practice Mate's appointment history and clinical charts require a support request to Office Ally — they do not self-export. Open-claim working state, in-flight denial notes, and unposted ERAs do not move cleanly through any export path. Plan thirty to forty-five days for a single-practice migration that includes payer enrollment. A billing company moving multiple client practices should stagger the rollout over six to ten weeks, not attempt them together.

Are you using Office Ally as a clearinghouse, a PM, or both?

This is the first question to answer before anything else, because it determines the shape of the entire migration.

A clearinghouse-only relationship means your team submits 837 files through Service Center and retrieves 835 ERAs, but patient records live somewhere else — a standalone EHR, a separate PM, or a spreadsheet-driven workflow. The migration from this configuration is operationally lighter. Your patient and ledger data does not need to move through an Office Ally export. The work is almost entirely payer enrollment: decommission the Service Center trading-partner connections, establish Stedi as your new clearinghouse, re-enroll the payers that require a separate EDI enrollment, and run a parallel period to confirm claim submissions and ERA retrieval are clean. You will still need to extract historical ERA files from Service Center before closing the account, because Office Ally does not document a retention window for former customers.

A Practice Mate relationship means your team uses Office Ally as a combined clearinghouse and practice management system. Patient demographics, insurance information, authorizations, scheduling, charge entry, claim status, and ERA posting all flow through the same platform. This migration has a data extraction project in front of the enrollment project. Patient demographics export directly in CSV format. Claim history and financial reports export to Excel. Appointments and clinical charts require you to contact Office Ally support and request the export — they do not self-serve from within Practice Mate. None of these exports carry billing open-claim state forward. Denied claims in flight, appeal documentation, follow-up notes, and unposted ERAs at the time of cutover stay in Practice Mate; the migration path for those is to work them down or document them into a handoff before you close the account.

A hybrid relationship is also common: some client practices on Practice Mate, others whose EHR pushes claims into Service Center directly, perhaps a few using a third-party PM that connects through the Office Ally payer gateway. Map each client practice to its actual usage pattern before building a migration plan. The answer is usually not uniform across the book.

If you want a fuller comparison of how these configurations stack up before committing to a switch, the Office Ally comparison page covers pricing mechanics, workflow gaps, and stack-role differences in depth.

Plan for thirty to forty-five days

Per published industry guidance on switching RCM platforms, a clean single-practice transition takes thirty to forty-five days when payer enrollment, data extraction, and A/R continuity planning run in parallel rather than in sequence. Compressing that to under three weeks routinely produces A/R leakage on aged claims that stop being worked during the chaos of cutover. The Medical Billers and Coders 30-Day Transition Playbook puts the revenue loss from under-three-week transitions at eight to twelve percent of trailing A/R.

Office Ally's cost structure introduces a wrinkle that most migration timelines do not account for. Because Service Center has no contract and no cancellation fee, there is a temptation to treat it as an on-off switch — move to Medi, close the Office Ally account, done. That works for the clearinghouse relationship if enrollment is complete and the parallel period confirms everything. It does not work if Practice Mate holds claim history you have not extracted, ERAs you have not downloaded, or open claims still being worked. Access to historical data depends on the account staying open. Close it too early and the history is gone.

The two things to lock down contractually before cutover:

The outgoing billing arrangement for any client practice continues to work all claims with dates of service prior to cutover for sixty days minimum, with aging reconciliation reported weekly. That applies whether the outgoing arrangement is your own team running Office Ally or a prior billing company.

The billing company or practice owns the trailing A/R outright, with documented access to claim history for the duration of that sixty-day closeout and a defined process for extracting it before account closure. This clause is often skipped when leaving a free platform because there is no vendor negotiation involved — but it still matters for internal operational planning. Write it into your own migration checklist.

What Office Ally actually exports

The exports that come out of Office Ally without a support request are narrower than most billing companies expect going in.

Patient demographics export directly from Practice Mate in CSV or Excel format, and this is the cleanest transfer. The file structure is standard enough that most receiving platforms can ingest it with minimal reformatting, though column mapping always needs to be verified practice by practice.

Claim history exports through Practice Mate's reporting module as Excel-compatible files. You can filter by date range and apply basic parameters, but the output is a flat report — not a structured data format that can be re-imported as live claims into another system. The value of this export is historical reference and A/R aging continuity, not claim portability. Import it as read-only reference data, not as working claims.

ERA files download from Service Center in two formats: a raw 835 ANSI file and a human-readable text version. Office Ally packages them as a zip file, accessible by date through the Download EOB/ERA interface. These are your posted payment records. Export them by month before closing the Service Center account. The 835 files are the machine-readable archive; the text files are for staff reference. Keep both.

Appointments and clinical charts from Practice Mate or EHR 24/7 require a support request to Office Ally. They do not export on demand. Office Ally will deliver them in Excel or CSV format when requested, but the timeline for fulfillment is not documented publicly. Submit the request early in the migration process, not the week before cutover.

What does not export at all: open-claim follow-up notes, in-flight denial tracking, appeal documentation tied to specific claims, custom per-payer scrub rules, and the working state of any claim that is mid-adjudication at the time of export. These are either screen-captured and added to a handoff document, re-entered manually into Medi, or left in Place Mate under a read-only legacy access window.

One critical operational note: Office Ally does not publicly document how long it retains data for inactive or closed accounts. Before closing the account, download every ERA file you will need, export every report you reference in client reporting, and confirm that the exported files open and display correctly. Do not assume you can come back later.

Migration planning checklist

EDI enrollment is the long pole

Whether your migration is clearinghouse-only or a full Practice Mate departure, payer enrollment is almost always the constraint that sets the cutover date. Data extraction can be parallelized and accelerated. Enrollment cannot be rushed.

The CMS Electronic Billing and EDI Transactions guidance describes a baseline enrollment process that takes weeks per payer, with meaningful variance by payer family, state, and transaction type. A few enrollment realities that cause problems during Office Ally departures specifically:

Office Ally has its own submitter IDs registered with each payer. When you move to Medi and Stedi, the submitter ID changes. Any payer that requires enrollment — and many do — needs a new enrollment application under the new submitter ID. The fact that you were enrolled through Office Ally does not carry forward. This is not an Office Ally policy; it is how payer enrollment works across every clearinghouse transition.

ERA enrollment is a separate process from 837 claim submission enrollment. It is common to complete claim submission enrollment, begin submitting claims, and not receive ERAs for several weeks because the 835 enrollment was filed separately and takes longer to activate. File both at the same time. Confirm both are active before declaring cutover complete.

Medicare and state Medicaid programs have their own enrollment processes and their own timelines, both of which run longer than commercial payers in most cases. If Medicare and Medicaid represent a meaningful share of your volume — and for many Office Ally users they represent the majority — start those enrollment applications the day the migration decision is made.

The Anthem and Elevance family of payers routes through Availity as their EDI gateway. If your current Office Ally setup routes Anthem through the Service Center payer gateway, that connection gets re-established through Availity on the Medi side. BCBS enrollment varies by state plan; the Texas enrollment is not the California enrollment. Regional Medicaid managed care plans often have their own enrollment requirements on top of the base state Medicaid process.

Start enrollment work the day the migration decision is made, not the day the data extraction is complete.

Parallel-run plan

The legacy A/R closeout and the forward-only Medi cutover run side by side for at least two weeks, and often four to six. The shape that protects revenue and catches routing errors:

New billing in Medi starts for any encounter with a date of service on or after the cutover date. Nothing submitted before cutover moves to Medi as an active claim.

Office Ally stays open for all claims with dates of service before cutover. ERAs for those claims continue to land in Service Center and get posted there. If Practice Mate was the PM, the practice continues to log payment posting activity in Practice Mate for the legacy period.

Both systems receive ERAs for at least the first two weeks so totals can be reconciled payer by payer. Some payers route ERAs based on the submitter ID that submitted the original claim. If a claim went out under the Office Ally submitter ID, the ERA often comes back to Office Ally regardless of which system you prefer. This is expected behavior, not a routing error, and the parallel period is specifically designed to catch it.

The outgoing Office Ally arrangement reports A/R aging weekly until legacy claims are resolved or written off. For a billing company managing multiple client practices, this reporting obligation applies per practice.

Reconciliation meetings — daily for the first two weeks, weekly thereafter — between the teams responsible for each system confirm that payments are not being double-posted, that aged claims are still being worked in the right system, and that the ERA routing is landing where it should.

The clearinghouse-only migration runs a shorter parallel period because there is less operational surface to reconcile. Two weeks of confirmed ERA receipt in Medi, per payer, is typically sufficient to close the parallel run for a straightforward Service Center departure.

A practice-by-practice rollout protects everyone

A billing company with eight client practices should not move all eight in the same weekend. Moving them together compounds every enrollment gap, data extraction issue, and user training problem into a single failure window. The shape that recovers from problems:

Move the smallest practice with the simplest payer mix first. This is the proving run. Run it end to end in Medi for two full weeks before touching the next practice.

Apply what the first cutover taught you: which payer's ERA enrollment came back slower than expected, which scrub rule did not transfer cleanly, which staff needed more time with Medi's denial queue before they were productive. Those lessons cost nothing to apply to the next cutover if you do them in order.

Move the largest and most complex practices last, after the operational pattern is stable. The practices with the highest claim volume, the most payers, and the most denial complexity are the ones where a migration mistake costs the most. They should not be the proving run.

A book of eight practices moves cleanly over six to eight weeks under this shape. Twenty practices moves over three to four months. The trade is calendar time for execution risk, and it is a trade worth making. For more on how Medi structures multi-practice billing operations, see the billing company operations guide.

What does not migrate, and what to do about it

Open-claim working notes do not survive any Office Ally export. For every claim that is still open at cutover, document the working state in a structured handoff: payer, claim number, denial reason, last action taken, next action due, and who owns it. That document travels with the claim into the sixty-day legacy closeout period.

In-flight appeal documentation does not move. For each open appeal, record the payer reference number, submission date, appeal level, supporting documentation list, and next-action date. Keep that documentation in a shared location accessible to both the staff working the legacy period in Office Ally and the staff standing up Medi.

Per-payer custom scrub rules configured in Practice Mate do not export and do not re-import automatically. These rules often encode years of learned billing behavior for specific payers — modifiers that a given payer always rejects, diagnosis code combinations that require additional documentation, procedure codes that need to be billed with a specific revenue code. Inventory them before cutover and re-implement them in Medi's scrub configuration.

Unposted ERAs sitting in the Service Center queue at cutover should be posted in Office Ally before closing out. Do not attempt to migrate unposted remittances. The reconciliation complexity is not worth it.

Author attribution on any clinical content from EHR 24/7 does not carry forward in exported files. If chart history matters for billing audit purposes, keep a read-only EHR 24/7 login active for the historical record rather than relying on the exported copy.

What absolutely must move

Patient demographics, including all active insurance coverages, secondary and tertiary payers, and authorization records tied to active treatment episodes.

Provider NPIs, taxonomy codes, individual and group Tax IDs, and any billing identifiers the payers have on file for each rendering provider.

Active payer enrollment status, documented per payer per NPI, so the Medi enrollment applications reference the correct information and the active connections are not accidentally deactivated during the transition.

User accounts and practice access restrictions, rebuilt in Medi before the first day of production use. Staff who can see only specific client practices in the current setup should have the same restrictions in Medi on day one.

Custom fee schedules where they differ from Medicare allowables, particularly for commercial payer contracts where the contracted rate affects expected payment and underpayment detection.

At minimum the last twelve months of paid claim history and posted payment records, in the exported formats Office Ally provides, stored as reference data for reporting continuity and A/R aging baseline.

Historical ERA files in 835 format, downloaded by month before the Service Center account closes.

Day-zero cutover checklist

On the day a practice migrates:

Confirm Office Ally is in read-only mode for new claim creation for that practice. No new claims enter Office Ally after cutover for that practice.

Confirm Medi has accepted the patient and provider imports for that practice and the data is visible, correctly mapped, and searchable.

Confirm payer enrollment in Medi is active for at least the top three payers by claim volume for that practice. Do not cut over if the top payer is not enrolled.

Confirm the first test claim submission in Medi for that practice passes scrub, routes through Stedi, and reaches the clearinghouse with an accepted acknowledgment.

Confirm the first ERA can be received in Medi for at least one active payer connection. An ERA that does not land in the first two days is a signal that the 835 enrollment is not complete.

Confirm that the billing staff assigned to that practice have logged into Medi, can see the practice, and can navigate the work queues without assistance.

Notify the client practice that Office Ally is read-only for new work and that Medi is live.

Document the cutover date, the enrolled payer list, and any enrollment gaps still outstanding, so the parallel-run reconciliation team knows exactly what to watch.

Frequently asked questions

How is an Office Ally migration different from migrating off a full billing platform like Tebra?

The clearest difference is that Office Ally's export surface is shallower, the cost calculus during migration is different, and the reason most users leave is UX rather than pricing. Tebra's export includes XML Summary of Care files and a thirty-day SLA for data services. Office Ally's export is CSV demographics, Excel claim history reports, and ERA downloads — functional but not structured for re-import into another platform. The cost math is also different: because Office Ally's base tier is free for participating-payer volume, the saved fees from leaving may be small compared to the operational overhead of migration. The ROI question for an Office Ally departure is usually about operational depth — multi-practice visibility, denial workflows, ERA review tooling — not about reducing the monthly bill. See the Tebra migration guide for a direct comparison of what a full-platform departure looks like.

What happened to the non-par fee in January 2026 and does it affect my migration math?

Before January 1, 2026, Office Ally's non-par processing fee of $44.95 per unique Tax ID and Rendering NPI combination applied when fifty percent or more of that combination's monthly claim volume went to non-participating payers. Effective January 2026, Office Ally changed the trigger: the fee now applies if any non-par claims are submitted for that Tax ID and NPI combination in the month, regardless of volume percentage. For a billing company with providers who submit even occasional claims to commercial PPOs classified as non-par — and many mid-sized commercial PPOs are non-par — this change materially increases the monthly non-par fee exposure. A billing company with ten rendering NPIs each submitting a single non-par claim in the month faces $449.50 in non-par fees, before any other charges. Run the calculation against your actual payer mix and your current Office Ally invoices before concluding that leaving is cost-neutral or cost-negative. For many billing companies with meaningful commercial volume, the January 2026 fee change is itself the trigger that tips the migration math in Medi's favor. The pricing page has current Medi fee structure for comparison.

Can I keep Office Ally as a backup clearinghouse while running Medi as the primary?

You can, but verify you are not paying two sets of fees for the same payer connections. The configuration that makes sense is a temporary parallel run during migration, not a permanent split. If you route claims through Medi and Stedi and also maintain an active Service Center account with the same payers enrolled, you are paying for redundant clearinghouse connections. Office Ally did continue processing claims independently during the 2024 Change Healthcare outage, which is a real operational point in its favor as a backup. If clearinghouse redundancy is a genuine concern for your book, a documented backup clearinghouse relationship with Office Ally is a defensible decision — but price it explicitly rather than leaving it as an open-ended monthly cost.

What does the Jopari acquisition mean for billing companies currently on Office Ally?

The April 2026 acquisition brings Jopari's workers' compensation, auto medical, and property-and-casualty electronic billing capabilities into the Office Ally clearinghouse network, along with Jopari's clinical attachment infrastructure and electronic payment processing. For billing companies whose book is primarily commercial and government health insurance, the acquisition does not change the core Service Center product materially in the short term. The integration roadmap is not publicly disclosed. The acquisition is most consequential for billing companies with meaningful P&C or workers' comp volume, where Jopari was a specialist. If your book includes significant workers' compensation billing and you have been running that volume through a separate Jopari relationship, verify with Office Ally directly what the combined product looks like before making any migration decision in that segment. For standard health insurance billing, the acquisition is background news worth monitoring rather than an immediate operational factor.

How long does Office Ally keep my data after I close the account?

Office Ally does not publicly document a retention window for data belonging to closed accounts. Their FAQ and support documentation address active account usage but are silent on what happens after termination. This is the reason to extract everything you need — ERA files by month, patient demographics, claim history reports, and any requested appointment or chart data — before closing the account, not after. Treat the account-open period as your only window for data retrieval.

We are a solo biller with two practices on Practice Mate. Is the migration worth it?

It depends on what is driving the question. If the answer is UX frustration with Office Ally's interface — the navigation patterns that regressed in the newer version, claim search difficulty, ERA data that occasionally fails to populate — that is a real and widely reported pain point, but it is not automatically a migration trigger. If the answer is that your book is growing past five or six client practices and you need cross-practice A/R visibility, denial workflows that span all clients, and role-based access for additional staff, that is the structural gap Medi is designed to close. A solo biller managing two or three practices with predominantly Medicare and Medicaid volume on Office Ally's free participating-payer tier is not Medi's primary target. The billing company software evaluation guide covers the decision criteria in detail. If your practice count and claim volume are at the threshold where multi-practice operational visibility starts to matter, a demo is the right next step.

How current is this guide?

Last reviewed 2026-05-18. Office Ally's pricing, payer participation list, non-par fee criteria, and product scope have all changed historically and will change again. The January 2026 non-par fee threshold change is the most recent material pricing update as of this review. The sources for Office Ally's current fee structure are the Office Ally pricing page and Office Ally's own support documentation on par versus non-par processing fees. The Jopari acquisition was announced April 2, 2026; integration timelines are not yet public. Industry migration timelines are drawn from the Medical Billers and Coders 30-Day Transition Playbook and CMS Electronic Billing and EDI Transactions guidance. Verify all fee amounts and enrollment requirements directly with Office Ally and with each payer before building a cost model or a migration timeline.