Finalizing the migration in Cloud

As previously stated there are certain configurations that the migration tool cannot move from the On-prem version of the application to the Cloud version.

These need to be finalized manually by the user, and this document aims to share the details on what needs to be done.

1. Authorizing OAuth2 Outgoing Mail Connections

If any of the migrated Outgoing Mail Connections uses the OAuth2 method for authentication, they should be authorized before usage.

• Before you authorize replace the redirect URI (The value is always the following: https://jeti.addon.meta-inf.hu/admin/oauth2/callback) at your email provider. For more details visit the documentation depending on your provider Google or Microsoft.

• To authorize, open the connection, then click on Authorization and follow the steps on your email provider site. You can find the connecting documentation here.

Authorizing an Outgoing Mail Connection

2. Authorizing OAuth2 Incoming Mail Connections

If any of the migrated Incoming Mail Connections uses the OAuth2 method for authentication, they should be authorized before usage.

• Before you authorize replace the redirect URI (The value is always the following: https://jeti.addon.meta-inf.hu/admin/oauth2/callback) at your email provider. For more details visit the documentation depending on your provider Google or Microsoft.

• To authorize, open the connection, then click on Authorization and follow the steps on your email provider site. You can find the connecting documentation here.

Authorizing an Incoming Mail Connection

3. Correcting the mail handler and adding actions

The migrated mail handlers do not contain any actions, due to severe differences in handler functions between the Email This Issue Cloud and On-premise instances. They are, therefore, created as a basic Cloud mail handler and they are using the migrated Incoming Mail Connections.

The Cloud mail handlers have four tabs:

• General handler settings

• Filters

• Find issue

• Rules and actions

The General handler settings are by default filled with values during the migration, all they need is a check from the administrator.

Filter Emails comparison

The below table shows the email filtering options both in On-premise and in Cloud versions:

On-premise option	Cloud option	Migration status
Bulk emails	Filter out bulk emails	FULL MIGRATION
Delivery status notification emails	Filter out delivery status notifications	FULL MIGRATION
Auto-submitted	Filter out auto-reply emails	FULL MIGRATION
Large emails	-	NOT AVAILABLE
Emails sent from this Jira system	Filter out emails sent from Jira	FULL MIGRATION
Emails sent from other Jira system	Filter out emails sent from Jira	FULL MIGRATION
Emails sent from unknown addresses	-	NOT AVAILABLE
Emails by recipient address	Accept email if any recipient equals...	NEEDS MANUAL SETUP
Emails by email attribute	-	NOT AVAILABLE
Emails by sender address	Sender email address filters	NEEDS MANUAL SETUP

Find Issues for Email

The below table shows the email filtering options both in On-premise and in Cloud versions

On-premise option	Cloud option	Migration status
Find issues by issues key appearing in the email subject	Default issue lookup (no option for enabling/disabling)	FULL MIGRATION
Find issues by references in email headers	Enable issue lookup by mail headers	FULL MIGRATION
Find issue by JQL	Enable issue lookup by JQL	JQL NEEDS TO BE EDITED MANUALLY

You are required to open each Mail Handler, and build up the complete Rules and actions secion from scratch manually. You can find the documentation on how to do so here.

4. Checking Email Templates

Depending on the complexity of the migrated templates they may not be working correctly. Please test each template and make the necessary corrections before using them.

1. Check out the differences between Cloud and on-premise velocity macros on the below document pages: - On-premise documentation - Cloud documentation

2. Check all Jira related identifiers: - Project key / ID - Issue type / ID - Field / custom field ID - User name / ID - Group name / ID - Roles

Editing templates on the Cloud

5. Check Advanced Email Configuration

This step is necessary if the migration contained any Advanced Email Configurations (It is a mix of the General Configuration and the Context on the On-prem platforms). For more information, please refer to the Advanced Email Configuration documentation.

• Check that the correct Outgoing Mail Connection is selected

• Correct the JQL filter if needed

• Make sure that your Reply/Forward template is correct (other template options may be found in the Manual Email Defaults)

• Check the order field

6. Check Recipients

Places where the Recipients are used:

• Manual Email Configuration recipients

• Notification Event recipients

• Recipient Restrictions

Recipients in the application may take up different input forms. These can be:

• Users

• Email addresses

• Roles

• Groups

• Custom fields

• Other special fields (eg. Reporter, Assignee, Watchers, etc)

If for some reason a value is not migrated by Jira, it cannot be resolved by Email This Issue. You have to check recipients in the settings and fix them manually after the migration process if needed.

Some examples for why the values would not be migrated:

• You are migrating selected projects and project-related users. If you refer to a Role as a recipient, but the project does not have any members in that role, then the role is not migrated and will be missing from the recipients.

• You are migrating selected projects and project-related groups. If you refer to a Group as a recipient, but the project does not have any members in that group, then the group is not migrated and will be missing from the recipients.

• If a custom field is not used on any issues, it is not migrated.

7. Manual Email Configuration

If you have a Manual Email Configuration migrated, correct the JQL filter if needed.

8. Check Email Notification details

If you have a Notification configured to use any of the following attachment settings:

• Added in the last operation or

• Attachments from attachment selector field

they have been migrated as None since these options are not availbe in the Cloud. If you have a different option selected, please update this part of the configuration.

Also correct the JQL filter if needed.

Notification Event mappings

The list of supported events are different on the On-Prem and on the Cloud versions of our product. Here you can see a comparison of supported events and how they are mapped:

Server	Cloud
Default Event	Not Supported
Issue Archived	Not Supported
Issue Restored	Not Supported
Request Created	Issue Created
Request Updated	Issue Updated
Request Resolved	Issue Resolved
Request Reopened	Issue Reopened
Customer Visible Status Changed	Not Supported

9. Disable data migration to your cloud instance in Email This Issue

When you are done with finalizing your settings on your Cloud instance, disable data migration in Email This Issue Administration - Migration options.

10. Workflow post-function

As the workflow postfunctions are not migrated at all please follow the manual migrations steps detailed at Migrating Post Functions if you have any on the server side.