MEDITECH MAGIC End of Life: Legacy Data After Expanse

MEDITECH has not published a public end-of-life date for MAGIC or Client/Server, and both still appear on its ONC certification page. The deadline that bites is local: when your hospital cuts over to Expanse, most of the history stays behind in MAGIC, and you must decide whether to keep it read-only, archive it, or integrate it.

Three dates matter here: when MEDITECH stops supporting your release (set by your contract), when clinicians stop documenting in MAGIC (your go-live), and when the legacy servers are finally switched off (your decommissioning). State law sets how long the chart left in MAGIC must be kept, which is often a decade or longer.

Is MEDITECH MAGIC at end of life?

Not by any public date. MEDITECH's own certification page still lists MAGIC and Client/Server v5.67c products certified to the 2015 Edition Cures Update, dated September 2022, and its 2025 Real World Testing results report (last updated January 19, 2026) reports API usage measured for "legacy platform customers" on both. Certification is not a support commitment, though, and neither page says how long either release will be maintained.

What MEDITECH does publish is a migration path it describes as designed "for our MAGIC and Client/Server customers," and customers are taking it. MEDITECH said in June 2022 that 50 legacy customers chose to migrate to Expanse in 2021, citing the 2022 KLAS US Market Share Report. Moving is not legally mandatory, and some hospitals leave MEDITECH entirely instead. Either way, ask your MEDITECH account team in writing what support, regulatory updates and hosting remain for your exact release, and for how long. Ask separately about the operating system, database and hardware under it, which often reach their own vendor deadlines first.

Go-live does not end MAGIC on its own. Late documentation, result corrections and payment posting can keep landing in the legacy system for weeks, so set a written cutoff for each kind of activity and plan a final incremental extract after it.

MAGIC vs Client/Server vs 6.x vs Expanse: what is the difference?

They are four generations of the same vendor's EHR. MAGIC and Client/Server share the 5.x release line (both are certified as v5.67), 6.x was a new platform generation, and Expanse grew out of 6.x. Dates come from MEDITECH's corporate history as summarized on Wikipedia and from MEDITECH's certification listings.

The 2015 Edition archive listing "MEDITECH Expanse (6.16) Core HCIS v2.1" is the clearest public evidence of that lineage. For data planning, a MAGIC or Client/Server site moving to Expanse is converting between different platform generations, so the conversion scope decides what history comes along. A 6.x site shares more with Expanse, but it should still read its own scope document rather than assume everything carries over.

How much MAGIC history converts to Expanse?

Usually a few years of clinical data, not the whole chart. Archive vendor Harmony Healthcare IT wrote in 2023 that "most of the time, about two years of legacy data is migrated," and described Magnolia Regional Health Center in Mississippi, a MEDITECH customer since 1996, moving two years of clinical data to the new platform while leaving more than 20 years of clinical, accounts receivable, payroll and general ledger data behind. Galen Healthcare Solutions' 2020 Expanse conversion guide puts the usual choice at "perhaps three to five years of data."

Both figures come from companies that sell conversion and archive services, so treat them as observations. Your own conversion scope document is the real answer. Read it line by line and list, for each data type (allergies, problems, medications, results, notes, scanned documents, encounters, charges, payments), how many years convert and in what form. Anything with zero years next to it stays in MAGIC.

Some reports fall through the cracks. MEDITECH partner Forward Advantage notes that some MAGIC and Client/Server reports needed for the legal medical record were never sent to MEDITECH Scanning and Archiving and "may not have been converted by your standard data conversion." Your HIM director should sign off on a written definition of the legal medical record before anyone decides the legacy system can go dark.

How long do you have to keep legacy MEDITECH data?

As long as your state's medical record retention law requires, plus any longer period set by Medicare rules, payer contracts, litigation holds or minors' records. HIPAA's six-year rule does not apply to the chart. It covers your HIPAA policies and compliance documentation.

HHS answers the question in its HIPAA FAQ: "The HIPAA Privacy Rule does not include medical record retention requirements. Rather, State laws generally govern how long medical records are to be retained." The six years come from 45 CFR 164.316(b)(2)(i) and 45 CFR 164.530(j)(2), which require you to keep Security Rule and Privacy Rule documentation (policies, procedures, required records of actions and assessments) for six years from creation or the date last in effect, whichever is later.

