Define required records before cutover
The clinician and data owner define the records required for continuity, including necessary medical history. Record what moves, what remains accessible in the archive, and who approves that decision.
Guides · clinic data migration
Clinic data migration starts with a sample and recovery plan
Clinic data migration starts with a sample and recovery plan: test patient identity, relationships, permissions and export, then agree access to essential records before cutover. No single timetable or zero-downtime guarantee fits every clinic.
Start with a source inventory and a sample reviewed by the clinician, reception and accounts. Approve fields, relationships and permissions, test export and restoration, then agree the cutover window and decision owner. Keep secure access to required records. Do not assume a subscription includes data cleaning or archive scanning; the written proposal defines migration scope.
Reviewed on
In operations
Four rules that show up on day one
Required records first
Owners define what care and follow-up require. Archiving is not a reason to withhold necessary medical history.
Sample before volume
Choose cases that expose identity, time and attachment differences, rather than many nearly identical records.
The source stays until stability
Destroying the book on day one cuts the rollback. Write the stop date down.
Export is a practical test
Test what the file includes and excludes. Data rights, retention and handover must also be clear in the contract.
Visible steps
Follow the sequence as written
Name the source: paper, a spreadsheet, or a legacy system
Each source needs an owner and a format. Do not mix the reception book with a vendor export in one file without columns.
Review patient identity and conflicts
Retain the source identifier. Do not merge records by name or phone alone: family members may share a number. An authorised reviewer must resolve uncertain matches and record the decision.
Upload a small sample and read it back
Use synthetic or appropriately de-identified records in an authorised environment. Include similar names, a changed appointment and an attachment, then test relationships and access. A failed sample blocks the bulk import.
Match roles on the sample
A reception account must not open what is the clinician’s. Record the attempt. Migration without roles copies the risk.
Write the cutover window and recovery plan
Define the final source write, how changes since the sample will move, and who can order recovery. Retain restricted access to required records under the retention policy, and test restoration before retiring the source.
Test export before accepting cutover
Open a sample export in an independent tool and check included fields, relationships and attachments. Record missing data and format limits before contracting, not when you need to leave the system.
Approve access to required medical history
Do not defer records the clinician needs to deliver care. Clinical and data owners approve what must move or remain securely accessible at the source; additional scanning requires written scope and pricing.
Why a migration guide separate from the buying list
The requirements checklist supports product selection. This guide covers cutover readiness: what must be evidenced, who approves it and when to recover. The linked migration-plan article provides field mapping and a sample reconciliation record. A feature list does not replace a sample review.
Who owns the migration file
Name a person in the clinic who owns the columns, not only a developer. Name and phone errors are fixed at the source, then the sample is rerun. Do not fix them in support as a silent exception after go-live. BarmajTek can help inside a written scope; we do not promise a silent move without review, or scanning every paper chart inside the subscription. If the source system stays and you only need a connector, that is the integration service, not a full migration.
What the ready subscription does not migrate
Scanning every paper chart, tying an external archive device, and merging two branches with conflicting history: those are projects. They are not hidden inside “turning Clinic Tek on”.
Invoicing during the move
Do not start JoFotara submission from the new system before taxpayer and tax fields are stable in the new record. A duplicate record may associate the invoice with the wrong person; a similar name alone does not establish that the submission will be rejected. Finish the patient sample, then match roles, then the invoice path, then till training on rejection. The portal account stays in the establishment’s name. A subscription does not create that account, and it does not replace the registration guide if the portal is not linked yet.
After the steps
Return to the requirements list if it is still open, then Clinic Tek prices and a product walkthrough. If the source system stays and you only need a connector, that is the integration service, not a full migration.
Questions
Do not assume so. Ask the provider to specify migration, cleaning, attachments, scanning and training in the written proposal.
Sequence the sample, then choose product or project
If the aim is to run Clinic Tek, book a walkthrough after the sample. If the source stays and you only need a connector, start an integration project.