Software sunset transition guide

Your MRR software is being sunset. Here is the transition plan.

Confirm what is actually ending, protect the review cycles in front of you, preserve usable history, test the replacement, and treat security and exit planning as part of the migration—not as paperwork for later.

This guide is for independent consultant pharmacists, small consultant pharmacy practices, and larger teams replacing medication regimen review software because of a vendor sunset, end of support, hosted shutdown, acquisition, or an account-specific transition decision.

Personalized migration calendar

Turn the guide into your working transition plan.

Start with aggregate business information. We will create a private link, calculate the buying and cutover milestones, and let you refine every task.

Do not enter protected health information.No resident names, identifiers, clinical details, credentials, payment information, or patient-level records.

Your private link works immediately. Saving it to an account requires email verification.

Approachable summary

Do these five things before you compare products.

The first job is not choosing a replacement. It is preserving time, evidence, and continuity while the outgoing vendor can still answer questions.

  1. Verify the clock

    Get the exact end-of-sale, maintenance, support, security-update, hosting, and access dates in writing. A product announcement, account notice, and contract can describe different deadlines.

  2. Name one transition owner

    Give one person authority to maintain the decision log, deadlines, vendor questions, exception list, and sign-offs—even if the practice is small.

  3. Request an export now

    Do not wait for the final month. Obtain a representative export, field definitions, report archive, attachment inventory, and the outgoing vendor's conversion requirements while support is available.

  4. Protect the next review cycle

    Write down how reviews, urgent findings, facility reports, responses, and coverage will continue if either system is unavailable during the change.

  5. Measure the current burden

    Record current MRR volume, preparation, documentation, follow-up, reporting, and lookup time before comparing price or promised efficiency.

Put a number beside the disruption

Build a labor baseline before you set a software budget.

The calculator turns current MRR volume, data preparation, documentation, follow-up, reporting, and history lookup into monthly labor. It also models a possible workflow opportunity against the fastest connected answers in the tool.

Use the result as one budget input. It is not guaranteed savings, reimbursement, profit, or a complete return-on-investment calculation.

1

Value your current timeUse loaded labor cost, target consulting rate, or owner-time value.

2

Isolate repeat workSeparate clinical judgment from searching, re-keying, assembly, and status reconstruction.

3

Test the claimed changeAsk each finalist to prove which minutes disappear, move, or remain.

Calculate MRR time and labor value

Translate the notice

“Sunset” is not one date.

A system can stop being sold while support continues, lose maintenance while hosted access remains, or reach a hard shutdown. Plan against the most restrictive account-specific date—not the friendliest interpretation of an announcement.

Software lifecycle terms and the question each one leaves open
MilestoneWhat it usually meansWhat to ask
End of saleNew licenses or subscriptions stop being sold.Can existing customers add users, facilities, modules, or capacity?
End of maintenanceRoutine fixes or product improvements stop.Will defects, regulatory changes, and compatibility problems still be addressed?
End of security supportThe vendor no longer commits to security patches or vulnerability remediation.What is the last supported version and its final patch date?
End of technical supportHelp desk, troubleshooting, or implementation assistance ends or narrows.Which support channels, response targets, and transition services remain?
Service shutdownHosted access ends, which may also end access to data and reports.What remains available after shutdown, in what format, for how long, and at what cost?

The complete plan

Six phases from notice to safe retirement.

