Cloud EHR migrations usually go well clinically and badly from a compliance point of view, for one reason: the old system does not disappear when the new one goes live.
Before you move
Get the BAA signed before data moves, not after go live. If the vendor will not sign one, that is the end of the conversation.
Understand the shared responsibility. The vendor secures their platform. You remain responsible for who has accounts, what those accounts can reach, how people authenticate, and what happens on your end. Practices routinely assume the vendor compliance covers theirs. It does not.
Update your risk analysis before the move, not eighteen months later. The environment is changing, which is precisely when the document should change.
Ask where the data physically lives and whether any part of it, including support access, sits outside the United States.
During the move
Encrypt the transfer. Not a hard drive in a car, not an unprotected upload.
Do not use production patient data in a test environment unless it is protected exactly as production is. Test systems are where forgotten copies accumulate.
Keep a record of what moved and when. You will want it later.
After the move, which is where it goes wrong
Decide what happens to the old system. Practices leave the legacy server running just in case for years. It stops being patched, it stops being monitored, it still holds every record, and it is still your responsibility. Either bring it into scope properly or decommission it deliberately and document the destruction.
Remove access nobody needs. Migration projects hand out broad permissions to get the job done. Those permissions rarely get withdrawn.
Check the backups actually work in the new arrangement. A cloud EHR does not automatically mean you have a recoverable copy of your own data. Ask the specific question: if this vendor is unavailable for a week, what do we have.
Update every document that referenced the old system, including your risk analysis, your incident response plan and your BAA folder.