It is very pleasing that Atlassian has developed a Cloud Migration Assistant for Jira and Confluence, which takes care of a large part of the migration. There are certain limitations, but basically the tasks from Jira and the pages from Confluence can be migrated. Global configurations and settings are not migrated (as of January 2023).
However, the Cloud Migration Assistant is also a bit unpredictable in parts. Certain things that were migrated without problems during the test migration, then generate error messages on the production day, or even content could be migrated without errors with previous versions of the assistant, with current versions must be selected for comparable content a different migration procedure and work with workarounds. At linkyard, we have a standardized migration procedure that we use for new migration projects, but we are prepared for unexpected deviations.

A second stumbling block can be the plugins used. There are plugins that are not available in the Atlassian Cloud. Here, alternatives must be sought and a migration of the data into the alternative plugin is guaranteed in the rarest cases. If the plugins also exist for the cloud, it must be checked how the data can be transferred to the cloud. In the best case, the plugin data is migrated along with the Cloud Migration Assistant (e.g. as an attachment with Gliffy). In the second best case, a migration path is offered by the plugin (e.g. with draw.io) and the data can also be transferred to the cloud with a few clicks. If the data cannot be migrated as in the cases just mentioned, the only option is to manually reconfigure and capture the data (e.g. Scriptrunner), which can be very time-consuming depending on the plugins and how they are used.
When linkyard performs the migration, we are dependent on the support of the customers for the plugins - especially those that we do not use or we do not know how they are used in a company - and we need information on how the teams work and use the plugins.

This brings us to the most important point of the migration: the cooperation between the customers and linkyard. The migration should always be seen as a project in which both sides must reserve time for the work. We do not know all the instances and do not always see the specifics right away. Therefore we depend on explanations, for example if a special plugin is used in the company or how the users are managed. Also, with extensive testing by our customers, errors can be discovered and eliminated before the productive migration, which means that during the productive migration the discovered errors can be avoided or quickly corrected. In this way, the targeted time schedules can be adhered to.

Of course, this is not a complete list of the stumbling blocks. For example, there are also Confluence macros that exist on the server/datacenter but do not exist in the cloud. The transfer of users to the cloud is also not necessarily trivial, especially if an AD connection is used or one is to be reused in the cloud.
For every migration, we recommend migrating, analyzing and checking the entire content first for test purposes in order to then be optimally prepared for the productive migration.