The calendar will vary, but the dependencies do not. Do not contract before requirements, cut over before reconciliation, or decommission before live validation.

  1. Immediately

    Stabilize the deadline and the work

    Turn a vague sunset notice into an owned plan with dates, escalation paths, and a continuity procedure.

    • Save the notice, contract, amendments, invoices, BAA, support terms, and current technical requirements.
    • Identify who controls the license, database, backups, interfaces, hosting account, encryption keys, and vendor relationship.
    • Record the last safe dates for contract notice, export requests, test conversion, go-live, rollback, and old-system access.
    Exit evidenceA one-page deadline register with an owner and source for every date.
  2. First week

    Inventory the workflow and every copy of the data

    Define what must continue, what must move, and what can remain in a controlled archive.

    • Map monthly, admission, interim, urgent, recommendation, response, reporting, correction, coverage, and history-lookup work.
    • Locate ePHI in the application, local databases, laptops, shared drives, report folders, backups, email, portals, and vendor systems.
    • Separate source data from MRR-created work so a medication feed or facility system is not mistaken for migrated history.
    Exit evidenceA data and workflow inventory that identifies system of record, owner, format, history depth, and disposition.
  3. Before shortlisting

    Build requirements from the current process

    Use the move to remove repeat work without deleting clinical or operational safeguards that still matter.

    • Mark each current step keep, improve, replace, or retire, and record why.
    • Define minimum requirements for data intake, review history, recommendations, outcomes, psychotropic work, reports, roles, export, and support.
    • Run the labor calculator and replace the default wage with loaded employment cost, target consulting rate, or owner-time value when appropriate.
    Exit evidenceA weighted requirements list and a current labor baseline—not a feature wish list.
  4. Before contracting

    Make each finalist prove the same scenario

    Compare observable workflow, migration, security, support, and exit evidence on equal terms.

    • Use synthetic resident data; do not place real PHI into an uncontracted demo environment.
    • Show an exception: a duplicate resident, missing field, changed recommendation, correction, covering pharmacist, and export request.
    • Score each requirement demonstrated, contractually scoped, unavailable, or still to confirm.
    Exit evidenceA completed acceptance script, security responsibility matrix, total-cost schedule, and sample exit export.
  5. Before go-live

    Convert, reconcile, and rehearse rollback

    Show that the new system is complete enough to operate and that exceptions are visible before the old path changes.

    • Reconcile record counts by facility and object type, then inspect representative records field by field.
    • Reproduce key reports, permissions, open-work lists, and historical searches in the replacement system.
    • Run a mock cutover, downtime process, backup restore or recovery evidence review, escalation test, and rollback decision meeting.
    Exit evidenceA signed reconciliation log, open-exception register, go/no-go criteria, and rehearsed rollback plan.
  6. After cutover

    Validate the live workflow and retire the old environment safely

    Confirm that real work remains available, accurate, and supportable before access or infrastructure is removed.

    • Review the first facility cycles, urgent route, corrections, covering-user access, reports, responses, and history lookups.
    • Resolve exceptions, revoke unnecessary accounts and integrations, update the asset inventory and risk analysis, and retain the decision record.
    • Follow applicable contracts and retention rules for return, archive, destruction, media disposal, and any continuing safeguards.
    Exit evidencePost-live acceptance, final disposition evidence, updated policies, and a named owner for the remaining archive.

Define the record before the export

Decide what must survive—and how you will know it did.

A folder of PDFs and a reusable structured export solve different problems. Ask for both when the continuing need requires both. The new system does not need every internal field simply because it exists, but every exclusion should be understood, owned, and accepted.

Residents and facilities

Stable identifiers, active/inactive status, assignments, locations, census context, and source-system identifiers.

Acceptance testCounts by facility match; duplicate, merged, discharged, and moved residents are explained.

Reviews and clinical history

Review type, service date, author, findings, notes, medication context, supporting dates, and completion state.

Acceptance testA sample across years, facilities, review types, and authors is readable and correctly related.

Recommendations and outcomes

Recipient, priority, category, original wording, response, rationale, status changes, follow-up, and timestamps.

Acceptance testOpen work remains open; closed work keeps its chronology; no status is silently remapped.

Reports, attachments, and released artifacts

Facility reports, prescriber communications, amendments, attachments, delivery evidence, file names, and versions.

Acceptance testRequired files open, link to the correct record, preserve readable dates, and distinguish originals from corrections.

Users, roles, and provenance

Authors, user status, facility access, role history, activity records, source labels, and imported-record markers.

Acceptance testAuthorship survives; former users are not reactivated; imported activity is not presented as newly created.

Configuration and dependencies

Templates, categories, report profiles, rules, integrations, import schedules, code mappings, and custom fields.

Acceptance testEvery dependency has an owner, replacement, exception, or documented retirement decision.

