Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.



This article is for customers users of Enterprise Message Handler for Jira, who are considering migrating from JEMH for Jira Server/Data Center to JEMH Cloud, also known as JEMHCa self-hosted deployment to the cloud-based offering of the app.

Migration assistance

There is currently no automated migration tool, primarily due to differences in the data structure used for storing configuration. You will need to do ground up configuration of JEMHC.

In progress

We have been adding some configuration section-exports in JEMH, (e.g. image blacklisting) but as yet have not added the import aspect to JEMHC.


Cloud capacity plans

Your JEMHC subscription drives an allocation (1st of every month) of a Capacity Plan based on the number of subscribed users; as your users increase, so does message volume and data capacity. If you consume the allocated plan, inbound mail and outbound notifications stop. No data is lost, it just remains queued.

New users are initially placed on a Starter Plan that is deliberately limited in capacity. This is to fail fast if a problem occurs (for example, a mail server delivers more mail than you expected).

Getting more message volume and data


Related to message data, JEMHC does support inline images in outbound notifications, and attachments, if you enable this, and make regular use, it can impact your data usage.

Mail servers

JEMHC cannot can’t use the built-in mailbox address provided by Atlassian, so you must use an external one, when . When doing so you may need to refer allow connections from the JEMHC public IP address to allow contact to your instance - this allows anyone on JEMHC to attempt this, for finer grained security, you would need to to your mail service. For finer grained access control, you could setup dedicated certificates that only your configuration has.


Microsoft office 365 (in:POP/IMAP/EWS, out: SMTP)


Gmail (in: POP/IMAP, out: SMTP)


New users start on a Starter Plan that is deliberately limited in capacity, this is to fail fast when problem scenarios occur (e.g. processing a POP mailbox where the ‘from now’ checkbox wasn’t set…)


What features are missing for cloud?

Scripting support

There is no Script Field Processor or Script Project Mapping Rules are not yet available. This is a big important feature to do for cloud and is something we hope to look at this yearoffer between Q4 '21 - Q1 '22.

What's different?

Data Storage

Inbound mail



As JEMHC is remote, the JEMHC app JEMHC periodically retrieves mail from your configured mail servers you configure over SSL transport for common protocols (POP/IMAP/EWS). By default, JEMHC currently retains stores a very limited rolling window of the last 100 latest mails in full (for mail under 10MB), encrypted (at rest) in our database, residing in the AWS Virginia data center. We do this as part of auditing to allow failed mails to be retried. This data is stored in the us-east-1 AWS region and is encrypted at-rest and in-transit. Users can opt out of this (requires support interaction email retention, but requires you to contact us to re-enable), doing this would impact our ability to support you with processing problems.JEMHC communicates with your Jira instance over SSL transport security.

Part of Auditing > Inbound Messages will retain recipient info, including the Project/Issue Key.

We have no access to your mail held here. You have the option to ‘flag’ mail for support, at which point we are able to see/download that mail and the processing report through our back office support tool, accessed by employees only.






For background, see How Jira events turn into emails and Manipulate Webhook data in a Template



Your Jira Cloud instance will send event data to JEMHC when changes are made to issues. JEMHC will only retain webhooks for processing where you have configured JEMHC to generate notifications for specific projects, in this way, we retain only the subset required for JEMHC to do what you have configured.


When JEMHC sends mail, we again retain the most recent 100 messages (and their HTML payload) in Auditing > Outbound Messages , where we track the project/issue source, the sent email subject (typically issue summary) as well as the recipients. A ‘Report’ for the actual sending of the mail is also stored, including recipients, filenames of attachments added etc.

About PII

JEMHC communicates with your Jira instance over SSL transport security.

Whilst JEMHC only retains the most recent 100 webhooks and inbound/outbound mails, we retain the last months worth of ‘audit’ records that something happened, meaning, webhooks, inbound mail and outbound mail. If a user choose to ‘be forgotten’ Atlassian will notify JEMHC and removals of related records will occur.


JEMHC data is currently stored in a highly available dedicated JEMHC database, which is not publicly accessible.

Data Residency



Background information: , non US realms:

JEMHC currently only has one ‘Realm’, located in the USA, we expect to look into JEMHC data residency later in the year..


JEMH Server/DC Profile exports are not currently compatible with JEMH Cloud.