Data migration is the process of transferring or moving data from one storage system to another. An “A2A” migration occurs when data is transferred from one athena environment (“tablespace”) to another athena tablespace to gain access to tools, functionality, and a more current user experience for the team. The A2A migration process requires careful attention to planning, validation, and support to ensure a successful go-live. Without the proper steps in place, an organization may experience go-live delays, patient care disruptions, or data issues in the new system. To help make the migration as smooth as possible, it is important to keep several key gotchas in mind.
Not All Data Transfers
- Do not assume an A2A migration will be simple just because data is moving from one athenaOne tablespace to another.
- Review athena’s data migration resources carefully to understand which document and data types do and do not transfer.
- Prepare teams for possible changes to daily routines, workflows, and system access in the destination tablespace.
- Address small issues early, because minor slip-ups can affect the migration timeline and create challenges before go-live.
- Confirm specific non-transferring items, such as submitted orders, vitals that do not exist in the destination tablespace, and cancelled appointments.
Scheduling and Third-Party Vendors
- Redirect scheduling and third-party vendor communications to the new tablespace before go-live.
- Turn off or update third-party vendor connections in the legacy athena instance so appointments, messages, and scheduling items do not continue flowing into the old tablespace.
- Review all forms of scheduling to prevent missed updates, duplicate work, and avoidable confusion.
- Account for contracts that may need to be renegotiated or re-signed because of the tablespace change.
- Contact all vendors proactively at least 8 weeks before migration.
- Begin interface vendor communication at least 14 weeks before migration.
Data QA & Testing
- Download error logs, review output files, and understand why a chart or data element may be missing.
- Identify where missing information should be located and who is responsible for resolving each issue.
- Create a clear error-handling process so unresolved data problems do not carry into go-live.
- Plan for at least one test migration run by athena.
- Set aside substantial time for the team to review patient charts and error logs.
- Schedule time with the athena integration project manager to review questions and clarify issues.
Timeline Underestimation
- Create a timeline with target dates and clear due dates to keep the migration on track for go-live.
- Consider the scale of the data and the amount of workflow or process adjustment required in the new tablespace.
- Identify the long poles in the tent early, especially the components that will take the most time.
- Act proactively on long-lead items to prevent overall delays.
- Use platform-provided timeline estimates as a starting point, but build in internal time for validation, troubleshooting, training, and workflow changes.
- Turn tasks around quickly to reduce last-minute pressure and avoid data access issues, unresolved errors, or go-live delays.
SSO, Access Challenges, and Permission Adjustments
- Review access needs before removing or changing permissions in the legacy tablespace.
- Avoid making users view-only too early if billing, clinical, or operational teams still need active permissions after migration begins.
- Confirm users can still complete key tasks such as signing orders, sending prescriptions, taking payments, closing encounters, and completing other required work.
- Plan for SSO limitations, because users may have difficulty moving between the legacy and new tablespaces.
- Consider using an incognito window and a second instance of the legacy tablespace when ongoing access is needed during migration.
- Define how user permissions should be adjusted in the legacy tablespace after migration begins so workflows are not disrupted.
Open Documents
- Close open documents in the legacy tablespace before migration because open documents will not transfer.
- Recognize that unfinished documents can delay migration when they remain unavailable for transfer.
- Pay close attention to orders in a SUBMITTED status and documents older than 2 years, since these do not appear in the Clinical Inbox.
- Communicate clear expectations to users about closing documents, completing open work, and checking for unfinished items before migration begins.
- Consider using athena’s script to close large numbers of documents when appropriate.
Reviewing Migration Guides
- Review migration guides and related resources provided by athenahealth during early migration calls.
- Use the guides to understand important steps, configuration needs, and go-live expectations.
- Avoid brushing off handouts or resource materials, because they may explain what must be configured in the new tablespace.
- Ask questions during meetings to clarify what may be different from the old tablespace.
- Treat the migration seriously at every step so the organization is better prepared for required changes.
Dedicated Migration Teams
- Assign a dedicated data migration team to monitor the full scope of the migration.
- Ensure the team understands why each migration step matters and how it affects go-live readiness.
- Have the team monitor progress, communicate with end users, and review missing or corrupted data.
- Prepare the team to support manual abstraction when needed.
- Use the dedicated team to keep decisions organized and resolve issues before they become larger go-live problems.
Final Thought
Data migration is not a simple task. It requires proactive planning, clear communication, realistic timelines, and the right support to ensure data is transferred properly. By paying attention to common gotchas such as access issues, vendor redirection, duplicate records, open documents, and migration guide requirements, organizations can reduce avoidable errors and better prepare their teams for a successful go-live.
Additional Resource: For more detailed migration guidance, refer to athenahealth’s data migration guide: Welcome to athena-to-athena (A2A) Data Migrations
