Migrate Appointment Reminders When Switching CRM

How to Migrate Appointment Reminders When Switching CRM (2026 Guide)

Switching clinic CRM systems is a significant operational undertaking, and appointment reminder migration is one of the highest-risk elements. Unlike client record migration (which has a clear success/failure outcome: did the data import correctly?), reminder migration failure is often silent — the system appears to be working, but reminders are firing at the wrong time, to the wrong contacts, with the wrong content, or not at all.

A clinic that migrates to a new CRM and experiences a 30% increase in no-show rates the following month is unlikely to immediately identify "reminder migration gap" as the cause. They'll suspect the new system is generally inferior to the old one, or blame the specific week's appointment mix. Identifying the true cause takes time — and in the meantime, no-show losses continue.

This guide covers how to migrate appointment reminders safely when switching CRM, with a structured validation approach that prevents the silent failure mode.

What Gets Lost in Reminder Migration

Understanding the specific failure modes helps design the migration to avoid them.

Trigger logic mismatch

The old CRM may trigger reminders based on "appointment type = new patient" while the new CRM uses a different field name or a different taxonomy entirely. If the appointment type mapping isn't correct, reminders fire for the wrong appointment types — or don't fire at all for appointment types that exist in the old CRM but don't have a direct equivalent in the new one.

Timing miscalculation

"48 hours before the appointment" sounds unambiguous, but it isn't. Does 48 hours mean 48 hours before the appointment start time, or 48 hours before midnight of the appointment day? Does the system account for time zones? Does it send at the exact calculated time or queue it for a defined send window (e.g., only send between 9am–7pm)? A timing miscalculation of a few hours is often invisible in aggregate data but produces individual cases where a patient receives a "tomorrow" reminder two days early, or a "day of appointment" reminder after the appointment time.

Quiet-hour and consent rule gaps

Most clinic CRMs have quiet-hour settings (no reminders sent between 9pm and 8am) and GDPR consent filtering (reminders only go to patients with active contact consent). If these settings aren't replicated in the new CRM, the first week of live operation may produce reminders sent at 3am, or reminders sent to contacts who previously opted out of SMS contact.

Template content errors

When reminder templates are re-entered in the new system, transcription errors are common: wrong appointment details variable names (the old system used {appointment_time}, the new system uses {appt_time}), incorrect clinic contact details, broken formatting on mobile devices, or outdated policy references.

Channel delivery differences

The old CRM may have been routing reminders through a SMS gateway account configured for UK numbers, while the new CRM uses a different SMS gateway with different sender ID behaviour. Patients may not recognise messages from the new sender, leading to lower confirmation rates even when delivery is technically successful.

The Migration Checklist

Step 1 — Document current reminder configuration

Before touching the new system, document everything about the current reminder setup:

• List of all active reminder schedules: Name, appointment type(s) it applies to, trigger timing (e.g., T-48h, T-24h, T-2h), channel (SMS/email), template content
• List of all inactive or paused reminders: These exist for a reason; they should be migrated to the new system in the same state
• Consent and quiet-hour settings: What GDPR consent is required? What are the quiet-hour windows?
• Opt-out contact list: The list of contacts who have opted out of reminders; this must be imported to the new system before any reminders go live
• Historical performance baseline: Reminder delivery rate, confirmation rate, and no-show rate over the past 90 days — by appointment type

This documentation is the reference against which the new system's configuration will be validated.

Step 2 — Map trigger logic to the new CRM's event model

Every reminder in the old system has a trigger — a condition that causes the reminder to fire. Map each trigger to the equivalent in the new CRM:

Old trigger	New trigger equivalent	Notes
Appointment type = "New Patient"	Appointment type = "Initial Consultation"	Verify field name in new CRM
Patient status = "Active"	Client tag = "Active"	Confirm equivalent filter
48h before appointment	T-48h offset from appointment start	Confirm time zone handling
Not yet confirmed	Confirmation status = "Pending"	New CRM may handle confirmation differently

Where no direct equivalent exists, decide how to handle the gap: create a new appointment type in the new CRM, use an approximate equivalent, or flag the reminder for manual management.

Step 3 — Recreate templates and validate content

Re-enter all reminder templates in the new system. After re-entry:

• Send a test message to your own number for every template, on every channel (SMS and email separately)
• Verify that variable fields populate correctly: appointment time, practitioner name, clinic contact details
• Verify formatting on mobile (SMS templates often look correct on desktop but break on mobile)
• Check quiet-hour compliance: send a test at an out-of-hours time to confirm it is queued, not sent

Step 4 — Shadow-run in parallel