HIPAA still governs the legacy data while you hold it. The same FAQ says covered entities must apply administrative, technical and physical safeguards to PHI "for whatever period such information is maintained," including disposal. A read-only MAGIC server is in scope for your risk analysis, access reviews and audit logging for as long as it runs.

Two more rules shape the archive design. The designated record set includes billing records as well as medical records, so financial history in MAGIC is subject to patient access requests. Under 45 CFR 164.524 you have 30 days to act on an access request, extendable once by 30 days if you notify the patient in writing within the first period, and you must provide the form and format requested if it is readily producible.

Retention clocks run from different events (last treatment, death, a minor's birthday, the date a record was created) and differ by record type, so the last records in MAGIC may need to be kept 20 years or more after cutover in some states. Ask counsel for a written retention schedule by state and record type before you price any option.

Where can you get data out of MAGIC and Client/Server?

There are four practical surfaces: the Data Repository on SQL Server, the certified EHI export, the certified FHIR API, and report output. Plan on using at least two, since none holds everything.

The MEDITECH Data Repository

MEDITECH describes the Data Repository (DR) as "a separate SQL data warehouse comprised of all MEDITECH data" that works with any ODBC-compliant reporting tool (MEDITECH). It runs on Microsoft SQL Server, and third-party DR tooling such as Iatric's DR Resource Center supports MAGIC, Client/Server, 6.0, 6.1 and Expanse sites. Iatric's report writers point out that nearly every DR table carries a SourceID column in its primary key, and that modules built on MEDITECH's NPR technology use a facility-specific SourceID while M-AT modules use a single facility ID. Joins that ignore SourceID can produce wrong answers in multi-facility systems.

Start by sizing what your DR holds. This query reads SQL Server's system catalog, so it needs no knowledge of MEDITECH's table names. Run it with an account that can see every DR table; the catalog only shows objects you have permission on.

-- Size every DR table (approximate rows) and flag whether it has SourceID
SELECT s.name  AS schema_name,
       t.name  AS table_name,
       SUM(p.rows) AS approx_rows,
       CASE WHEN c.column_id IS NULL THEN 0 ELSE 1 END AS has_sourceid
FROM sys.tables t
JOIN sys.schemas s     ON s.schema_id = t.schema_id
JOIN sys.partitions p  ON p.object_id = t.object_id AND p.index_id IN (0, 1)
LEFT JOIN sys.columns c ON c.object_id = t.object_id AND c.name = 'SourceID'
GROUP BY s.name, t.name, c.column_id
ORDER BY approx_rows DESC;

-- Exact counts per facility/database, for tables where has_sourceid = 1
-- (replace dbo.YourTable with a table from the inventory)
SELECT SourceID, COUNT(*) AS rows_per_source
FROM dbo.YourTable
GROUP BY SourceID
ORDER BY SourceID;

The sys.partitions counts are approximate and good for sizing. For reconciliation, use exact COUNT(*) results and compare them with counts produced on the MAGIC side, usually by NPR reports, for the same date range. A module your hospital never configured for DR replication will simply be missing, and you want to find that out while MAGIC is still running.

The certified EHI export

ONC's certification criterion 45 CFR 170.315(b)(10) requires a certified product to export a single patient's electronic health information, and to create a patient population export, covering the EHI "that can be stored at the time of certification by the product," in a computable format with a published format link. That is the certified product's data, not every system in the hospital. MEDITECH's EHI Export documentation describes two configurations. Configuration 1, which covers MAGIC and Client/Server acute sites among others, packages electronic chart documents, US Core FHIR data, C-CDA documents and supplemental reports. Configuration 2, for MAGIC and Client/Server acute and ambulatory sites using MRI and the DR, delivers patient data as CSV files alongside FHIR and C-CDA. The earlier version of that page lists MAGIC 5.67 Acute and Client/Server 5.67 Acute and shows a zip with a README, a schema file and a table of contents in NDJSON. MEDITECH warns that content varies by version, applications and configuration, so ask which configuration applies to you. If the request stalls, see our guide to information blocking and getting your EHR data out.

The certified FHIR API

MAGIC and Client/Server 5.67c appear in MEDITECH's real world testing results for the (g)(7), (g)(9) and (g)(10) application access criteria, so a standardized FHIR API exists on those releases. The API serves US Core FHIR profiles covering the USCDI data classes, which works for clinical summaries and is far narrower than the full chart.

Reports and document output

NPR reports on MAGIC and Client/Server (Iatric's NPR tips cover both) can still produce the printed documents your HIM team releases today: discharge summaries, operative notes, results, statements. We recommend rendering those to PDF/A while the system is up, because it preserves the legal medical record in a form a records clerk recognizes. Index each file by MRN, account and document date, record a SHA-256 hash at render time, and have HIM attest to the render process, so you can show later that nothing changed. HL7 v2 feeds are a weak source of history: an interface engine's message archive holds only what flowed through it, and historical queries depend on what the sending system supports.

When a module's data sits outside the DR and outside the export, the remaining route is to reverse engineer the report output or the data structures. That is the kind of work described in our guide to legacy integration through reverse engineering. Whether you may do it depends on your agreement with MEDITECH. This is not legal advice; review your license agreement and MSA with counsel, and see our overview of reverse engineering law.

Should you archive, integrate, or keep MAGIC read-only?

Our recommendation: keep MAGIC read-only only as a bridge, archive the data that is needed mainly for release of information and audits, and integrate only what clinicians still need inside their Expanse workflow. In practice that usually means an archive plus a link or document load into Expanse.

When you compare costs, put the archive quote next to the annual cost of keeping a second EHR alive for 10 to 20 years, including hardware refreshes and security reviews. Before signing with any archive vendor, ask four questions. What format do we get our data back in if we leave? Can the archive post A/R transactions or only display them? How are release-of-information requests logged? How is destruction handled when a record's retention period ends?

What does an owned MEDITECH archive look like?

A modest one is a SQL Server or PostgreSQL database loaded from the DR and the EHI population export, a document store for the PDF/A report output, and a small web viewer with search by MRN, account number and patient demographics. It has to answer a records request quickly and prove who looked at what.

Most of the engineering goes into audit, access and retention logic. Every view and export needs an audit log entry. Access needs role-based controls tied to your identity provider. Retention needs a rules table keyed by state and record type, so each record gets its own earliest destruction date, and a legal hold flag that overrides all of them. A FHIR API over the archive can feed a patient portal or a future system; getting old documents into the Expanse chart still means a MEDITECH-supported route such as a Scanning and Archiving load or a launch link, which you confirm with MEDITECH. Our HIPAA software development and EHR integration teams build this kind of system, and the EHR integration development guide covers the interface patterns in more depth.

On an earlier project we mapped an undocumented vendor API by enumerating it, probing it, validating every response against a schema and then wrapping it in a stable interface. The case study describes how that schema validation caught three vendor-side changes before they broke anything. Legacy MEDITECH extraction calls for the same discipline: reconcile counts per module and per SourceID, then sample charts by hand with HIM.

Checklist before you turn MAGIC off

1. Get MEDITECH's written statement of support, regulatory update and hosting terms for your MAGIC or Client/Server release, and check the OS, database and hardware deadlines underneath it.
2. Have HIM define the legal medical record and list which report types make it up.
3. Have counsel produce a retention schedule by state and record type, including minors, CAH rules, payer contracts and litigation holds.
4. Set written cutoffs for documentation, results and payment posting in MAGIC, then take a final incremental extract.
5. Run the DR inventory, then reconcile exact counts per module and SourceID against NPR counts from MAGIC.
6. Request a test EHI population export, confirm which configuration you get, and check it against the documented format.
7. Verify patient identity mapping across facilities and MRNs, including merged records.
8. Render legal medical record reports to PDF/A with hashes, and have HIM sample charts, amendments and attachments.
9. Test retrieval: fulfil a mock access request and an audit request from the archive alone, and restore the archive from backup.
10. Decide who works the remaining A/R, from which system, and until what balance.
11. Record HIM, compliance and IT sign-off on any known gaps, then schedule the shutdown date.
12. Document the decommissioning, including media sanitization, as part of your HIPAA records.

If you have not done it yet, run the DR inventory and compare it with the conversion scope. The gap between those two lists is the data you will be responsible for long after Expanse is live. If you want a second set of eyes on that gap, talk to us.