Put usability in the contract

“We will give you your data” is not a migration specification.

Define who can request it, objects and history included, formats, field definitions, relationships, deadline, delivery method, encryption, fees, corrections, transition assistance, post-termination access, and what the outgoing vendor retains or destroys. HHS explains that when a BAA requires PHI to be returned, the format should be reasonable under the agreement and preserve accessibility and usability.

HIPAA and security during an upgrade

Use the transition to reassess risk—not to make a blanket claim.

The current HIPAA Security Rule is technology neutral. A desktop product is not automatically deficient, a cloud product is not automatically compliant, and a BAA is not a security certificate. The useful question is whether the actual arrangement protects the confidentiality, integrity, and availability of ePHI.

Current-rule watch

HHS's Security Rule summary says the existing rule remains in effect while proposed cybersecurity modifications proceed through rulemaking. Do not treat proposed requirements as current law; check HHS again before final approval.

Re-run the risk analysis

A sunset, new vendor, new hosting model, changed data flow, or newly unsupported component changes the environment around ePHI. Identify where ePHI is created, received, maintained, and transmitted; then document threats, vulnerabilities, existing measures, likelihood, impact, and planned treatment.

Keep as evidenceDated analysis scope, asset/data-flow inventory, risk register, owners, decisions, and reassessment date.

Separate product age from supportable risk

HIPAA does not require a fashionable interface or a cloud deployment. It does require reasonable and appropriate safeguards. Lack of patches or vendor support can create material risk, but the existence of a newer product does not prove the old one is unsupported or noncompliant.

Keep as evidenceExact supported version and environment, patch history, vulnerability process, final support dates, and documented compensating controls.

Resolve business-associate responsibility before real data moves

Merely selling software does not automatically make a vendor a business associate. A vendor that hosts PHI or accesses it for implementation, conversion, or troubleshooting generally is one. Determine the relationship and put the required agreement in place before access.

Keep as evidenceSigned BAA where applicable, permitted-use scope, incident terms, subcontractor duties, and a clear responsibility matrix.

Test confidentiality, integrity, and availability through the move

Limit migration access, protect transfers, reconcile data, record exceptions, and keep an authorized route to needed information. These are practical controls derived from the Security Rule's goals; row counts and sample comparisons are not themselves named HIPAA requirements.

Keep as evidenceAccess list, secure-transfer method, reconciliation evidence, exception log, archive-access test, and incident escalation route.

Keep contingency planning live during cutover

The transition plan should identify critical work, backups, restoration, downtime operation, disaster recovery, emergency-mode operation, and testing. A backup file is not enough if nobody has shown that the needed records can be restored and used.

Keep as evidenceNamed recovery owner, backup scope, recent restore evidence, downtime instructions, communication tree, and rollback trigger.

Write the exit and retention terms precisely

Define usable export format, timing, fees, post-termination access, return or destruction, exceptions, and continuing protections. HIPAA does not create one universal medical-record retention period; confirm the state, setting, facility, contract, litigation-hold, and professional requirements that apply.

Keep as evidenceContract schedule, sample export, archive plan, retention authority, disposition decision, and deletion or return evidence where appropriate.

Outgoing and replacement vendors

Eight questions that belong in writing.

Ask both sides where responsibilities meet. A conversion can fail even when each vendor completes the narrow task it assumed the other vendor owned.

  1. Which date ends sales, maintenance, security fixes, technical support, hosting, and data access—and which document controls if the dates conflict?

  2. What exact versions, operating systems, databases, browsers, integrations, and deployment models remain supported until each date?

  3. Who will produce the export, what objects and history are included, what is excluded, which formats and data dictionaries are supplied, and what will it cost?

  4. How long will the outgoing vendor provide transition access and assistance, at what service level, and through which escalation path?

  5. How will record identity, authorship, timestamps, recommendation states, attachments, released reports, corrections, and audit information be preserved?

  6. Which party owns data cleanup, mapping, duplicate resolution, failed records, reconciliation, security configuration, training, and final acceptance?

  7. What happens if cutover fails: how long can the old workflow resume, how is data entered during the gap reconciled, and who has authority to roll back?

  8. After termination, what stays accessible, what is returned or destroyed, what evidence is supplied, and what safeguards continue for retained copies?

