Move an app from cPanel to Eza Cloud

Eza support can answer questions about Eza tools through support@eza.co.ke.

Eza staff do not access your cPanel account, VPS, foreign host or domain registrar.

• Migration questions receive a first reply within 1 business day.
• If a production app migrated to Eza is broken, Eza aims to respond within 4 business hours during support hours.
• Support hours are Monday to Saturday, 08:00 to 18:00 EAT.
• Self-service migration is free.

Pending founder decision: decide whether Eza will offer paid hands-on migration help later. Do not publish pricing for a service that does not exist. Confirm support staffing and ticket routing can meet the 1-business-day and 4-business-hour targets before publishing.

You need:

• Access to your Eza Cloud account.
• Access to the cPanel account.
• Access to your domain registrar or DNS host.
• A local computer with Git, the Eza CLI and database client tools.
• A copy of your app code and uploaded files.
• Database credentials for the old host.
• A rollback plan.

You should also:

• Record your current domain DNS records.
• List environment variables, email settings and third-party API keys.
• Check current PHP version, extensions and cron jobs.
• Check how your app stores uploads.
• Identify background jobs and scheduled tasks.
• Reduce DNS TTL at your registrar or DNS host 24 to 48 hours before cutover.

Eza does not host DNS. Lowering TTL happens at your existing registrar or DNS host.

Use this order:

1. 1Create and deploy the Eza app.
2. 2Create the Eza database.
3. 3Import a trial copy of the old database.
4. 4Copy app files and uploads.
5. 5Test the app using the Eza temporary URL.
6. 6Fix configuration and application errors.
7. 7Schedule a short maintenance window.
8. 8Stop writes on the old app.
9. 9Export the final database copy.
10. 10Import the final database copy into Eza.
11. 11Switch DNS to Eza.
12. 12Check the live app.
13. 13Keep the old host available until the new app is confirmed.

The old host can remain live during a trial import.

For the final import, stop writes on the old app. Use your application’s maintenance mode or read-only mode. Any records written after the final database dump will not exist in the Eza database.

Every Eza app gets a default HTTPS URL before you add a custom domain. The format is:

https://{app}-{org}.{apps-domain}

Example:

https://shop-acme-juma-shop.{apps-domain}

Pending fact: confirm the final Eza apps domain and replace {apps-domain} before publishing. It must be the separate apps domain, never app.eza.co.ke or another subdomain of eza.co.ke.

Customer apps do not use an eza.co.ke subdomain.

Use the default URL to test the Eza deployment before you change public DNS. Do not use the temporary URL as your permanent production domain.

Create an Organisation for the app you are moving. If you are an agency, create one Organisation per client.

Choose a hosting plan:

Prices include VAT at 16% and are paid by M-Pesa.

Create the app in Eza and choose the production environment.

Do not rely on a cPanel full-account backup as your deployment source. Get the application code into a Git repository where possible.

PHP or Laravel

1. 1Download the app files from cPanel File Manager.
2. 2Exclude runtime files, logs and secrets.
3. 3Add a .gitignore file.
4. 4Add environment variables to Eza instead of committing .env.
5. 5Commit the code to GitHub, GitLab or Bitbucket.

WordPress

• Copy the files needed by your deployment workflow.
• Do not place database credentials in version control.
• Treat uploaded media separately from application code.
• Review persistent-volume or object-storage setup before copying uploads.

Without Git

If you cannot use Git, deploy the local folder with the Eza CLI.

$ cd your-app$ eza link$ eza deploy --local

The Eza CLI respects .gitignore and .ezaignore during local uploads.

Create a managed database in Eza before importing data. Use the database engine that matches your app.

• PostgreSQL
• MySQLBeta
• MongoDB-compatibleBeta
• Redis-compatible

• PostgreSQL is generally available.
• MySQL is Beta.
• MongoDB-compatible is Beta and runs on FerretDB.
• Redis-compatible uses Valkey.

WordPress normally needs a MySQL-compatible database.

Pending product confirmation: publish the tested WordPress and MySQL setup before using this guide for production WordPress migrations.

Eza injects connection details into your app environment. Do not copy the old database password into your app if Eza provides new connection values.

MySQL and MariaDB

Use cPanel database backup tools or phpMyAdmin.

1. 1Open the database backup area or phpMyAdmin.
2. 2Select the database used by your app.
3. 3Export it as SQL.
4. 4Save the dump file on your local computer.

For WordPress, confirm you export the database shown in wp-config.php. Example values to find:

define('DB_NAME', 'example_database');define('DB_USER', 'example_user');define('DB_HOST', 'localhost');

PostgreSQL

If your cPanel account provides PostgreSQL access, export the database using the database tools available in cPanel or your local PostgreSQL client. Use pg_dump for a PostgreSQL export.

$ pg_dump \    --format=custom \    --file=old-app.dump \    "postgresql://OLD_USER:OLD_PASSWORD@OLD_HOST:5432/OLD_DATABASE"

A custom-format pg_dump archive is restored with pg_restore.

Keep the export file private. It can contain customer data and credentials. Encrypt dump files on your computer where possible, and delete them after a successful migration.

