Migrations without the blind leap

Prepare the migration

Inspect the source before moving

A migration should begin with a verified source inventory. SHM can connect to supported cPanel, Plesk, DirectAdmin, or SHM sources, discover available accounts and resources, and present them for selection before work begins.

The source type matters because providers describe accounts differently. SHM gathers provider-specific data, hydrates it into a common migration model, and records the limitations of each source format.

Select the resources to migrate

Operators can select accounts and the supported resource groups needed for the job, including web files, databases and users, mail resources, FTP data, DNS state, and account settings where the source provides them. Package, owner, and IP mapping can be adjusted for the destination. Mail migration includes more than mailbox folders. Supported paths handle mailboxes, forwarders, autoresponders, filters, global filters, spam preferences, and mailing lists when those resources exist and the provider exposes enough source data.

Define the conflict policy

An account name or domain may already exist on the destination. SHM makes the conflict policy part of the job: skip safely, overwrite only under the selected rules, or stop on conditions that require an operator. Domain ownership is checked across accounts so importing one customer does not quietly claim another customer's hostname.

Ownership validation is part of migration correctness; copied data assigned to the wrong customer is not a successful result.

Run and verify the migration

Run the transfer as a tracked job

Transfers and restores run as migration jobs with stages and logs instead of holding a browser request open for the duration. Concurrency can be bounded, and operators can follow each account through gather, transfer, hydrate, execute, and verification-related stages.

Failures remain attached to the affected job and step. Supported retry or resume behavior can continue from the known state rather than forcing a blind restart of every account.

Create native SHM state at the destination

Imported data is not left as a foreign-provider configuration folder. SHM serializes the account model into its own state, merges resources through the migration worker, creates the destination resources, and regenerates the web, DNS, database, mail, and account runtime artifacts that SHM normally owns.

The final UI projection matters too. A migrated forwarder, filter, database, or mailbox should appear where a newly created SHM resource appears, because future management depends on one source of truth.

Verify the destination item by item

Provider exports vary by product and version, so identical feature coverage cannot be assumed. SHM verifies the supported contract across source gather, hydration, YAML serialization, parsing, merge, execution, generated resource, and UI projection. Unsupported or unavailable source data must be reported, not invented. This produces a dependable migration sequence: inventory first, explicit choices, visible conflicts, staged execution, and destination checks. The operator can verify what moved and identify any unsupported source data before completing the project.