Maintenance

Migrate ClientExec exports

ClientExec native collections, exact export requirements, mapping limits and safe imported state.

Platform
Laravel / PHP
Laravel
13
PHP
8.4
Database
Dedicated MySQL-compatible production database

Supported source and collections

The reviewed newer Migration centre has an explicit ClientExec reader. This is an export-file reader requiring the matching released core; it is not a live account connector or an automatic database cutover. Select ClientExec and the exact destination storefront.

Native export format: Get Users / Get User JSON export.

Native collections: customers.

Source-specific preparation

Native customer profiles; supply customer_currencies[id] because the public user response omits currency. Use mapped CSV or JSON for packages, invoices, payments and support history; public package endpoints do not document a complete read export.

Export all pages and keep stable source IDs. Remove passwords, password hashes, tokens, saved card/payment instruments and provider credentials. Use a stable source_instance across batches and explicit ISO currency mappings; never infer currency from a symbol or destination default. For collections outside this native reader, choose mapped CSV/JSON and supply every required field explicitly.

Preview and import

Review the complete field and wrapper reference, then upload within the bounded size/row limit. Preview owner, destination, counts, normalised samples, currency mappings and conflicts. Apply only that unchanged reviewed preview with the required sensitive-admin confirmation. An exact repeated source import is idempotent; conflicting changed records are held, not overwritten.

Imported state and limits

New customers start disabled with new random passwords; products stay inactive/manual; automatic service/domain renewal and provider mapping remain off. Historical invoices remain legacy_review and cannot request payment until reconciliation. Historical payments move no funds. Source contacts, ownership, dates and amounts are preserved where supported, while unsupported ticket attachments/messages, orders, credit ledgers, mandates and configuration need separate review. Negative native credit lines are refused instead of silently converted.

Use Migration centre operations for multi-batch parent references, explicit existing-customer mapping, encrypted provenance, transaction/conflict behavior and the guarded CLI. A successful preview is not a production migration acceptance.

← All EmailaBiller guidesGet help →

Need help with EmailaBiller?

Tell us the product version and what you are trying to do. Keep passwords and private keys out of your message.

Contact Emaila