Migrate Client Portal Data to New Practice Software

Migrate Client Portal Data to New Practice Software (2026 Guide)

Migrating client portal data when switching practice software is one of the more underestimated parts of a platform transition. Practices focus on clinical records and billing history — but client portal data has its own migration challenges: clients have saved payment methods, document signing history, booking preferences, and active login credentials that don't transfer when you change platforms.

This guide covers what client portal data exists, what migrates cleanly and what doesn't, how to handle the client communication side of the transition, and the GDPR obligations that apply to the data transfer.

What Counts as Client Portal Data

Client portal data is distinct from the practice's internal records. It is the data that clients themselves create, access, and manage through the portal:

Account and login credentials

Every portal client has login credentials tied to the old platform — an email address and password (or social login). These do not transfer. The new platform's portal requires clients to register new accounts or reset passwords. This is the most visible part of the migration for clients.

What does transfer: The client's email address (from the practice's client record) is the basis for sending the new portal invitation. Everything else is new.

Uploaded documents and consents

If clients uploaded documents through the portal (identification, referral letters, signed consent forms), these files live in the old platform's storage. They may or may not be exportable in bulk — most platforms allow individual file download but not automated bulk export of all client-uploaded files.

Transfer approach: Export and download client-uploaded files from the old platform. Attach them to the corresponding client record in the new system as historical documents. Clients will not need to re-upload documents that the practice holds in their record — but any documents they uploaded as drafts (not yet reviewed or signed) may need to be re-submitted.

Signed consent forms and e-signature records

Signed consent forms have legal standing — the signature record (who signed, what they signed, when, from what IP address) is part of the audit trail. This audit trail cannot be transferred to a new platform's e-signature module, because the cryptographic chain of custody is tied to the original platform.

Transfer approach: Export signed consent forms as PDF files (which embed the signature and audit information). Store the PDFs in the new platform as historical documents attached to the client record. Future consent forms are collected on the new platform and generate a new audit trail from the migration date forward.

Saved payment methods

Saved payment methods (credit cards, SEPA mandates) stored in the old platform cannot be transferred to a new platform. Payment card data is held by the payment processor (Stripe, Adyen, or similar), not by the practice software. When a client has a saved card in Platform A via Stripe, and the practice moves to Platform B via a different Stripe account, the saved card is not accessible to Platform B's Stripe account.

Transfer approach: Notify clients that they will need to re-enter payment details in the new portal. For clients on recurring memberships or payment plans, this is operationally critical — they must update their payment method before the next billing date, or the charge will fail.

Appointment booking history (client view)

Clients can typically view their past appointments in the portal. This history is derived from the practice's appointment records, which do migrate. If the appointment records import correctly into the new system, the client's appointment history is available in the new portal from day one.

Secure messages and communication history

Message threads between clients and the practice via the portal's secure messaging feature are specific to the old platform. These do not transfer. Export relevant message content as PDFs or text files and attach to the client record if there is anything clinically or legally significant.

The Migration Sequence

Phase 1 — Pre-migration data audit (2 weeks before cutover)

• Identify all clients with active portal accounts in the old system
• Identify clients on recurring billing who have saved payment methods — these require priority communication
• Identify all signed consent forms — plan the PDF export and archive process
• Identify any open message threads with clinically significant content — archive before migration

Phase 2 — Data export from old platform

• Export all client records (CSV)
• Export appointment history (CSV)
• Export billing history (CSV)
• Download all client-uploaded documents and signed consent form PDFs
• Export any message content that needs to be retained

Most platforms export this data under GDPR data portability rights (Article 20) or standard account export features. Check the old platform's export documentation to understand the format and completeness of available exports.

Phase 3 — Import into new platform

• Import client records
• Import appointment history
• Import billing history
• Attach exported documents and signed consent PDFs to corresponding client records
• Verify a sample of records to confirm the import is correct

Phase 4 — Portal account transition (client-facing)

Send a migration notification to all clients with active portal accounts:

Email template (adapt for your practice):

Dear [Client Name],

We are moving to a new client portal to improve your experience. Your clinical records and appointment history are fully preserved.

To access the new portal, please use this link to create your account: [link]

If you have a saved payment method: Please update your payment details in the new portal within the next 14 days to avoid any interruption to recurring billing.

