End-to-end migration
Connector, gateway, import and cutover
Mivama migration is a customer-authorized, plugin-assisted transfer into one owned Hosting Service. Every migration gets its own record, one-time access code, scoped upload token and staging directory.
Participants
| Participant | Role |
|---|---|
| Portal | Creates/displays migration and customer instructions |
| Mivama Core | Owns migration identity, authorization, states and commands |
| Connector plugin | Runs on the source WordPress, scans and uploads data |
| Migration gateway | Accepts authenticated metadata/chunks without root privileges |
| Import worker | Pulls import work and applies it to the target tenant |
| Hosting runner | Ensures the target hosting runtime exists and is healthy |
Connection and initial import
The code exchange fails after use or expiry. Subsequent plugin requests use the migration token, not the human code. Disconnect removes local plugin credentials.
Source scan
The connector records WordPress/PHP versions, site URLs, database size, upload/file inventory, active theme/plugins and compatibility warnings. The customer confirms they own or are authorized to transfer files, database, users, orders and personal data.
Files upload in bounded chunks with sequence, size and integrity validation. The gateway writes only inside the assigned migration directory under /srv/mivama/migrations. It does not run WordPress or Docker commands.
Privileged import
The import worker is root because it must enter the target tenant, manage backups, import MariaDB content and repair ownership. WordPress CLI runs as the target WordPress user or correct container user—never as root executing untrusted site code.
Import includes:
- confirm target service and tenant paths from Core;
- create a rollback backup;
- validate archive and database payloads;
- restore files without path traversal;
- import database;
- replace source URL with target preview/live URL;
- preserve correct tenant ownership;
- flush cache/rewrite rules and run health checks;
- report structured result.
Review and final sync
The initial copy becomes a reviewable target. The original site can remain live while the customer verifies pages, checkout, users and plugins. Approved final sync transfers the delta and newest database, then performs cutover checks. During that short critical phase, the target can show a maintenance message.
Migration completion removes the temporary transfer capability and marks onboarding complete. It does not silently change external DNS unless that exact cutover step is configured and confirmed.
Sources: api/_portal_migrations.py, migration_runtime/gateway.py, migration_runtime/import_worker.py and the Mivama connector plugin source.