Now price the complete move

Compare subscription, transition cost, and modeled labor opportunity.

Include setup, conversion, cleanup, parallel work, training, interfaces, support, contract term, internal time, retained archive, and eventual exit. Then use the calculator baseline to test—not assume—the value case.

Build the labor baseline

Printable acceptance worksheet

Reconcile counts, then inspect the story inside the records.

Print / save as PDF

Counts find missing groups; samples find broken meaning. Complete both. Add rows for custom data, interfaces, reports, or legal holds, and attach the exception log rather than forcing a false pass.

MRR software migration reconciliation and sign-off worksheet
Record or configuration groupExpected / outgoingConverted / archivedSample and exception resultOwner / sign-off
Facilities and active resident counts□ Pass   □ Exception
Inactive, discharged, moved, duplicate, and merged residents□ Pass   □ Exception
Review counts by type, facility, month, and author□ Pass   □ Exception
Open, accepted, declined, deferred, and closed recommendations□ Pass   □ Exception
Psychotropic and GDR-related history used in later review□ Pass   □ Exception
Released reports, corrections, attachments, and file readability□ Pass   □ Exception
Authorship, timestamps, source identifiers, and imported-record labels□ Pass   □ Exception
User roles, facility access, integrations, templates, and report profiles□ Pass   □ Exception
Clinical ownerName / date
Operational ownerName / date
Privacy / security ownerName / date
Final go / no-goDecision / date

Practical-control boundary: This worksheet applies integrity and availability principles to migration testing. HIPAA does not prescribe these exact rows, counts, sampling methods, or sign-off roles.

Frequently asked questions

Clear answers to the questions behind the search.

What does it mean when a software vendor sunsets a product?

There is no universal operational definition. A notice may refer to end of sale, maintenance, security updates, technical support, hosted access, or all of them on different dates. Ask the vendor to identify each milestone, the versions affected, your contractual rights, and what remains available afterward.

What should a consultant pharmacy practice do first after an end-of-life notice?

Verify the dates in writing, name an owner, preserve the notice and contracts, request a representative export, inventory the MRR workflow and data, and write a continuity plan for the next review cycles. Do those things before product demonstrations consume the schedule.

Can a healthcare organization keep using unsupported software under HIPAA?

There is no automatic yes or no based only on the word unsupported. The regulated entity must perform and document a fact-specific risk analysis and reduce risks to a reasonable and appropriate level. OCR warns that unsupported legacy systems can be particularly vulnerable and recommends planning an ultimate retirement when possible. Obtain qualified advice for the actual environment.

Does moving to cloud software make the practice HIPAA compliant?

No. The Security Rule is technology neutral. A cloud vendor may be a business associate, a BAA may be required, and both parties still have responsibilities. Product selection alone does not establish compliance.

What MRR data should be tested during migration?

At minimum, inventory resident and facility identity, reviews, recommendations, responses, status history, psychotropic or GDR context used later, reports, attachments, corrections, authorship, timestamps, source identifiers, roles, templates, and integration configuration. The actual required record depends on the practice, setting, contracts, and applicable law.

How can a practice estimate what replacement software may be worth?

Measure current review volume and the time spent preparing data, finding information, documenting, following up, reporting, and retrieving history. The site's calculator models a labor baseline and possible workflow opportunity. Treat that as one budget input, not guaranteed savings or a complete ROI calculation.

Is RxPertise being discontinued or sunset?

We found no official public RxPertise sunset date as of July 16, 2026. SoftWriters' live help center offers current-software downloads, update announcements, ticketing, tutorials, and support-renewal status checks. Existing users should still obtain their edition, maintenance date, supported environment, security-update path, export scope, and roadmap directly from SoftWriters in writing.

Primary-source register

What supports this guide.

