Oh, what, why is my app migration looking stuck for a long time ? Has something gone wrong on the server side?

App migrations looking stuck has been a leading pain point for customers performing server to cloud app migration using Cloud Migration Assistants. This often results in customers contacting both Atlassian and marketplace partners. One of the major reasons for app migration looking stuck is server side listener failures.

What’s a server side listener failure and how it can impact app migration ?

Server apps can face issues when executing server side listener method (onStartAppMigration ) and stop the execution with an uncaught exception. We have seen cases where this leads to app migrations looking stuck, as their cloud apps were not aware of server side listener failures and had not updated their transfer status to a settled state.

Yeah, there’s a good news, we are closing this gap, your cloud apps can know the occurrence of server side listener failures :

This feature will be released in few weeks (ETA : mid November 2022) and will be available for app migrations using CCMA v3.3.7 and JCMA v1.7.2 onwards.

To close this gap related to server side listener failure, App migration platform is introducing,

  • a new web hook event type ( listener-errored) to notify the cloud apps that the execution of your server side listener method (onStartAppMigration) has stopped with an exception
  • a new connect end point to fetch details about the server side failure

What must my cloud apps do on receiving listener-errored web hook event ?

– Update the status of your transfer which is essential for an acceptable customer app migration experience

It is essential for your cloud apps to update the status of app migration transfers periodically and finally set a meaningful settled status for all your transfers to avoid bad customer experiences due to stuck app migrations.

On receiving a listener-errored event,

  • your cloud app must update the transfer status to a meaningful settled status based on data received so far from your server app, if your server app stops performing migration operations for a given transfer on termination of onStartAppMigration
  • your cloud app must continue sending periodic status updates and finally update the transfer to a meaningful settled status, otherwise

– Use server side error details for improving your app migration reliability

Look for common issues why your server side listener is failing and fix (if it’s an issue that can be fixed in your server app) or report (if you believe it’s an issue related to App migration platform) such issues to improve the reliability of your app migration. As you might already know, Apps with higher migration success rates are promoted as reliable app for migration with Cloud Migration Assistants.

Link to the change log


I received 403 when calling the new endpoint to retrieve server error.
What I did:

  • update my listener to throw RuntimeException
  • my cloud app receives the listener-errored webhook
  • I use ACE to make a request back to cloud site with transferId in the webhook event => got 403
    Any tips on how to fix this?

Hi @KhaNguyen2

Thanks for reaching us. May I ask few questions to assist you in this case,

  1. Could you please share a transferId for which you faced this problem ?
  2. Do you use ACE to make any other App migration requests (for e.g., sending status from cloud app) ?
  3. Have you updated the status of errored transfer to a settled state ( SUCCESS, FAILED, INCOMPLETE) , before retrieving the server side error ?


  1. transferId: 0ce892a0-d87c-3ab5-82ec-9f7231330717
  2. Yes, I use ACE to call all other migration APIs
  3. I’m not sure since we also have our own error handling mechanism which might run before listener-errored event. So the new error API won’t work if the migration is set to a settled state?

I’m not sure since we also have our own error handling mechanism which might run before listener-errored event. So the new error API won’t work if the migration is set to a settled state?

Thanks heaps @KhaNguyen2 , this helps. We see that your cloud app tried to retrieve the error after settling the transfer based on our logs. As stated in our public docs, any request made using the transferId of a settled transfer will return a 4XX response code.

I’d recommend to update your cloud app to fetch the server side error before settling the transfer.