Before switching the new system to live, run both systems simultaneously for a defined period (typically 1–2 weeks):

• The old CRM continues sending reminders as normal
• The new CRM is configured and generates reminder previews (scheduled but not sent)
• Compare: does the new system's schedule match the old system's schedule for the same appointments?

The shadow run reveals trigger logic mismatches (reminders that fire in the old system but not the new, or vice versa), timing discrepancies, and template content issues — without any patient impact.

Step 5 — Switch cohort-by-cohort

Rather than cutting over all appointment types simultaneously, switch one cohort at a time:

1. Start with a low-risk, high-volume appointment type (e.g., routine follow-ups)
2. Monitor delivery rate and confirmation rate for 1 week vs. the baseline for this appointment type
3. If stable, add the next appointment type
4. Reserve high-value new patient appointments for the final cohort, after the system has proven itself on routine appointments

This approach limits the blast radius of any reminder delivery problem to one appointment type at a time.

Step 6 — Monitor daily for 2 weeks post-cutover

After the new system is fully live:

• Daily: Reminder delivery success rate (were all scheduled reminders sent successfully?) and any delivery errors (bounced emails, SMS delivery failures)
• Daily: Confirmation rate by appointment type (compare against baseline)
• Weekly: No-show rate by appointment type (compare against baseline)

A sudden increase in no-shows after reminder migration is the signal that something failed in the migration. Identify the specific appointment type, trace back to the reminder configuration, and investigate.

Setting Up Reminders in Tregovia

Tregovia's Follow-up Sequences module (EUR 8/month) manages appointment reminders with full trigger configuration:

• Appointment type triggers: Reminders scoped to specific appointment types; import your current appointment type taxonomy before configuring
• Timing offsets: T-72h, T-48h, T-24h, T-2h, and custom intervals; time-zone aware
• Channel selection: SMS and email per reminder step
• Quiet-hour settings: Configurable send window (e.g., 9am–8pm only); messages scheduled outside the window are queued to the next opening
• Consent filtering: Marketing reminders filtered by active consent; transactional reminders (appointment logistics) processed under Art. 6(1)(b) without separate consent
• Opt-out management: SMS STOP and email unsubscribe handled automatically; opt-out list imported from previous system before go-live
• Confirmation tracking: Patient confirmation link in reminders; confirmation status visible in appointment record

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

Pricing: Base plan EUR 47/month + Follow-up Sequences EUR 8/month — flat rate, up to 2 staff accounts (extra users EUR 10/month per 5 seats). 14-day free trial to configure and test reminders.

FAQ

What should be validated first in the new reminder system?

Trigger timing accuracy for each appointment class. The most common migration failure is timing drift — reminders that should fire at T-48h are firing at T-47h or T-50h due to timezone handling differences or send-window queuing behaviour. Validate timing with test appointments: create a test appointment at a specific time, confirm when the system schedules the reminder, and verify it matches the expected T-48h window. Do this for every appointment type before going live.

Why avoid a full reminder cutover in one step?

It maximises the risk of a widespread silent failure. If every appointment type's reminders are switched simultaneously and a trigger logic error exists, every appointment type is affected simultaneously — and it takes a full week of no-show data to confirm there's a problem. Cohort-by-cohort switching limits the impact of any error to one appointment type, and the faster feedback loop (one appointment type at a time, monitored closely) makes errors visible within 1–2 days rather than 7–10.

How long should the shadow run last?

Until confirmation rates in the new system's preview match the old system's live confirmation rates for the same appointment cohort. For most clinics, 5–7 business days of shadow-run data is sufficient to confirm that the trigger logic and timing are correct. Extend the shadow run if you see discrepancies that haven't been explained (the new system's preview schedule shows different appointments being flagged than the old system's live schedule).

What KPI should be watched daily after cutover?

Reminder delivery success rate (percentage of scheduled reminders that were confirmed delivered to the recipient channel) and daily confirmation rate by appointment type. Both should be stable within ±5% of the pre-migration baseline within the first 3 days of live operation. If either metric drops significantly below baseline, pause the cutover for that appointment type and investigate the cause before continuing.

What happens to patients who were mid-sequence during cutover?

Patients who already received a T-48h reminder from the old system but haven't yet received their T-24h reminder at cutover time need to be handled carefully. Options: let the old system complete the T-24h reminder (keep the old system active for in-flight sequences), manually suppress the T-24h reminder in the new system for that specific cohort, or accept that some patients may receive a duplicate reminder. Duplicate reminders are annoying but not harmful; missing reminders increase no-show risk. Plan the cutover timing to minimise the number of appointments in mid-sequence.