Migrating from Office Ally

Short answer

Moving off Office Ally is two migrations, not one, and which you face depends on how your team uses the platform. If you run claims through Service Center and do everything else elsewhere, the migration is an EDI enrollment project: stand up Medi, re-enroll your payers through Stedi, and run a two-week parallel period to confirm ERAs land. If you run patient records, scheduling, and billing in Practice Mate, a data extraction project sits in front of that enrollment project. Conflating the two is the most common planning error.

What Office Ally gives back is real but narrow. Patient demographics export to CSV, claim history exports as Excel-compatible reports, and ERA files download as 835 or readable text. Practice Mate appointments and clinical charts require a support request; they do not self-export. Open-claim working state, in-flight denial notes, and unposted ERAs do not move cleanly through any export path.

For planning, we usually estimate around one business day per practice for the Medi cutover once exports and payer-enrollment inputs are ready. A billing company moving several client practices should still stagger the rollout, with payer enrollment and legacy A/R closeout tracked in parallel. Medi migration is free with a 12-month commitment, or a one-time $100 per client practice (capped at $3,000) month-to-month. Data export is always free in standard formats, and there is no early-termination fee on the annual plan.

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

Answer this first. It determines the shape of the entire migration.

**Clearinghouse-only** means your team submits 837 files through Service Center and retrieves 835 ERAs, while patient records live elsewhere. This migration is lighter: your patient and ledger data does not move through an Office Ally export. The work is almost entirely payer enrollment. Decommission the Service Center trading-partner connections, establish Stedi as the new clearinghouse, re-enroll the payers that require separate EDI enrollment, and run a parallel period to confirm clean claim submission and ERA retrieval. Extract historical ERA files from Service Center before closing the account; Office Ally does not document a retention window for former customers.

**Practice Mate** means Office Ally is your combined clearinghouse and practice management system, with demographics, insurance, authorizations, scheduling, charge entry, claim status, and ERA posting all in one platform. Here a data extraction project comes first. Demographics export directly to CSV, and claim history and financial reports export to Excel. Appointments and clinical charts require a support request; they do not self-serve from Practice Mate. None of these exports carry open-claim state forward. Denied claims in flight, appeal documentation, follow-up notes, and unposted ERAs stay in Practice Mate. Work them down or document them into a handoff before you close the account.

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

For a fuller view of how these configurations compare before you commit to a switch, the Office Ally comparison page covers pricing mechanics, workflow gaps, and stack-role differences.

Estimate around a day per practice

As a working estimate, a clean Medi cutover is often around one business day per practice once the Office Ally exports, provider identifiers, payer inventory, and user list are ready. Payer enrollment, data extraction, and A/R continuity still run in parallel, so the cutover estimate should not be confused with the whole transition. The revenue risk is unmanaged aged claims during transition, not a fast go-live.

Office Ally's cost structure adds a wrinkle most timelines miss. Because Service Center has no contract and no cancellation fee, it is tempting to treat the move as an on-off switch: cut over to Medi, close the account, done. That works for a clearinghouse relationship once enrollment is complete and the parallel period confirms everything. It fails 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 early and the history is gone.

Lock down two things before cutover, even though you are leaving a free platform with no vendor to negotiate against. Write both into your own migration checklist:

1. The outgoing billing arrangement works every claim with a date of service before cutover for at least sixty days, with aging reconciliation reported weekly. This holds whether the outgoing arrangement is your own team on Office Ally or a prior billing company. 2. The billing company or practice owns the trailing A/R outright, with documented access to claim history for that sixty-day closeout and a defined process for extracting it before the account closes.

What Office Ally actually exports

The exports that come out without a support request are narrower than most billing companies expect.

**Patient demographics** export directly from Practice Mate to CSV or Excel, and this is the cleanest transfer. The structure is standard enough that most receiving platforms ingest it with minimal reformatting, though column mapping still needs verification 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 format you can re-import as live claims. Its value is historical reference and A/R aging continuity. 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, packaged as a zip accessible by date through the Download EOB/ERA interface. These are your posted payment records. Export them by month before closing the 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. Office Ally delivers them in Excel or CSV when asked, but the fulfillment timeline is not documented publicly. Submit the request early, 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 mid-adjudication at export time. Screen-capture these into a handoff document, re-enter them manually into Medi, or leave them in Practice Mate under a read-only legacy access window.

