Migrate an existing database

Treat a database migration as a data-transfer project: preserve the source, import into a separate destination, verify it, and then switch the application. Do not delete a working source as the first step.

Prepare the migrationCopy Anchor Link

• Record the source engine and version, database size, storage engine, collation, and required extensions.
• Export both the database and any application files stored outside it.
• Preserve the application's encryption key and required secrets; replacing an encryption key can make existing encrypted values unreadable.
• Choose an Openstead destination plan with room for indexes, logs, temporary work, and future growth.
• Decide how to stop or reconcile writes during the final cutover.

Openstead MySQL uses version 8.4. A MariaDB dump or older MySQL application may need syntax, collation, or SQL-mode changes. PostgreSQL extensions and major-version compatibility should also be checked before import.

Create an empty destinationCopy Anchor Link

Create the managed database in the application's intended environment. Wait for it to be running, and record its connection fields securely.

The database ports are private. A client on your laptop cannot import directly into the private hostname. Use phpMyAdmin for suitable MySQL imports or a deliberate migration client running within the same Openstead environment.

Import MySQLCopy Anchor Link

For smaller SQL files, use phpMyAdmin. Its total request ceiling is 32 MiB and execution limit is 60 seconds, so large or complex imports need another approach.

A migration client in an authorised application shell can use the standard MySQL client if that binary is installed in the application's image:

mysql --host="$DB_HOST" --port="$DB_PORT" \
  --user="$DB_USERNAME" --password "$DB_DATABASE" < backup.sql

The --password option prompts for the password instead of embedding it in the command history. Substitute your current private connection values through the application's environment. Transfer the dump through a secure, controlled path and delete temporary copies after verification.

Inspect dumps for CREATE DATABASE, USE, GRANT, and DEFINER statements that refer to the old host's database or users. The managed application user cannot create arbitrary server users or access other schemas. Do not import MySQL system databases.

Use InnoDB for tables that need Openstead's consistent logical-backup workflow. If an import fails, check the partial destination before retrying rather than assuming every statement rolled back.

Import PostgreSQLCopy Anchor Link

Use PostgreSQL client tools compatible with the dump version from an authorised application environment. A custom-format archive uses pg_restore; a plain SQL dump uses psql.

pg_restore --no-owner --no-acl --single-transaction \
  --dbname="$DATABASE_URL" backup.dump

This example assumes a new empty database, a compatible archive, and an installed PostgreSQL client. Review extensions and privileges before running it. Do not run a destructive clean option against a database already serving customers.

The dashboard's Recovery workflow restores Openstead-created backups into separate managed instances. It is not an arbitrary file-upload importer for every external dump format.

Verify before switchingCopy Anchor Link

Compare expected table counts and representative rows. Test login, encrypted application fields, reports, queues, migrations, and file references. Confirm the application uses the destination's database name and current credentials.

For a final cutover, pause source writes as required, take the final export, complete the import, and point application references to the destination. Redeploy every process that uses the database, including workers.

Create a fresh Openstead backup and test application behaviour before retiring the source. Retain the original export according to your recovery requirements.

If migration needs assistanceCopy Anchor Link

Contact Openstead support with the engine versions, approximate dump size, destination service ID, and redacted error text. Never send database passwords, complete connection URLs, or production dumps containing customer data.