How to Migrate Patient Data from Excel or Legacy Software
Switching to a new system often raises the same question: how can a clinic preserve its existing information without carrying old errors into the new database? Records may contain duplicate patients, incomplete profiles, inconsistent phone-number formats and fields that are structured differently in the new software.
For this reason, migration should be treated as a separate project with preparation, testing and validation, not as a simple file copy.
1. Decide which information is needed
List the data used in day-to-day operations, such as patient records, contact details, visit history and other essential entries. Separately identify outdated information or data that should not be transferred. When working with personal and medical information, take applicable processing and retention requirements into account.
2. Review the source database
Before importing, look for empty required fields, obvious duplicates, invalid date or phone formats and records that cannot be matched reliably. Keep a separate copy of the original database and document changes made during preparation.
Do not automatically merge similar records without checking them: two patients may share a name or phone number. Establish a manual review process for uncertain matches.
3. Map the fields between systems
Column names may differ, and one field in the old software may correspond to several fields in the new one. Agree on field mapping and formatting rules before migration. If the new system does not support some information, decide in advance whether it should be stored separately or excluded from the import.
4. Run a test import
Begin with a limited sample that includes both typical and complex records. Check names, contact details, dates and links between patients and their visit histories. Make sure special characters and text in the required languages are preserved correctly.
Then complete the migration and compare control figures: record counts before and after, missing fields, duplicates and errors. Matching row counts alone does not prove that the information has been transferred correctly.
5. Assign owners and prepare a rollback plan
Before migration begins, decide who will validate the result, how errors will be reported and what will happen if the import is unsuccessful. Keep the original database until the new system has been checked and confirmed to work as expected.
If your clinic plans to move from Excel or legacy software to ARSMA Care, discuss the source-data structure and post-migration checks in advance. Preparation helps reduce surprises after the clinic begins using the system every day.
Frequently asked questions
Can we migrate only part of the database?
That depends on the data structure and the capabilities of both systems. Identify the required records first, then confirm that they can be transferred safely.
Should we clean the database before migration?
It is useful to fix obvious errors and identify duplicates, but any record merges should be verified. Keep an original copy before making changes.
How can we confirm that migration was successful?
Use a test import, control counts and sample checks against the source records. Review the content and relationships between records, not just the total number of rows.