Move code and data

Move code first, then copy production data into the target App. Keep the source App available until verification and cutover are complete.

Prepare and deploy the code

1. Choose Git or Workspace as the migration deploy source.
2. For Git, connect the production repository and select the branch, tag, or commit that matches production.
3. For Workspace, transfer the prepared project tree through the managed shell or file-transfer workflow and inspect it before deploy. For Magento, include the production vendor/ tree when the migration relies on the host’s full file tree instead of repository downloads.
4. Configure the required Vars, secrets, services, scheduled jobs, and persistent paths.
5. Start the first deploy from the selected source.
6. Confirm that the deploy completes before importing production data.

Don’t point public DNS at the target yet.

Copy the database

Export the source database with the source platform’s own dump tool. Import it into the target through the managed shell: the shell includes a MySQL client, and the platform-provided DATABASE_HOST, DATABASE_NAME, DATABASE_USER, and DATABASE_PASSWORD variables already identify the App’s own database (see the database connection details). A Team owner or admin must first grant the file transfer or database access these steps use.

1. Pause scheduled jobs with the Scheduled jobs enabled control so recurring commands can’t run against a half-imported database.

2. Transfer the dump into the Workspace with SFTP or SCP using a file transfer grant, or with rsync from the managed shell.

3. Import from the managed shell:

   Import a dump from the managed shell

   mysql --default-character-set=utf8mb4 \
     -h "$DATABASE_HOST" -u "$DATABASE_USER" -p"$DATABASE_PASSWORD" \
     "$DATABASE_NAME" < production-dump.sql

   The client prints a warning that a password on the command line can be insecure; that warning is expected here and isn’t an error.

4. Remove the dump file from the Workspace after the import, and resume scheduled jobs when verification starts.

Caution

An import that stops partway — a dropped SSH session, a truncated transfer, a statement error — leaves the target half-populated. Recover by re-running the complete import (a standard full dump recreates its tables from the start) or by restoring the target database to a recovery point taken before the import. Verify counts before building on an interrupted import.

The platform account in DATABASE_* is scoped to this App’s own database, so the import can’t touch anything outside it. To run the import from a desktop database client instead, use the SSH database forward with a scoped database account. Import time depends on dump size; the rehearsal’s recorded duration is your estimate for cutover.

If the import aborts, the error class points at the fix:

• “MySQL server has gone away” or a packet-size error: a large row exceeded the packet limit. Raise max_allowed_packet in the App’s MySQL service settings, apply, and re-run the import.
• A privilege error on a DEFINER clause: the dump carries views, triggers, or events defined by a source-database user. Strip the DEFINER clauses from the dump and re-import.
• A privilege error on a SET statement near the top of the dump: the source dump embeds replication state. Re-export with mysqldump --set-gtid-purged=OFF so the file replays under a restricted account.

Treat an import as a replacement of target data. A full export and import is the default. Use an incremental or delta method only when the source supports it, the process has been rehearsed, and the target hasn’t accepted independent writes. Don’t allow writes to both databases unless the application has a tested replication design.

Copy media and persistent files

Transfer customer uploads into the framework’s uploads path in the Workspace, using the same file-transfer grant or rsync:

• WordPress: wp-content/uploads — a platform-default shared path; requests to /wp-content/uploads/... URLs are served from it.
• Magento: pub/media — requests to /media/... URLs are served from it.

The application can also build some media URLs against managed media storage, where files land when they’re uploaded through the running application rather than transferred. After the transfer, browse a few migrated pages and confirm their images load; Verify the migrated App covers the full media-link check before cutover.

Exclude caches, temporary files, generated assets that the build recreates, and source-platform credentials.

Note

Files you transfer this way live on the App’s persistent files volume and are protected by App-file snapshots. Media that customers upload through the running application is stored in managed media storage and gains media version protection. Both layers are backed up; they restore through different actions.

Preserve file names, paths, content types, and application ownership rules. A successful file count alone doesn’t prove that application references are correct.

Update environment-specific values

Replace source-specific hostnames, callback URLs, storage endpoints, and credentials. Rotate any credential exposed during export or transfer.

Use Vars and secrets for runtime configuration. Use Services for supported service settings.

Repeat until predictable

Run at least one rehearsal before final cutover. Record the duration of the database copy, media copy, cache rebuild, deploy, and verification steps.

Continue with Verify the migrated App.