Medical Practice Cloud Migration: Moving Your PMS Without Disruption

A practice running its patient-management system in the cloud can add a consulting room, take on a locum, open a second site or let a practice manager reconcile claims from home without buying another server or paying for after-hours remote access. That is the payoff, and it is real. The risk is that the switch is treated as a software purchase rather than a continuity project, and the clinic wakes up on Monday able to log in but unable to see the right patient history, submit a Medicare claim, match a pathology result to a file or print a referral.

This is a guide to running that move as a continuity project: what to map before you touch anything, what to ask the vendor that an Australian data region does not answer, how to design access so reception cannot see what reception should not, and what "the backup worked" actually has to mean in a clinical setting.

What success looks like on the first Monday

Write the acceptance criteria before you choose the platform. For most GP, specialist and allied health practices, cutover has succeeded only when every one of these is true with real patients in the room:

• A clinician opens a long-standing patient and sees the complete history, including scanned attachments, old letters and results, in chronological order.
• Medicare and DVA claims submit and reconcile, including bulk bill and patient claims, with the right provider numbers against the right locations.
• Pathology and radiology results arrive, match to the correct patient and can be actioned and filed.
• Scanning, printing and document generation work from each workstation, including the label printer and the scanner on the front desk.
• My Health Record access works for the staff who are permitted to use it, and only for them.
• The practice can restore a usable system after an outage, not just a folder of files.

Anything that fails one of those tests is a go-live blocker, not a post-cutover ticket.

Discovery and data mapping

Before migration, build a register of every system that touches patient data and every integration that depends on the current server. For a typical practice that list is longer than expected: the PMS and its database, clinical document templates, the scanning workflow and its watch folders, secure messaging, pathology downloads, the Medicare Online or PRODA claiming channel, SMS reminders, payment terminals, the online booking widget, Microsoft 365 mailboxes and shared inboxes, local file shares holding old correspondence, and any device that writes results back into the record.

For each one, record where the data lives today, who the supplier is, who in the practice owns it, how support is contacted and what happens to it after the move. That register is the backbone of the migration plan, and it is also the document you will need urgently on the worst day. Partnered Health became aware on 23 June 2026 that a malicious actor had accessed data from its systems and publicly disclosed the incident on 15 July 2026; for every affected clinic, the practical question in between was which patients and which data categories were in scope. Reports on the incident noted that patient records across 21 named clinics in five states and territories were affected, including private health insurance and Department of Veterans' Affairs card details. A practice that can answer "what did we hold, where, and who else held a copy" in an hour is in a very different position to one starting that work from scratch.

Duplicate patients and data cleansing

Every long-running practice has duplicates: the same person entered twice with a different spelling, a maiden name, a transposed date of birth, or a record created during a weekend fill-in. On-premises, duplicates are an annoyance. Migrated into a new platform with new matching rules, they become a clinical safety issue, because the notes split across two records and the clinician sees half a history.

Cleansing happens before the extract, in the live system, with clinical input on which record is authoritative. Allow for merge rules, a list of exceptions a human has to decide on, and a second pass after the pilot once the new system's matching behaviour is visible. Decide early what happens to inactive and deceased patients, how far back attachments are migrated, and whether the old system stays read-only for a retention period — and if it does, who patches and secures it, because a legacy server left running in a cupboard is still your legal responsibility.

The vendor questions an Australian region does not answer

"Hosted in Australia" is a starting point, not an answer. Ask the vendor, in writing, and keep the response with the contract:

• Where is the primary data stored, and where are backups and disaster-recovery copies stored?
• Who are the subprocessors, and where is support staffed from? Can an engineer in another country open a support session into your tenant, and is that logged?
• Can the vendor use practice data for analytics, product development or AI model training, and can that be switched off?
• What are the breach notification commitments and timeframes to you as the customer?
• What is the export format on exit, who performs the export, and what does it cost?
• What are the uptime commitments and service credits, and what is the published incident communications channel?
• What retention and deletion behaviour applies after you terminate?
• What logging is available to you, and for how long is it retained?

Residency, support access and export rights are three different questions, and a vendor can satisfy one while failing the others.

Identity and role design

The access model is the part most often skipped and most often regretted. In the OAIC's figures for January to June 2026, health service providers lodged 149 of 667 notifications, more than any other sector, including 62 human-error incidents against 72 malicious or criminal attacks. Mistakes are not a secondary category. They are roughly the same size as the attackers.

Design roles as part of the migration, not afterwards: clinical, reception, billing and administrator as separate permission sets, with nobody holding administrator rights for daily work. Build the joiner, mover and leaver process at the same time, including which systems are touched when a receptionist becomes a practice manager and what is disabled on the day someone finishes. Turn on multi-factor authentication across the identity platform and the PMS, and work through the shared-workstation and shared-inbox exceptions deliberately rather than leaving a permanent gap at the front desk. This design work — mapping clinical, reception and billing permissions onto real practice workflows for healthcare and allied health practices — is what separates a migration that reduces risk from one that simply moves it.

My Health Record sits inside this design as a governance workflow rather than another integration. The OAIC recorded 24 data breach notifications concerning the My Health Record system in 2025–26, up from 18 in 2024–25. Document who is authorised, review that list on a schedule, and have a defined process for investigating access that looks out of pattern.

Pilot, staged cutover and restore testing

Pilot with a small group of real users, real patients and real claims, not test data. Submit live Medicare and DVA claims, receive live results, print a real referral, scan a real document. Integration failures surface here or they surface in front of patients.

Stage the cutover by site, by day of the week or by clinician group where the platform allows it, and keep the old system available read-only through the first full billing cycle. Book hypercare — named support on site or immediately contactable — through the first week, and expect reduced appointment loads while staff learn new screens.

Restore testing deserves its own line item. A backup that returns files has not proven anything. The test is whether the practice can get back to a working clinical workflow: the right patient history visible, claims submittable, documents printable, within a recovery time the practice has actually agreed. Run that test before cutover, and run it again on a schedule afterwards.

What the licences cost, and what they do not cover

These figures were observed on 2 November 2026 and SaaS pricing moves, so confirm with the vendor before budgeting.

The licence is the smallest line. The three-year number also includes Microsoft 365 or equivalent identity and email licensing, endpoint management and detection, backup licensing with immutable storage, migration and cleansing, integration work for Medicare, DVA, pathology and payments, training and lost clinic time, and the ongoing access reviews, patching and restore tests. A cheap PMS plan that forces you to buy backup, email security and monitoring separately is frequently the dearer option, and a Microsoft 365 Business Premium licence may already carry controls you would otherwise purchase twice.

The first move, and where we come in

Start with the register. List every system that touches patient data, the supplier, the support contact, where the data sits and who in the practice owns it. Then book half an hour with your current PMS vendor and ask the export question: what format, who runs it, what it costs. The answers to those two exercises tell you more about migration difficulty than any demo will.

If you would rather have that done properly, Precision IT will run a discovery and data-mapping engagement across your practice systems and come back with a written scope: what moves, what stays local, the vendor and contract gaps worth pushing on, the identity and role design, a cutover sequence with go-live blockers named, and a three-year cost comparison against staying as you are. If the honest answer is that your current server has life left in it and the move should wait, we will say so. Request a consultation and we will tell you what the project involves for your practice before you commit to it.