Initial situation:

On the customer side, there is a desire to have the function of their existing on premises SEPPmail Secure E-Mail Gateway as booked service in the cloud.

 

Question:

What must be done for a migration from on premises SEPPmail Secure E-Mail Gateway to seppmail.cloud, or if applicable, to another SEPPmail cloud affiliate.

 

Procedure:

The basis for the migration to the seppmail.cloud is the SEPPMAIL.CLOUD Manual. This already includes parts of this description.

 

For migrating to another MSP, close cooperation and coordination between the parties is generally recommended as the basis for a successful migration.

 

The following points of the target system (cloud) should be known before starting the migration:

•Which firmware version of SEPPmail Secure E-Mail Gateway is in use => in the seppmail.cloud it is always the newest.
 

•(optional) "future description of the client" (see Customer)
 

•(optional) "future name of the client" (see Customer Name)
 

•Is for the GINA domain the "Virtual Hosting" (see Use virtual hosting)

odeactivated (Off for all domains)
 

oactivated (On for all domains)
=> this is the default setting in seppmail.cloud and also recommended for all other MSPs.
 

ofreely (Use domain settings)
 

•Of the "Virtual Hosting Setting" Dependent Hostname

oSetting "Off"
=> As a rule, the company name of the client is used here in lower case, for "My Company Corporation" thus for example "mycompany".
 

oSetting "On"
=> An FQDN that is usually composed by the prefix "securemail" and the company domain, for example "securemail.mycompany.tld".
 

•Necessary adjustments in the DNS for

othe email flow (MX entries)
 

othe availability of GINA.
If necessary, a further entry is required at this point (see "Virtual Hosting Setting" above).

 

The following points of the source system (on premises) should be known before starting the migration:

•FQDN under which the GINA interface had been reachable so far (Hostname) (see also warning in point "c)")
 

•Accessibility of the own email server for the MSP (see also Forwarding server)
If the own email server is also operated by the MSP, this point does not apply.
 

•Export file (see "j)")
To avoid sensitive data falling into the wrong hands, the export file and the associated password should be communicated on two different communication channels if possible.

 

In detail, proceed as follows:

 

Necessary action on the "on-premises SEPPmail Secure E-Mail Gateway"

a)If on the on-premises SEPPmail Secure E-Mail Gateway the client capability has not yet been activated (see Multitenancy), this must be initiated with an email to support@seppmail.ch with the subject "Migration preparation" and the request to activate the client capability
After activation of the client capability, the licence change may be done by clicking on View release notes in the section Update of the menu Administration.
 

b)First it must be ensured that the SEPPmail Secure E-Mail Gateway does not have a higher firmware version than the MSP. (see above). In general, care should be taken to ensure that the difference between the version levels is as small as possible. The current status can be checked under Home System Firmware version.
For a migration to seppmail.cloud, the firmware must be updated to the latest version (see Administration Update).

 

c)If only the [default] GINA domain has been used (see %OEM-WEBMAIL-GINA%> Domains Domains GINA name), a new GINA domain has to be created via Create new GINA domain. Before creation it must be ensured that the option Use virtual hosting is set to Use domain settings.
In the menu for creating new GINA domains (Create New GINA Domain), a name should be entered under Description that meets the MSP conventions (usually the name of the customer ) (see above).
Similar to the Virtual Hosting Settings offered by the MSP (see above), the setting Use virtual hosting must be made.
Depending on the Virtual Hosting Settings made (see above) the Hostname must now be entered.
To ensure that the settings of the [default] GINA domain are applied, the Master template "[default]" should be selected.
 

 

Otherwise continue with point "e)".

 

d)Apply the newly created GINA domain to the managed domains
-> Mail System Managed Domains click on the managed domain to be processed and, in the following menu, under Settings under GINA domain, select the newly created GINA. The process must be repeated for each managed domain.

i.If it is possible to adjust the forwarding server before the export (and if available, to remove the smarthost (see also Send ALL outgoing mails from this domain to the following SMTP server)), these options will not have to be adjusted on the MSP (see "Accessibility of the own email server for the MSP").
 

e)Activation of the client capability on the "on premises SEPPmail Secure E-Mail Gateway"
-> Customer Multiple Customers Enable
 

 

 

f)Set up a client on the SEPPmail Secure E-Mail Gateway whereby the naming should follow the conventions of the MSP (see above "future description..."and/or "future name of the client").
The optional Customer Admin E-Mail can later receive a daily automated client backup if desired.
-> Customer Multiple Customers Create new customer...
 

g)Open the properties for the newly created client
-> Customer Multiple Customers, in the table under Customer click on the customer.
 

h)Allocate all domains managed on the appliance
-> Assigned managed domains, selection of the Managed domains to be migrated via the drop-down menu under Domain name. Finish the allocation by clicking on Assign.
 

i)Allocate all GINA accounts
-> Assigned GINA accounts, Manage accounts in the next menu Assign other GINA accounts assign all GINA accounts shown in the first table by clicking on Assign all proposed accounts. If in the second table further GINA accounts are listed, these should also be assigned by clicking on Assign all unassigned accounts.
-> after completion of this action, return to the higher-level menu via Back

 

j)Export of new client(s)
--> Customer Multiple Customers, in the table in the row of the newly created customer under Action, click on the button for the export

i.In the next menu Export customer “<Name of Customer>" under Export password enter a "secure" passwort (the export contains the entire key material, i.e. also the sensitive private keys!!) and finish by clicking Export.
 

ii.The export file is saved under the name  "<Name of Customer>-<jjjjmmdd>.zip".

 
on the SEPPmail Secure E-Mail Gateway target system (Cloud)

The necessary actions and adjustments on the SEPPmail Secure E-Mail Gateway of the MSP strongly depend on the machine to be migrated, especially regarding the Architecture of the email flow. If necessary, special cases such as a Microsoft 365 connection (see also Integration Of MS Office365 While Maintaining ATP/EOP) must be considered.

Furthermore, it may have to be taken into account whether all of the SEPPmail Secure E-Mail Gateway active Additional Features to be migrated are also offered by the MSP.

Adjustments that may already have been made prior to export (see for example "d) i.") are omitted on the target system.

 

k)Import of Export File
-> Customer Multiple Customers Import Customer  
 

So far, the option Import Customer allows for the import of a complete client. This implies that the required actions mentioned above are carried out on the MSP system afterwards.

As it can be seen in the documentation of the submenu Import Customer, a more granular import is planned for the future.

 

l)Check the settings for the email flow

•Has the correct forwarding server been entered? (see "d) i." and is the "accessibility of the own email server for the MSP" given?
 

•Shows the MX record for the email domains to be migrated to the target system (see "Necessary adjustments in the DNS")

oHas this also taken into account any necessary adjustments to the TXT entries for SPF, DKIM, DMARC, and so on?

 

m)Have the "Necessary adjustments in the DNS" been made, so that the possibly new (see "e)")  - GINA domain(s) on the target server can be reached?

•If on the target system the entry of Additional hostnames is necessary (see warning from "c)")

oHas the correct entry been made in the GINA domain(s)?

 

oHas the corresponding DNS entry been changed to point to the target system?
 

oDoes the Additional hostnames also exist in the CN or the SAN of the certificate of the respective GINA domain?