Three that actually hurt us:
Migrate and refactor separately. When something breaks mid-migration you won't know which change caused it. Move first, clean up after.
Don't assume equivalent services behave the same. SQS and Pub/Sub are both "message queues." The delivery guarantees and retry behaviour are different enough to surprise you.
Write a rollback plan per service, not just for the database. When a Cloud Run service had issues post-deploy, we were improvising. A one-page runbook per service removes the stress.
Good rule of thumb: if a decision feels rushed mid-migration, it probably is.
Nahid Mahmud
Building open-source tools for developers
Love the practical examples. Are there any specific pitfalls or anti-patterns you'd warn beginners to avoid here?