Captures files and database chunks locally, signs a manifest, and opens an outbound encrypted stream to the destination.
New migration
Create an account, confirm data ownership, connect both endpoints, and run a no-custody migration.
- 1Account
- 2App profile
- 3Source
- 4Destination
- 5Review and migrate
Account creation and data authorization
Users must create an accountable workspace and confirm they own or are authorized to migrate the data before any script runs.
App profile
Choose the stack you are moving.
Waiting for install folder scan.
Source endpoint
Where the current site lives.
We can remember label, host, port, username, app path, and preferred method. Passwords, private keys, and one-time tokens are encrypted for this migration only.
Folder ready for scan
Destination endpoint
Where the app will be migrated.
Saved destination profiles can be reused later, but migration secrets are entered again for each job and encrypted before the agent handshake.
Secrets ready for per-job encryption
Direct server-to-server
We only orchestrate. Your servers talk directly.
Source server
203.0.113.25
Source to destination tunnel
TLS 1.3 + signed job token
Destination server
198.51.100.42
No custody
Control plane never touches payloads.
Creates or validates the fresh install, receives chunks directly from source, restores paths, imports DB, and rewrites config.
Stores progress, consent, hashes, and error telemetry. No archives, dumps, uploads, or customer payloads land here.
Passwords and tokens are never saved in endpoint profiles; they are encrypted for the active migration handshake only.
Domain and rewrite plan
Apply same-domain moves, temp domains, cutovers, and serialized-safe WordPress URL replacement to the migration job.
This is billed as a route add-on when the base migration qualifies as free.
Same-domain dry run: source and destination stay on the source URL; no database URL rewrite is scheduled.
Recent migrations
| ID | Application | Source | Destination | Status | Progress | Credits | Action |
|---|---|---|---|---|---|---|---|
| MIG-98214 | W WordPress 6.5 | 203.0.113.25 /var/www/nyc_wp |
198.51.100.42 /var/www/staging_wp |
Ready to migrate | 240 | ||
| MIG-98213 | M Magento 2.4.6 | 192.0.2.44 /home/magento_live |
198.51.100.42 /var/www/magento_stg |
Completed | 382 | ||
| MIG-98212 | D Drupal 10.2 | 203.0.113.88 /var/www/drupal_prod |
192.0.2.77 /var/www/drupal_stage |
In progress | 316 | ||
| MIG-98211 | JS Node.js custom 18.x | 198.51.100.11 /opt/apps/api |
203.0.113.25 /opt/apps/api_stg |
Queued | 210 |
Migration troubleshooting
Common blockers get actionable fix popups so operators can recover without guessing.
Start is blocked until the account owner confirms authorization to move the data.
Filesystem permissions, disabled plugin editor, or ModSecurity can block the helper plugin.
Wrong owner/group or jailed path prevents the destination agent from writing restored files.
Large dumps need chunked import, extended packet size, or a direct database socket path.
The destination runtime does not match the detected app requirements.
Strict WAF rules can challenge the signed endpoint handshake or callback telemetry.