One operational note. Office Ally does not publicly document how long it retains data for inactive or closed accounts. Before closing, download every ERA file you will need, export every report you reference in client reporting, and confirm 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 the migration is clearinghouse-only or a full Practice Mate departure, payer enrollment almost always 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 that takes weeks per payer, with meaningful variance by payer family, state, and transaction type. The realities that bite during Office Ally departures specifically:

**Submitter ID changes.** Office Ally has its own submitter IDs registered with each payer. When you move to Medi and Stedi, that ID changes, so any payer that requires enrollment needs a new application under the new submitter ID. Prior enrollment through Office Ally does not carry forward. This is how payer enrollment works across every clearinghouse transition, not an Office Ally policy.

**ERA enrollment is separate from claim-submission enrollment.** It is common to finish 837 enrollment, start submitting claims, and not receive ERAs for weeks because the 835 enrollment was filed separately and activates more slowly. File both at the same time, and confirm both are active before declaring cutover complete.

**Government payers run longest.** Medicare and state Medicaid have their own processes and timelines, both longer than commercial payers in most cases. For many Office Ally users they are the majority of volume. Start those applications the day the migration decision is made.

**Anthem and Elevance route through Availity.** If your current setup routes Anthem through the Service Center payer gateway, that connection re-establishes through Availity on the Medi side. BCBS enrollment varies by state plan; Texas is not California. Regional Medicaid managed care plans often add their own requirements on top of base state Medicaid.

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

Parallel-run plan

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

1. **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. 2. **Office Ally stays open** for all claims with a date of service before cutover. ERAs for those claims keep landing in Service Center and get posted there. If Practice Mate was the PM, the practice keeps logging payment posting in Practice Mate for the legacy period. 3. **Both systems receive ERAs** for at least the first two weeks so totals reconcile payer by payer. Some payers route ERAs by the submitter ID that filed the original claim, so a claim sent under the Office Ally submitter ID often comes back to Office Ally regardless of preference. That is expected behavior, and the parallel period exists to catch it. 4. **A/R aging reports weekly** from the outgoing Office Ally arrangement until legacy claims resolve or are written off. For a multi-practice book, this reporting applies per practice. 5. **Reconciliation meetings** — daily for the first two weeks, weekly after — confirm payments are not double-posted, aged claims are worked in the right system, and ERA routing lands where it should.

A clearinghouse-only migration runs a shorter parallel period because there is less to reconcile. Two weeks of confirmed ERA receipt in Medi, per payer, is typically enough to close it.

A practice-by-practice rollout protects everyone

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

1. **Move the smallest, simplest-payer-mix practice first.** This is the proving run. Run it end to end in Medi for two full weeks before touching the next. 2. **Apply what it taught you** to the next cutover: which payer's ERA enrollment came back slow, which scrub rule did not transfer cleanly, which staff needed more time in Medi's denial queue. Those lessons cost nothing to apply in order. 3. **Move the largest, most complex practices last,** once the pattern is stable. The practices with the highest volume, most payers, and deepest denial complexity are where a migration mistake costs the most. They should not be the proving run.

For a ready book, around a day per practice is a reasonable cutover estimate. Larger books still move practice by practice while payer enrollment and legacy A/R continue in parallel. For how Medi structures multi-practice 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 still open at cutover, document the working state in a structured handoff: payer, claim number, denial reason, last action taken, next action due, owner. That document travels with the claim into the sixty-day legacy closeout.

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

**Per-payer custom scrub rules** configured in Practice Mate do not export or re-import automatically. They often encode years of learned billing behavior: modifiers a payer always rejects, diagnosis combinations that require extra documentation, procedure codes that need a specific revenue code. Inventory them before cutover and re-implement them in Medi's scrub configuration.

**Unposted ERAs** in the Service Center queue at cutover should be posted in Office Ally before closeout. Do not migrate unposted remittances; the reconciliation complexity is not worth it.

**Author attribution** on EHR 24/7 clinical content does not carry forward in exported files. If chart history matters for billing audit, 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 payers have on file for each rendering provider.
• Active payer enrollment status, documented per payer per NPI, so Medi applications reference the correct information and active connections are not accidentally deactivated during the transition.
• User accounts and practice access restrictions, rebuilt in Medi before the first day of production. Staff who can see only specific client practices today should have the same restrictions in Medi on day one.
• Custom fee schedules where they differ from Medicare allowables, especially commercial payer contracts where the contracted rate drives expected payment and underpayment detection.
• At least the last twelve months of paid claim history and posted payment records, in the 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:

