It is very gratifying that Atlassian has developed a cloud migration assistant for Jira and Confluence, which handles a large part of the migration. There are certain limitations, but in principle, processes can be migrated from Jira and pages from Confluence. Global configurations and settings are not migrated (as of January 2023).
However, the Cloud Migration Assistant is also a bit unpredictable in some cases. Certain things that were easily migrated during the test migration then generate error messages on the production day, or even content could be migrated without errors with earlier versions of the assistant; with current versions, a different migration procedure must be selected for comparable content 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 aren't available in the Atlassian Cloud. Alternatives must be sought here and migration of the data to the alternative plugin is rarely guaranteed. 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 scenario, the plugin data is also migrated with the Cloud Migration Assistant (e.g. as an attachment to Gliffy). In the second-best case, the plugin offers a migration path (e.g. with draw.io) and the data can also be transferred to the cloud with just a few clicks. If the data cannot be migrated as in the cases just mentioned, the only thing left is to manually reconfigure and enter the data (e.g. Scriptrunner), which can be very time-consuming depending on the plug-ins and their use.
When linkyard carries out the migration, we rely on customer support for the plugins - especially those that we don't use or don't know how to use them in a company - and need information about how the teams work and how to use the plugins.

And this brings us to what is actually the most central point for migration: cooperation between customers and the linkyard. The migration should always be regarded as a project in which both sides must reserve appropriate time for work. We don't know all instances and don't always see the special features right away. That is why we need explanations when, for example, a special plug-in is used in the company or how users are managed. With detailed tests by our customers, errors can also be discovered and eliminated before the productive migration, which means that the discovered errors can be avoided or quickly resolved during the productive migration. In this way, the targeted schedules can be met.

Of course, this is not a complete list of the stumbling blocks. For example, there are also Confluence macros that exist on server/data centers but do not exist in the cloud. Transferring users to the cloud also doesn't have to be trivial, especially if an AD connection is being used or one is to be reused in the cloud.
With every migration, we recommend that you first migrate, analyze, and review all content for testing purposes in order to then be optimally prepared for the productive migration.