...
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.
...
Regions
Your JEMHC subscription drives an allocation (1st of every month) of a Capacity Plan based on the number of subscribed (active) 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 evaluators are initially placed on a limited capacity Starter Plan. We do this to help you fail fast e.JEMHC supports Data residency in the following regions:
US (US West)
DE (Frankfurt)
See Atlassian docs on pinning your region.
Region Migration
We have no support for region migration at this time, its a do over, its on our roadmap.
Cloud capacity plans
Your JEMHC subscription drives an allocation (1st of every month) of a Capacity Plan based on the number of subscribed (active) 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 evaluators are initially placed on a limited capacity Starter Plan. We do this to help you fail fast e.g. where you start consuming all mail within a mailbox from long long ago.
...
JEMHC can’t use the built-in mailbox address provided by Atlassian, so you must use an external one. When doing so you may need allow connections from the JEMHC public IP address to to your mail service. For finer grained access control, you could setup dedicated certificates that only your configuration has.
What's different?
Data Storage
...
Allowlisting IP addressed used by JEMHC
Your mailhost may require JEMHC public IP addresses to be allowed. Your mailhost may have to be configured to be allowed to relay mail sending (symptoms of this are mail that doesn't deliver outside your domain).
EU and DE app data location IP addresses to allow
What's different?
Data Storage
As of MAR 2024 we support a default region of US as well as secondary DE region that new installation can pin their data to. As yet we do not have migration support from/to US deployment, potentially some areas can be manually exported (Profile JSON, templates etc) for reintroduction manually in a new DE deployment.
...
JEMHC has yet to implement a public rest API as we have for DC (Use JEMH Public Rest API to Export, Import and Update profiles ). Whilst tilted as for Profiles, we also exposed a way to deliver Mail directly over REST, which was utilised by some 3rd party email client app integrations. Those integrations will need rework once we have a public API in JEMHC. We are tracking this feature interally as
| Jira Legacy | ||||||
|---|---|---|---|---|---|---|
|
Migration Tasks
This section provides some advice for migrating from DC to Cloud.
A close replication of processing in DC can be achieved in Cloud but may not be identical (we do have a goal for functional equivalence, but there are different challenges in cloud. Customers should expect differences as part of this migration. We will happily take feedback through support for missing features, but cannot commit to implementing anything.
Documentation
We have structured App documentationfollowing the layout in the app, providing background on those features.
There is a Getting started guide, follow it to gain familiarity over round trip configuration requirements.
We have a large amount of How-to articles docs, we don’t expect you to dig for everything, ask us in support for guidance if keyword search doesn’t yield results!
Licensing
Customers and migrators should be aware of JEMHC App licensing , about How plan consumption is calculated and what happens when Capacity Plan Fully Consumed, and if required How to reduce MSG / Data volume.
Integration with Jira
JEMHC exists outside Jira, there is no ‘mail handler’ to pick as there was in DC. Configure JEMHC standalone via Apps from the main Jira toolbar.
Mailboxes
As JEMHC runs externally, customers must configure their own managed mailboxes in JEMHC (eg Gmail, o365, etc).
All mailbox connections must be (a) Authenticated (b) occur over SSL/TLS.
Common Questions
We must whitelist access to our mailhost, what are the public JEMHC IP Addresses
See EU and DE app data location IP addresses to allow .
Can customers user their nnn.atlassian.net mailbox in JEMHC
No. Atlassian do not support 3rd party use, and we don’t support Atlassian mailboxes for that reason, never mind Atlassian will frequently rotate the creds involved.
Can customers use their own private mail server with privately issued/managed SSL certifciate chain
Yes, see SSL Certificate Chains. Using a privately defined certificate chain ensures that only this tenant can connect to that service, as JVM connections will not be be possible without that.
Postfunctions
These are a functional redo at the workflow level, see Workflow Post Function Notifications
Adhoc notifications
These are a functional redo. Cloud apps have an app-permission that needs to be granted in the Project Permission scheme to Use Ad hoc notifications.
System Notifications
See JEMHC > Licensing > System Notifications, there you can setup recipients who will be notified of system availability and usage.
| Info |
|---|
Outbound SMTP Connection It is a requirement for you to create a default outbound SMTP connector, regardless of whether issue notifications are expected to be sent. Be assured, no issue notifications will occur unless explicitly configured within JEMHC. If no such outbound is defined, any mail ‘not processed’ cannot be signalled via a “Forward mail” defined in the Profiles and so, the inbound queue will permanently block until manually solved. |
Notifications
See Getting started, it takes you through a fully functional bi-directional configuration, and links you to what you will need to learn in order to make any template customisations, specifically:
how to convert Webhook Events into a Preview Context for edit-time preview of notification Template Sets.
JEMHC Email notification mappings are how we do issue level notifications. Notifications in cloud are simplified, the rich event model is not available, you get Issue Created, Updated and Deleted. On a Per-project basis you can currently pick a template that is used for the audience you have defined.
Templates are wrapped in Themes , you can create separate Templates on a per theme basis.
Notifications will be sent to the first matching JEMHC Notification Mapping, so even a final “ALL” projects Notification Mapping will not trigger (a) a second notification (b) enable use of different templates.
Profiles
JEMHC Profiles learned a lot from JEMH Profile evolution and has ‘less’ configuration at the top (common to all Project Mappings), with most configuration existing within Project Mappings.
For convenience, many settings defined on the Default Project Mappings are inherited by other Project Mappings, where the defaults can be overridden. Some care is needed to avoid incorrect values in other Project Mappings,
Profiles must contain at least one Project Mapping (the default), which will be used by default. You can create additional Project Mappings for other Projects, and add Rules for when to use them.
If ‘simple’ Domain Rules (addresses) were used in DC, the equivalence is close, if no fancy JQL scripting support is required, happy days, you will get through this quite quickly.
Scripting is a feature in cloud but is severely restricted for security, ability is limited to manipulation/decisions based on the content of the email, there is no external communication possible (so no Jira JQL or similar).
Most Field Processors formats from DC are supported in cloud so there is Directivessupport to drive issue creation/update.
In DC we have the Regexp Field Processor, part of which was the management of a remote system ID used to ingest remote system mail to create and continue to update the same issue, in Cloud, this feature exists stand alone, see Regexp foreign key association on https://thepluginpeople.atlassian.net/wiki/spaces/JEMHC/pages/72908873/Understand+how+Issue+association+works#Regexp-foreign-key-association .
As part of Project Mappings, like JEMH/DC, JEMHC has Custom Field Default feature (Set a dynamic custom field value ) to satisfy Jira workflow conditions and validators. As with scripting, the functionality of Custom Field Defaults is limited (either rendered via Velocity, based on email data) or scripted (again based on email data - during create, issue data available via webhook during update).
Body delimiters
A greatly used feature of JEMH/DC was the removal of replied-to email content. This feature exists in JEMHC within Project Mappings, see Handling signatures, replies and forwarded messages .
Auditing
When asking for support, get used to the inbound mail section of auditing, there is a ‘flag for support’ action, this sends us an email referring your instance, keeping your customer data in whatever deployment region is in use. We then use back office tools to pull that data down directly (securely) for support use. We do all this to minimise the spread of customer data where possible.
For the outlook users, please note that .MSG files are unusable by us, if you need to show MSG client side, use an annotated screenshot!
Audit records for Mail (in/out) are retained for a rolling 30d window. Mail less than 10MB of size is retained as part of this process, larger mail is not retained. If there is a failure to process such large mails, JEMHC cannot recover, your mailhost is the only possible backup.
Events are retained for an hour or so, to limit data exposure. If you need to get a Preview Context, regenerate the event and capture it.