1. Confirm Office Ally is read-only for new claim creation for that practice. No new claims enter Office Ally after cutover. 2. Confirm Medi has accepted the patient and provider imports and the data is visible, correctly mapped, and searchable. 3. Confirm Medi payer enrollment is active for at least the top three payers by claim volume. Do not cut over if the top payer is not enrolled. 4. Confirm the first test claim in Medi passes scrub, routes through Stedi, and reaches the clearinghouse with an accepted acknowledgment. 5. Confirm an ERA can be received in Medi for at least one active payer connection. An ERA that does not land in the first two days signals incomplete 835 enrollment. 6. Confirm the billing staff assigned to that practice have logged into Medi, can see the practice, and can navigate the work queues without help. 7. Notify the client practice that Office Ally is read-only for new work and Medi is live. 8. Document the cutover date, the enrolled payer list, and any outstanding enrollment gaps, so the 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?

Office Ally's export surface is shallower, the cost math during migration is different, and the reason most users leave is UX rather than price. 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. The cost math differs too: because Office Ally's base tier is free for participating-payer volume, the fees you save by leaving may be small against the operational overhead of migrating. The ROI question for an Office Ally departure is usually operational depth (multi-practice visibility, denial workflows, ERA review tooling), not a lower monthly bill. See the Tebra migration guide for 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. As of January 2026, the trigger changed: 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 materially raises monthly non-par exposure. Ten rendering NPIs each submitting one non-par claim in a month face $449.50 in non-par fees before any other charges. Run the calculation against your actual payer mix and current invoices before concluding that leaving is cost-neutral. For many billing companies with meaningful commercial volume, this fee change is itself the trigger that tips the migration math toward Medi. The pricing page has the current Medi fee structure for comparison.

Can I keep Office Ally as a backup clearinghouse while running Medi as 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. Routing claims through Medi and Stedi while also maintaining an active Service Center account with the same payers enrolled means paying for redundant connections. Office Ally did keep processing claims independently through the 2024 Change Healthcare outage, which is a real point in its favor as a backup. If clearinghouse redundancy is a genuine concern for your book, a documented backup relationship with Office Ally is defensible, 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 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, it does not change the core Service Center product materially in the short term, and the integration roadmap is not public. It matters most to billing companies with meaningful P&C or workers' comp volume, where Jopari was a specialist. If your book includes significant workers' compensation billing run through a separate Jopari relationship, verify with Office Ally directly what the combined product looks like before making a migration decision in that segment. For standard health insurance billing, treat it as background news to monitor.

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

Office Ally does not publicly document a retention window for closed-account data. Their FAQ and support documentation cover active account usage but are silent on what happens after termination. That 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 it is UX frustration with Office Ally's interface — navigation 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 not automatically a migration trigger. If 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 more staff, that is the structural gap Medi is built to close. A solo biller managing two or three practices with mostly 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. If your practice count and claim volume are at the threshold where multi-practice visibility starts to matter, a demo is the right next step.

What does it cost to migrate to Medi?

Migration is free with a 12-month commitment. Month-to-month, it is a one-time $100 per client practice, capped at $3,000 total regardless of book size. Data export is always free in standard formats, and there is no early-termination fee on the annual plan. Medi platform pricing is $20 per client practice per month, with volume pricing available ($15 for practices 26 to 50, $10 beyond 50). There is no per-provider fee and no contract required. Claims are billed at a flat $0.70 each, with ERA included and no separate remittance fee. Volume steps down to $0.65 from 501 to 5,000 claims a month and $0.55 beyond 5,000. Other transactions: eligibility $0.25, claim status $0.20, COB and attachments $1.50. The annual commitment is the only lock-in; your data never is.

How current is this guide?

Last reviewed 2026-06-07. 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. Sources for the current fee structure are the Office Ally pricing page and Office Ally's support documentation on par versus non-par processing fees. The Jopari acquisition was announced April 2, 2026; integration timelines are not yet public. Transition-risk benchmarks draw from the Medical Billers and Coders 30-Day Transition Playbook and payer-enrollment constraints from CMS Electronic Billing and EDI Transactions guidance. Verify all fee amounts and enrollment requirements directly with Office Ally and each payer before building a cost model or timeline.