Federal sources establish the current baseline. The ONC switching guide is EHR-specific and is used here as adaptable health-IT contracting guidance, not as a rule for MRR software. Vendor pages support only the dated RxPertise status note.

  1. Assistant Secretary for Technology Policy / Office of the National Coordinator for Health IT

    Transition Issues: Switching EHRs

    EHR-specific contracting guidance that is useful by analogy for support periods, transition services, data formats, conversion, fees, and access to the outgoing system. It is not an MRR-specific mandate.

    Accessed July 16, 2026
  2. U.S. Department of Health and Human Services, Office for Civil Rights

    Summary of the HIPAA Security Rule

    Explains the currently effective Security Rule, including risk analysis, safeguards, contingency planning, evaluation, business-associate arrangements, and documentation.

    Accessed July 16, 2026
  3. U.S. Department of Health and Human Services, Office for Civil Rights

    Guidance on Risk Analysis

    Describes the required scope and elements of a risk analysis for electronic protected health information.

    Accessed July 16, 2026
  4. U.S. Department of Health and Human Services, Office for Civil Rights

    Securing Your Legacy System

    Discusses unsupported legacy systems, risk analysis, compensating safeguards, contingency planning, and retirement planning.

    Accessed July 16, 2026
  5. U.S. Department of Health and Human Services, Office for Civil Rights

    System Hardening and Protecting Electronic Protected Health Information

    Explains that risk analysis includes unpatched and obsolete software and discusses ongoing vulnerability management and compensating controls.

    Accessed July 16, 2026
  6. U.S. Department of Health and Human Services, Office for Civil Rights

    Is a software vendor a business associate of a covered entity?

    Explains that a software vendor is generally a business associate when it hosts or needs access to PHI, while merely selling software does not itself create that relationship.

    Accessed July 16, 2026
  7. U.S. Department of Health and Human Services, Office for Civil Rights

    Guidance on HIPAA & Cloud Computing

    Explains cloud business-associate duties, shared security responsibility, BAAs, risk analysis, service levels, encryption limits, backup and recovery, and data return after termination.

    Accessed July 16, 2026
  8. U.S. Department of Health and Human Services, Office for Civil Rights

    Business Associate Contracts

    Summarizes required contract subjects and sample provisions, including safeguards, incident reporting, subcontractors, and return or destruction of PHI at termination.

    Accessed July 16, 2026
  9. U.S. Department of Health and Human Services, Office for Civil Rights

    May a business associate block or terminate access to PHI?

    Explains availability responsibilities and, when the agreement requires return, returning PHI in a reasonable format that preserves accessibility and usability.

    Accessed July 16, 2026
  10. U.S. Department of Health and Human Services, Office for Civil Rights

    Fact Sheet: Ransomware and HIPAA

    Discusses backup, restoration testing, disaster recovery, emergency operations, criticality analysis, and contingency-plan testing.

    Accessed July 16, 2026
  11. U.S. Department of Health and Human Services, Office for Civil Rights

    Does HIPAA require medical records to be kept for any period?

    Explains that the HIPAA Privacy Rule does not set a medical-record retention period; state law generally does. Other HIPAA documentation requirements still apply.

    Accessed July 16, 2026
  12. Electronic Code of Federal Regulations

    42 CFR § 483.70 — Administration, including medical records

    Federal nursing-facility requirements for complete, accurate, accessible, organized, confidential, and safeguarded medical records.

    Accessed July 16, 2026
  13. SoftWriters

    RxPertise Help Center

    The live portal offers current-software downloads, update announcements, feature tutorials, ticketing, and Product ID maintenance-status checks for current users.

    Accessed July 16, 2026
  14. Managed Health Care Associates

    Clinical Consulting Software

    A current public RxPertise description that discusses existing and prospective users and continued enhancements; it does not publish a retirement date.

    Accessed July 16, 2026
  15. SoftWriters

    RxPertise Technical Requirements

    Account-access support material for the installed application's technical environment. Buyers should obtain the current version-specific requirements and responsibility split directly from SoftWriters.

    Accessed July 16, 2026

Have a newer vendor notice or a correction? Send the public source and the exact statement that should change to consultantpharmacistsoftware@tinycall.com. We date material evidence reviews.