athenahealth Scheduling During a Medical Practice Acquisition: A Day-1 Continuity Checklist
An athenahealth scheduling checklist for a medical practice acquisition should protect the inherited schedule before ownership changes. Practice operations executives should inventory every provider-location-calendar relationship, baseline future appointments, assign each identity and workflow a transition disposition, test the target state, make Day-1 decisions by unit, and retain a controlled fallback until 30-day stabilization evidence supports closure.
What must the acquisition team protect before Day 1?
Protect the live schedule, not merely the new organizational chart. An acquisition inherits future appointments, provider templates, departments, locations, identities, external calendars, delegated access, and local booking rules. Reuse disciplines from a new-clinic scheduling go-live checklist, but do not treat an acquired clinic as a greenfield opening.
The minimum control unit is one provider, one department or location, one athenahealth identity, and each connected calendar. Unknown ownership or scope should block transition of that unit. Mapping evidence matters because athenahealth’s 2026 A2A migration proposal says future appointments are canceled in the source and recreated in the destination when the department, provider, and appointment type are mapped. Confirm whether that migration model applies to the transaction before relying on it.
How should the due-diligence workbook be structured?
Create one row for every provider-location-calendar pair and make every assumption visible. The workbook should connect inherited state to target state, evidence, ownership, disposition, fallback, and the final Day-1 decision.
| Workbook field | What to record |
|---|---|
| Rollout unit | Provider, department, location, appointment types, athenahealth context, and external calendars |
| Inherited state | Templates, future-appointment horizon, account owner, access paths, integration mappings, and local rules |
| Target state | Destination identity, calendar, booking authority, workflow, and effective date |
| Evidence and owner | Confirmed, observed, assumed, or missing evidence plus the accountable verifier |
| Disposition and fallback | Retain, transfer, migrate, reconnect, replace, or retire; include recovery steps and expiry |
| Decision | Proceed, proceed with containment, controlled coexistence, or delay |
Do not let a practice-level “complete” status conceal missing evidence for one provider or location. Filter the workbook by unit, owner, evidence status, disposition, and unresolved dependency.
How should inherited accounts and workflows be classified?
Give every identity, calendar, template, integration, and workflow exactly one transition disposition. Use the provider calendar offboarding checklist for departing providers and the provider identity-change cutover when domains, usernames, UPNs, mailboxes, or mappings will change.
| Disposition | Use it when | Required proof |
|---|---|---|
| Retain | The asset and ownership boundary remain valid | Current owner, access, mapping, and workflow are verified |
| Transfer | Ownership changes inside the same platform | The new owner accepts control and residual access is removed |
| Migrate | Data or accounts move to a destination organization or tenant | Scope, mappings, exceptions, and post-move state are reconciled |
| Reconnect | The calendar remains, but its identity or integration authorization changes | The existing calendar maps to the intended provider and passes tests |
| Replace | The inherited asset or workflow should not continue | The replacement is ready before the legacy path is disabled |
| Retire | The asset has no approved future purpose | Future obligations are handled and access is revoked without losing required continuity |
How do you protect future appointments?
Use a dated baseline, a single edit rule, duplicate-prevention controls, and post-transition reconciliation. If athenahealth migration services are involved, confirm the provider, department, and appointment-type mapping logic described in the current A2A migration proposal.
- Count future appointments by provider, department, location, appointment type, transaction status, and date horizon such as 0–7, 8–30, 31–90, and more than 90 days.
- Record the baseline timestamp and which system may create, reschedule, or cancel appointments during the transition window.
- Prevent parallel entry unless each change receives a unique owner and reconciliation record.
- Sample high-risk records across retained and departing providers, every location, short and long horizons, and created, rescheduled, and canceled states.
- Compare final counts and sampled records in the destination, investigate every unexplained variance, and keep the fallback until critical exceptions close.
A matching total is not enough: offsetting omissions and duplicates can preserve the count while leaving individual schedules wrong.
Who can edit schedules during the transition?
Assign one write authority for each transaction type and rollout unit. The buyer’s long-term centralized, local, or hybrid scheduling model can inform the target state, but the cutover also needs temporary source, destination, verification, and exception owners.
For coexistence, document which system may change future appointments, how changes reach the other system, who resolves conflicts, and when the arrangement expires. Do not allow seller staff, buyer staff, and an integration to make competing edits without a transaction-level control.
What must acceptance testing prove?
Testing must prove that representative schedule changes reach the correct final state and can recover from failure. Convert the inherited workflow into executable cases using a calendar-sync acceptance matrix, then capture evidence from athenahealth and every connected calendar.
- Create, reschedule, and cancel an appointment.
- Change one recurring occurrence, future occurrences, and an entire series where applicable.
- Add and remove temporary unavailability.
- Move a provider or appointment between locations.
- Revoke seller or departing-provider access.
- Break a mapping deliberately, contain the unit, reconnect it, and reconcile the missed interval.
Google Calendar’s event model distinguishes recurring series from individual instances, while Outlook’s current guidance provides occurrence, following-event, and series-level choices. The evidence card should state the chosen scope, expected state, actual state, tester, timestamp, defect, and recovery result.
How should the Day-1 decision gate work?
Make the decision for each provider-location-calendar unit, not once for the enterprise. A local mapping or access failure should not be hidden by an otherwise successful acquisition program.
| Outcome | When it applies | Required control |
|---|---|---|
| Proceed | Mappings, tests, trained owners, edit authority, and fallback are ready | Normal Day-1 monitoring |
| Proceed with containment | A bounded exception does not compromise critical schedule states | Named owner, scope, workaround, expiry, and retest |
| Controlled coexistence | The unit cannot cut over, but source operations can continue safely | One edit rule, daily reconciliation, and an exit decision date |
| Delay | Ownership, future appointments, access, mappings, testing, or fallback remain unsafe or unknown | Pause changes for the affected unit until the hard stop is cleared |
What should happen on Day 1?
Run Day 1 as a controlled verification window rather than a ceremonial handoff. Keep decision authority close to the evidence and protect unaffected units from local defects.
- Confirm the approved outcome for every rollout unit.
- Capture a final pre-change appointment baseline.
- Apply the edit freeze or coexistence rule.
- Run smoke tests for booking, rescheduling, cancellation, access, and connected calendars.
- Open one exception queue with severity, owner, containment, and next review time.
- Communicate unit-specific restrictions to schedulers and providers.
- Retain the fallback until the designated verifier signs off.
How should the first 30 days be measured?
Use a unit-level scorecard that measures schedule correctness, exception burden, and the remaining transition state. The daily schedule reconciliation playbook can supply the operating rhythm while acquisition leaders review trends at defined checkpoints.
| Measure | What it reveals |
|---|---|
| Unmatched future appointments | Potential omissions, incorrect scope, or incomplete transfer |
| Failed identity or calendar mappings | Units that cannot reliably reach the target state |
| Duplicate or stale entries | Competing edits, replay defects, or incomplete cancellation |
| Manual exceptions and closure time | The operational burden being carried outside the intended workflow |
| Repeat defects | Problems that were patched but not removed at the source |
| Units still in coexistence | Transition debt that still needs an exit decision |
Review the scorecard by provider and location, not only as an enterprise average. End stabilization only when trends are controlled, critical risks have owners, and routine operations accepts the remaining workload.
How should external calendar ownership be handled?
Resolve calendar ownership and access before seller-controlled accounts disappear. Current Google Workspace administrator guidance separates primary-calendar event transfer from secondary-calendar transfer and warns that secondary calendars and their events are deleted when their owner is deleted. Current Microsoft cross-tenant migration guidance says cross-tenant mailbox and calendar permissions are not supported, so mailbox content, delegates, and calendar rights need separate verification.
Inventory seller-managed tenants, personal accounts, shared calendars, secondary calendars, delegates, groups, applications, and departing providers. For vendor-specific fit, review the current Sporo athenahealth and Google Calendar product page, Sporo athenahealth and Outlook product page, Sporo Health scheduling-integration overview, and Sporo Health athenaConnect Marketplace listing. Treat these as vendor destinations and require written, configuration-specific confirmation before changing live workflows.
athenahealth scheduling checklist for a medical practice acquisition
- Define provider-location-calendar rollout units.
- Inventory inherited appointments, templates, identities, accounts, access, integrations, and owners.
- Record target state and evidence status for each unit.
- Assign retain, transfer, migrate, reconnect, replace, or retire.
- Baseline future appointments by risk-relevant dimensions.
- Set source, destination, verification, and exception authority.
- Document freeze, coexistence, duplicate-prevention, and fallback rules.
- Run representative acceptance and failure-recovery tests.
- Make one of four Day-1 decisions for every unit.
- Control Day-1 changes through one exception queue.
- Reconcile schedules and mappings throughout stabilization.
- Obtain operational acceptance before closing the transition.
Keep legal, tax, employment, records-retention, privacy, security, and clinical decisions with authorized specialists. The scheduling team should record them as dependencies rather than infer the answer.
What should leaders approve before close?
Approve only the units whose appointments, mappings, owners, tests, edit rules, and fallback are evidenced. The practical value of an athenahealth scheduling checklist for a medical practice acquisition is its ability to separate ready units from contained, coexisting, or delayed units without putting the entire inherited schedule at risk.
If connected calendars are part of the target state, use a limited vendor review and acceptance test rather than assuming one configuration fits every acquired provider or tenant.
Frequently asked questions
Should legal close and scheduling cutover happen on the same day?
No; legal close and scheduling cutover do not have to happen on the same day. Set cutover by provider-location readiness, and use controlled coexistence only when edit authority, reconciliation, and fallback are explicit.
What should block an acquired unit from cutover?
Unknown ownership or incomplete evidence should block the affected unit. Missing mappings, untested future appointments, unclear edit authority, untrained owners, or an unusable fallback are hard stops.
How do you preserve future appointments during an athenahealth practice acquisition?
Preserve future appointments with a dated baseline, controlled edits, duplicate prevention, and reconciliation. Compare counts and sampled records across providers, locations, appointment types, date horizons, and transaction states.
Can every inherited calendar use the same migration path?
No; inherited calendars need separate transition dispositions. Assign retain, transfer, migrate, reconnect, replace, or retire, and handle personal accounts, seller-managed tenants, shared calendars, and departing providers separately.
What should the Day-1 gate decide?
The gate should produce one of four outcomes for each rollout unit. Choose proceed, proceed with containment, controlled coexistence, or delay rather than hiding local failures inside one enterprise decision.
Which scenarios must acceptance testing cover?
Acceptance testing must cover every material schedule-state change and recovery path. Test creation, rescheduling, cancellation, recurring changes, unavailability, location changes, revocation, failed-mapping recovery, and final state in every connected system.
When can the acquisition scheduling work leave stabilization?
Stabilization can end only when trends, ownership, and coexistence exits are controlled. Require verified critical mappings, assigned repeat defects, acceptable exception workload, and routine-operations acceptance.
Sources
- athenahealth Data Migration Proposal and Overview
- Google Workspace: Cancel or transfer events or secondary calendars
- Google Calendar API Events reference
- Microsoft cross-tenant mailbox migration guidance
- Microsoft Outlook recurring-event change guidance
- Sporo athenahealth and Google Calendar product page
- Sporo athenahealth and Outlook product page
