LiteTMS Data Portability Register
1. Starting a transfer
An account administrator submits a request in the System or to support@litetms.eu and states whether data should be transferred to another provider, moved to the Customer's own infrastructure, or erased without transfer. We may verify the requester's identity and authority. The time limits, assistance, retrieval period, and erasure rules are set out in §15 of the Terms.
Standard report exports are available in the System. A complete migration package, documentation and — where available for a feature — an export interface are prepared on request without a switching charge.
An account administrator can also request a data export in Settings (Data export) covering employees, vehicles, trailers and contractors, with their stored files if chosen. We confirm the request by phone before preparing it. The archive is a ZIP file encrypted with AES-256 using a password the administrator sets; it holds one CSV file per table, a CSV index of the files and a JSON summary, and it is downloaded from the same page.
2. Data structures in a migration package
| Collection | Scope and structure | Format |
|---|---|---|
| Manifest | Schema version, generation date, file and collection inventory, record counts, relationships, code lists, and checksums where used. | JSON |
| Account and settings | Customer, branch, user, role, permission, and Customer-created setting data; only values and metadata needed to read the data and preserve relationships. | CSV or JSON |
| Master data | Contractors, contacts, employees, drivers, fleet, vehicles, trailers, warehouses, and other registers: identifiers, descriptive and contact details, business numbers, statuses, dates, and relationships. | CSV or JSON |
| Operations | Orders, stops, routes, assignments, statuses, schedules, load plans, costs, settlements, reminders, CRM, and other operational records: identifiers, dates, parties, places, amounts and currencies, statuses, line items, and relationships. | CSV or JSON |
| Communications | Announcements, messages, and available delivery history: sender and recipient, content, channel, status, timestamps, and attachment references. | JSON or CSV |
| Location and telematics | Available points and route history, vehicle or device, time, coordinates, source, accuracy, and movement parameters where recorded; geofences and events. | CSV or JSON |
| Custom-module data | Records entered or generated by the Customer, plus field names and types and relationships needed to read them. This excludes the module definition, form and view layouts, formulas, automations, workflows, and executable logic. | CSV or JSON |
| Files | Documents, images, recordings, and other attachments in their original format, plus an index containing filename, MIME type, size, related-record identifier, and timestamps. | Original format + index (JSON or CSV); ZIP container |
| eCMR documents | For each issued electronic consignment note, an evidence package: the record of each version, every PDF rendition (PDF/A-3B, or plain PDF where that conversion fails), the hash-chained event log, the signatures, entries and their photos, the platform seals, the time stamps (if any), the certificates, the country rules and eCMR Procedures files the note was issued under, a manifest of SHA-256 checksums, and a verification script with instructions. A structured export of a version (schema ecmr-export/1) holds the ecmr-record/1 record, the signatures, the entries and a block mapped to the eFTI common data set. Users who manage the eCMR settings can download every note in pages of 20 packages, each page with a CSV index. | ZIP container; JSON and JSON Lines; PDF; JWS seals; RFC 3161 time stamps (DER); PEM certificates; CSV index |
| Customer-facing audit data | Audit events available to the Customer: time, action type, actor, object, result, and safe metadata. | CSV or JSON |
A complete package contains all portable data from features used by the Customer. The Customer may request a narrower scope. Empty collections and technical fields or internal metadata not needed to read the data or preserve its relationships are omitted; the manifest identifies exactly what the export contains.
3. Common rules and standards
- text: Unicode UTF-8;
- tabular or flat data: CSV under RFC 4180 with a header row; complex data, manifests, and indexes: JSON under RFC 8259; files: original formats in a ZIP container;
- dates and times: ISO 8601, including the time-zone offset where available;
- currencies: three-letter ISO 4217 codes, with amounts as decimal values without thousands separators;
- coordinates: WGS 84 (EPSG:4326), unless the source requires preservation of another reference system;
- eCMR evidence: SHA-256 hashes, seals as JSON Web Signatures (RFC 7515) with X.509 certificates in PEM, and time stamps under RFC 3161, if any; each package explains its checks in
VERIFY.md; - record relationships: stable identifiers; missing values:
nullin JSON and an empty field in CSV; - export interfaces, where supplied: HTTPS and JSON; authentication, limits, and endpoint details accompany the export documentation.
4. Known limitations
- We do not export Platform code, credentials, secrets, internal infrastructure logs, or material protected by the Service Provider's or a third party's rights or trade secrets unless the Customer has a right to use the relevant asset outside the Platform independently of the Agreement.
- A custom module operates only within LiteTMS, so its definition, interface, formulas, automations, workflows, and logic are not ported. The Customer's data stored in it and the minimum field and relationship description needed to read that data are ported.
- Files retain their source format and may require suitable software to open.
- Integration data is exported to the extent stored in LiteTMS and permitted by data rights. We do not recreate data an external provider no longer supplies.
- Porting configuration does not guarantee identical operation at another provider. We supply data and available documentation needed to interpret it; the destination provider remains responsible for its import and functionality.
- Very large datasets may be divided into parts. Encryption and the secure delivery method of a migration package are agreed with the Customer; the Settings data export uses the AES-256 password described in section 1.