If you have any questions, contact us at [contact details].

Send this 7–10 days before the new portal goes live, with a reminder 2 days before.

Phase 5 — Parallel access period (30 days)

Keep the old portal accessible (read-only if possible) for 30 days after the new portal is live. Some clients will not see the migration notification immediately and will try to log into the old portal. Having it accessible (even read-only) prevents support calls from confused clients and gives stragglers time to complete their account setup on the new platform.

GDPR Obligations During the Migration

Data transfer between platforms

You are the data controller. When you transfer client data from Platform A (the old system) to Platform B (the new system), you are acting as data controller directing data processors. The transfer is covered by your data controller authority — you don't need client consent to move data between your own processing systems.

However, both Platform A and Platform B must be operating under reviewed terms — processor terms with both processors. Confirm that the new platform's processor terms are in place before data is imported.

Data residency during transfer

If the old platform is US-hosted and the new platform is EU-hosted, the data transfer from old to new is a one-time cross-border transfer covered by SCCs (Standard Contractual Clauses) that the old platform operates under. After the transfer, the data is EU-resident and the old platform's SCCs no longer apply to your data.

Deletion from the old platform

After migration is complete and verified, request that the old platform delete your account data from their servers. As data controller, you have the right to instruct processors to delete data once the processing relationship ends. Request written confirmation of deletion and retain it in your compliance records.

Client privacy notice update

Update your privacy notice to reflect the new data processor (the new platform) and the new data residency (if it has changed from US to EU). The privacy notice must accurately describe how client data is processed. An outdated privacy notice that still references the old platform is a GDPR compliance gap.

Setting Up in Tregovia

Tregovia provides the tools to receive migrated client portal data:

Client record import: CSV import for client records, appointment history, and billing history. Imported records are immediately accessible in the client portal.

Document storage: Upload historical documents (signed consent PDFs, client-uploaded files from the old platform) directly to client records. Available in the portal from day one.

Client portal invitations: Bulk send portal invitation emails to imported client records. Clients click the link, set a password, and access their record immediately.

Recurring billing setup: After clients update payment methods in the new portal, recurring membership billing resumes from the new platform. Stripe Connect integration for card payments.

Privacy controls: Configure access roles, consent records, exports, deletion requests, and retention rules before publishing this workflow.

Pricing: Base plan EUR 47/month flat rate — up to 2 staff, up to 100 clients (extra users EUR 10/month per 5 seats), portal included. 14-day free trial.

FAQ

Do clients need to re-enter their clinical history when migrating to a new portal?

No. Clinical history (records, appointments, billing) is held in the practice's internal records, not in the client's portal account. When the practice migrates that data to the new platform, it appears in the new portal under the client's account once they register. Clients register a new login but their history is already there.

What happens to recurring membership clients during the migration?

Recurring billing charges will fail if the client's saved payment method is not transferred to the new platform. Notify recurring clients specifically — not just in the general migration communication — with a clear instruction to update their payment method and a deadline (before the next billing date). For high-value recurring clients, a personal follow-up call from the front desk is appropriate to ensure continuity.

How should a practice handle clients who don't respond to the migration notification?

After the migration notification and reminder, send a final prompt two weeks after the new portal goes live. For clients who still haven't registered, the practice can register them manually (using the client's email address) and send a password reset link. For clients who have had no contact in 12+ months, assess whether they are active clients before investing further effort in portal migration — they may simply no longer be patients of the practice.

Is it necessary to retain the old portal for 30 days after migration?

It is operationally advisable, not legally required. The 30-day parallel access period is a practical buffer that reduces client support calls and catches cases where the migration notification didn't reach the client. If the old platform charges by the day or has minimum notice periods, factor this into the migration timeline. Some practices manage without the parallel period by having a robust client communication campaign and responsive front-desk support during the first two weeks of the new portal's operation.

What GDPR right applies if a client requests their data during the migration period?

Subject Access Requests (SARs) during a migration period must be fulfilled from wherever the data currently resides. If the migration is in progress, the response may need to draw from both systems. Document the migration timeline so you can demonstrate which system held the data at the time of the request. Migrating data does not suspend SAR obligations — a SAR received during migration must still be fulfilled within 30 days.