60.5 Importing and Exporting Profiles
60.5.1 Overview ¶
Profiles can be exported individually or as a bundle and imported on another installation. This is the classic method for transferring configurations between systems, taking over templates from other setups or copying individual profiles in a targeted way - without transferring the entire configuration via the backup function.
When importing, the program automatically detects the format: AEP 2 (V2), AEP 3 (V3) and AEP 4 (V4) are supported. For V2/V3, automatic migration to the current V4 format takes place - old configurations can therefore be deployed directly.
60.5.2 Export profile ¶
| Step |
Action |
| 1 |
In the main window, select one or more profiles in the profile list |
| 2 |
Profile -> Export Profiles… in the profile dropdown of the toolbar |
| 3 |
File dialog opens - choose location and file name |
| 4 |
Program writes a JSON file with the profile definitions |
The export file contains:
- Complete profile definition (name, filters, tasks, options)
- References to accounts, printers, database connections - but not the accounts/printers themselves (those are to be transferred separately via the backup mechanism)
In this way a profile can be transferred from one setup to another, provided the referenced resources (accounts, printers) either already exist on the target system or are created together during import.
60.5.3 Import profile ¶
| Step |
Action |
| 1 |
Profile -> Import Profiles… in the profile dropdown of the toolbar |
| 2 |
File dialog opens - select JSON file (or XML from AEP 2/3) |
| 3 |
Program analyzes the file and automatically detects the format (V2, V3 or V4) |
| 4 |
Resource selection dialog appears if the file contains additional resources (see 60.5.4) |
| 5 |
Profiles are inserted into the current configuration - existing profiles remain unchanged |
60.5.4 Resource selection during import ¶
If the import file contains additional resources - such as email accounts, printers, lookup tables or filter lists - the program asks per category whether these should be taken over:
| Area |
Behavior |
| Email accounts |
Checkbox per account: import or not. Already existing accounts (match by display name) are not overwritten |
| Printers |
Like accounts: checkbox per printer |
| Lookup tables |
As above |
| Global placeholders |
As above |
| Filter lists |
As above |
Already existing resources with an identical name are not overwritten - instead, the imported profiles are mapped to the existing resources. This way, critical data (passwords in accounts, printer definitions) is preserved while the profile logic is updated.
60.5.5 V2/V3 migration ¶
When importing an AEP 2 or AEP 3 file, automatic migration to the V4 format takes place:
- Filter structures are rebuilt (V3 had inline operators such as
<AND>/<OR> in filter values - V4 uses explicit filter sets)
- Task types are mapped (e.g. Outlook category -> Microsoft 365 category)
- Path notations are normalized (e.g.
\\Account\Folder -> INBOX/Folder)
- Obsolete tasks (e.g. proprietary Outlook COM-specific commands) are mapped to V4 equivalents - where no equivalent exists, the task is skipped and noted in the log
The migration is conservative: when in doubt, it skips rather than taking over incorrectly. After the import, you should check each migrated profile before activating it.
60.5.6 Use case ¶
Migration from AEP 3 to AEP 4
In AEP 3, export all profiles as XML. Import them in AEP 4 - the V3 XML is automatically detected and migrated to V4 JSON. Afterwards, check per profile whether all tasks were taken over sensibly.
60.5.7 Tips ¶
- After importing V2/V3 profiles, first check all profiles before activating them - the migration is good, but not perfect
- Passwords are transferred along with account imports. In the standard mode (encrypted in the profile file), they also work on a different user/PC. In the Windows Credential Manager mode, they must be re-entered on the target system, because the vault is bound to the Windows user