Transfer Content Between Environments

An environment transfer copies one environment’s content into another environment of the same Website. It is one operation in both directions; the interface names it after where the content lands.

• Clone fills an environment that has never held content.
• Sync refreshes a non-production environment, usually from production.
• Promote sends a non-production environment’s content to production.

Transfers are available on WordPress, Static HTML, and Node.js Websites. Both environments must be hosted by TMXIO and belong to the same Website. Production, staging, and development can each be a source or destination. PHP Websites continue to deploy to each environment from your own pipeline.

For Node.js, follow Transfer a Node.js release. The backup-selection and file/table controls below apply to WordPress and Static HTML.

Before you start

Only Account owners and administrators can run a transfer, and only one transfer runs at a time per Website.

The transfer reads a completed backup of the source environment, so the source needs at least one. Choose which one on the confirmation panel: the most recent is selected for you, and an earlier restore point is available when you want the environment as it was at a particular time.

Run a WordPress or Static HTML transfer

1. Open Environments for the Website.
2. On the environment holding the content you want to copy, select Transfer from here.
3. On the environment you want to replace, select Send here. A connector is drawn between the two, pointing at the environment that will be replaced.
4. Choose a restore point.
5. Review the checks, then confirm.

Select Reverse to swap the two ends. Select Choose what moves to transfer only some files and tables.

What a WordPress or Static HTML transfer replaces

By default the destination is made to match the source: content the source no longer has is removed from the destination.

When you choose what moves, only the files and tables you select are replaced. Everything else on the destination is left exactly as it is, including files the source does not have.

The destination keeps its own identity in every case: its own address, its own database credentials, its own PHP version, and its own TMXIO configuration. Settings are never transferred, only content.

What happens to a WordPress or Static HTML destination

The destination is backed up before anything is replaced, so a transfer can be undone from that environment’s backup history.

A transfer into production is verified before it is reported as complete, and production is returned to its pre-transfer backup automatically if it fails. A transfer into a non-production environment is left in place when it fails so you can inspect it, and can be rolled back from its backup history.

The destination is briefly unavailable while its new content is put in place.

WordPress staging and development environments

An environment that is not production is prevented from acting on the outside world, because a transfer gives it a copy of production’s configuration along with production’s content:

• Search engines are refused with a noindex response header.
• Outgoing mail is suppressed. WordPress reports messages as sent, but nothing leaves the environment.
• Scheduled tasks do not run.

These apply after every transfer and cannot be turned off. Test anything that sends mail or depends on scheduled tasks on your production environment.

Third-party credentials stored inside your Website’s database — payment keys, API tokens, licence keys — are copied with the rest of the content. Replace them in the destination if it must not use your production accounts.

Transfer a Node.js release

Both environments must use artifact delivery. Select a retained release with confirmed healthy runtime diagnostics; a release marked Active with warning cannot be transferred. A release without health information needs a fresh deployment or confirmed runtime observation before it can be selected.

1. Open the source environment’s Node.js deployment history.
2. Select Transfer beside the healthy release you want to copy.
3. Choose the destination environment. Production defaults to staging and staging defaults to production; from development, choose the destination explicitly.
4. Choose whether to Include Data Directory and Overwrite destination runtime settings. Both options start unchecked.
5. Read the source, destination, and overwrite warnings. Type the destination identity shown in the dialog, then confirm.

The selected release always transfers. TMXIO takes fresh, usable backups of both environments before applying changes. If a backup cannot be completed or used safely, the transfer stops before changing the destination.

Choose what is overwritten

Include Data Directory replaces the destination’s Data Directory with the source’s data. This includes SQLite and any other embedded database files stored there. It can overwrite destination application data in every direction, including production to staging and development to production. If you leave this option unchecked, destination data stays in place. Data Directory enablement is a separate destination setting and is never changed by a transfer.

Overwrite destination runtime settings copies the source’s Node version, start command, resource profile, health path, app directory, and immutable asset directories. Leave it unchecked to keep the destination’s current settings; make sure those settings can run the selected release.

The destination always keeps its own environment variables, secrets, delivery mode, domains, credentials, and TMXIO-managed databases. Managed databases are never copied or overwritten. Secrets stored inside Data Directory files do move when that directory is included; review production data before copying it into staging or development. Node.js transfers do not automatically anonymize data or disable application-managed mail and scheduled jobs.

Understand the result

Transfer complete means the release activated and the recorded runtime checks passed. Verify the destination’s public URL and important application paths before relying on it.

Transfer completed with warning means activation finished, but the application is inactive, repeatedly restarting, or its service status could not be confirmed. The new release stays in place, including on production. Review the reason shown and check the destination’s Node version, start command, health path, and runtime settings. Use the destination’s application logs to investigate and redeploy after correcting the problem.

Transfer needs attention means a transfer step failed. The result explains the failed step, whether the destination was changed or restored, and what to do next. Failures during data application trigger restoration of the destination safety backup. Release installation or HTTP health-check failures retain the deployment’s normal rollback behavior. If recovery also fails, follow the displayed instructions and contact support with the transfer number.

Transfer progress and warnings remain available after refreshing the page. Starting another transfer while an earlier one is running is rejected; follow the existing transfer until it finishes before trying again.

Storage

Each environment keeps its own backups, so an environment that has received a transfer adds to your Website’s stored data. The WordPress and Static HTML confirmation panel shows how much the transfer will add before you confirm. Repeat transfers between the same two environments only store what has changed since the last one.