Use eza db tunnel to expose a managed database through a local TCP port.

$ eza db tunnel production-db

The tunnel works with psql, pg_restore, mysql, mongosh and redis-cli. Keep the terminal open while you import the database.

Pending product confirmation: publish exact tunnel output, local port selection and connection instructions before this guide ships.

MySQL or MariaDB dump

MySQL is Beta on Eza. Use the MySQL client through the Eza database tunnel.

$ mysql \    --host=127.0.0.1 \    --port=[LOCAL_PORT] \    --user=[EZA_DATABASE_USER] \    --password \    [EZA_DATABASE_NAME] \    < old-app.sql

PostgreSQL plain SQL dump

$ psql \    "postgresql://[EZA_DATABASE_USER]:[EZA_DATABASE_PASSWORD]@127.0.0.1:[LOCAL_PORT]/[EZA_DATABASE_NAME]" \    < old-app.sql

PostgreSQL custom dump

$ pg_restore \    --host=127.0.0.1 \    --port=[LOCAL_PORT] \    --username=[EZA_DATABASE_USER] \    --dbname=[EZA_DATABASE_NAME] \    old-app.dump

pg_restore restores PostgreSQL archive formats created by pg_dump.

Do a trial import before the maintenance window. Do not delete the old database until the Eza app has been tested after cutover.

Move configuration from your cPanel .env, PHP config files or application settings into Eza environment variables. Do not commit secrets into Git.

Common values include:

APP_ENV=productionAPP_URL=https://your-domain.co.keDATABASE_URL=[EZA PROVIDED VALUE]DB_HOST=[EZA PROVIDED VALUE]DB_DATABASE=[EZA PROVIDED VALUE]DB_USERNAME=[EZA PROVIDED VALUE]DB_PASSWORD=[EZA PROVIDED VALUE]

• Use only the variables your app expects.
• Runtime variables are injected when the app starts.
• Build-time variables enter the build only when you mark them as build-time.
• Secret values are encrypted at rest and hidden until revealed.

Pending product confirmation: publish eza env set and eza env pull syntax before adding CLI examples.

Do not assume files inside a cPanel app directory will survive a new deployment.

• For WordPress, uploads commonly live in wp-content/uploads.
• For Laravel, uploads may live under storage/app.

Use a persistent volume for app files that must remain after deployments. A volume can grow. It cannot shrink.

For a multi-replica app, use Eza Object Storage for shared uploads. A persistent volume ties an app to one replica.

At launch, Eza has no SFTP access and no SSH access to app containers.

Pending product confirmation: eza volumes cp <local path> <app>:<mount path> is proposed. Do not publish it until it exists and is tested.

For media stored in object storage, use S3-compatible tools such as rclone or aws s3 sync, then configure the app or a media-offload plugin to use that storage.

Test the app before touching your custom domain. Check:

• Home page loads.
• Sign-in works.
• Forms write to the new database.
• File uploads work.
• Email settings work, if used.
• Background workers run, if used.
• Scheduled jobs use the right schedule.
• Payment integrations use the correct keys.
• HTTPS works.
• Build and runtime logs show no unexpected errors.

For Laravel, check the health path and application configuration. For WordPress, check pages, permalinks, uploads and administrator sign-in.

For any app, test creating and editing data. Then remove the test data before final cutover if needed.

• Add the domain in Eza before changing DNS.
• Eza shows the DNS records you need to add.
• Eza can verify domain ownership before you switch traffic.
• The SSL certificate issues after DNS points to Eza.

Eza checks DNS every minute. After DNS resolves to Eza, SSL usually issues within 5 minutes. DNS propagation time depends on the old TTL, resolver caching and your DNS provider.

1. 1Plan a short maintenance window.
2. 2Put the old app into maintenance mode or stop writes.
3. 3Export a final database dump from cPanel.
4. 4Import the final dump through the Eza database tunnel.
5. 5Check the app on the Eza temporary URL.
6. 6Update DNS records at your registrar or DNS host.
7. 7Wait for DNS to resolve to Eza.
8. 8Confirm that the SSL certificate is active.
9. 9Test the live domain.
10. 10Keep the old host available until you confirm that the new app works.

For Laravel, use the app’s own maintenance mode if your app supports it. For WordPress, use a maintenance plugin or another WordPress-level maintenance method.

Eza does not provide platform maintenance mode or redirect rules at launch. Use application code, application configuration or your existing web-server rules for redirects.

Do not write new data to both the old and new databases during the cutover. That creates records you must reconcile later.

After DNS resolves to Eza:

• Check the home page.
• Check sign-in and core user actions.
• Check the database writes.
• Check uploads.
• Check email and third-party integrations.
• Check workers and scheduled jobs.
• Check billing or payment flows.
• Read the runtime logs.
• Confirm SSL is active.

Keep the old host and backup files until you are confident in the migration.

• Failed health check

  If a deployment fails health checks, the previous Eza deployment stays live.

• Rollback

  You can roll back to an earlier Eza deployment in about 30 seconds.

If the Eza app has a deployment problem, use build logs and runtime logs.