Purpose of existing Migration Feedback API

Cloud Migrations
, ,
1

Hey

I am considering purpose of existing the migration feedback API, because it doesn’t work as I would expect.
According to documentantion, feedback api should be useful to send migration feedback to server side

Your cloud app can use the Feedback channel API to send feedback about the migration to the Jira or Confluence server product.

Furthermore, I have found response from Atlassian Staff on this community (click):

The feedback api is more about machine to machine communication. We’ve provided it if you ever need to provide communication between your cloud service and the on-premise server. This way you don’t need to create your own authentication and communication system.
During import, your cloud service can provide messages to the on-premise server. What that would entail is really up to what your needs might be. But it could be a request to send specific data in the transfer payloads or to pre-process the data in a specific way, say if there are version differences.

The API looks nice and it’s what we need. It would be really useful to send migration feedback (and display additional information for jira admin) if only api wouldn’t return HTTP 403 status everytime when migration’s status is set to ‘SUCCESS’, ‘INCOMPLETE’ or ‘FAILED’. To sum up, transfer is treat as Settled transfer and app can’t access to feedback data anymore.

We’d like to use the feedback api to provide more details about migration after end of transfer and display it in our separate view. But there’s one problem - feedback data can’t be fetched after migration. I see only one way to implement workaround which would try to fetch migration data periodically and save it in database for future usage. Maybe do you know another approach?

Cheers,
Kamil.

2

Hi @Kamil,

Thanks for your question. Yes, the feedback channel is designed to allow the cloud side of migration to communicate to server side to provide updates during the migration process. Because of rules around GDPR and data usage, after a transfer is settled we remove everything related to that transfer and close off the communication.

You can send a message with the progress update, but this only displays in the migration assistant.

So, I think you’re plan for saving the data in the database is probably going to be the best option if you’re going to use the migration platform for sending the update.

However, there’s nothing stopping you providing your own mechanism to fetch data from your servers to provide an update in your admin screen on server side - using a common value (e.g. transferId). This might provide a better option as you aren’t tied to the lifespan of the transfer.

Regards,
James.

3

Hi @jrichards

Thanks for your response and clarification. We wanted to use provided the feedback API to achieve our goal instead of creating additional mechanism (what would include auth etc.).

However, the api would be more useful only if server app would has some more time to fetch data, but I understand your approach to GDPR.

Cheers,
Kamil.

1 Like