Move Installatron Backups to a New Server: Import and Restore Checklist

July 27, 2026

Moving an Installatron backup archive to another server does not automatically make it appear in the destination server’s My Backups list. That list is an Installatron inventory, not a general-purpose file browser. To make the backup usable on the new server, the destination must either receive the full Installatron service state during a server migration or register a valid Installatron-created archive from an approved backup location.

This guide separates those two jobs, so you can preserve the right history without confusing an application import, a hosting-panel backup, and an Installatron backup archive. It is written for WordPress owners, hosting customers, and server administrators using Installatron with a hosting control panel.

Installatron logo from the vendor’s documentation, used here to identify the backup-transfer workflow.

Choose the right transfer path first

There are three common situations, and they should not be handled as the same migration.

Moving the Installatron service to a replacement server: the administrator transfers the service data, configuration, and Installatron database as a coordinated server move. This is the right path when the goal is to retain installed-application records, backup history, and administrative settings together.
Moving one hosting account’s backup archives: the destination server receives existing Installatron-created archives in an approved backup location, then an Installatron administrator registers them with the destination inventory.
Reusing remote storage: the destination server is connected to the approved remote backup location, then the eligible archives are registered for the correct account. Connecting storage alone is not the same as importing its backup history.

If you are moving the live WordPress site as well, keep that work separate from the backup-history task. Installatron Clone or Import can create and track a destination application, but it does not by itself recreate the old server’s My Backups entries.

Before you move anything

Make a short handoff list for every backup you intend to preserve. Record the application URL, account owner, backup date, destination account, and whether the backup is in an account folder or remote storage. This prevents an archive from being assigned to the wrong customer or mistaken for a generic hosting-panel backup.

Keep the source backups available until the destination list and a safe restore check have been verified.
Use only archives that Installatron created. A normal file archive or a general cPanel backup is not an Installatron backup-history import.
Keep transferred backups in a protected, provider-approved backup location. Do not place archives in a public web directory.
Confirm which destination account should own each backup before it is registered.
For an online store, schedule the site move separately and follow the WooCommerce migration checklist so new orders are not overlooked.

Path 1: A provider is moving the Installatron service

Use this path when a provider is replacing or migrating the server that runs Installatron itself. The goal is to preserve the service’s knowledge of installed applications and backup history, not simply copy selected archives.

Installatron’s Plugin transfer documentation calls for a current Installatron installation on the destination and a control-panel account transfer that includes the account’s .appdata and application_backups directories. Installatron’s Server transfer documentation separately covers moving service data, configuration, and the service database when Installatron Server is the product in use. These are provider tasks: they should be planned as a coordinated migration, with the destination license assignment and service validation handled by the administrator.

Confirm whether the source uses Installatron Plugin or Installatron Server so the provider follows the matching vendor transfer guidance.
Have the provider transfer the hosting accounts and the relevant Installatron account data as part of its approved server-move process.
After the destination service is ready, open representative accounts and confirm that My Applications and My Backups show the expected history.
Perform a controlled restore to a non-production or newly migrated target before retiring the old service.

This route is normally a host or server-administration task. It is safer than trying to rebuild a full server’s history by importing individual archives, and it avoids exposing configuration details that should remain private.

The direct account-level method: make a backup appear in My Backups

For a small number of backups moving with one hosting account, use the destination account’s Installatron backup storage. Installatron documents that an Installatron-created archive that no longer appears in the interface can be uploaded to the account’s ~/application_backups/ folder; after you reload My Backups, it should be listed again. This is the most direct answer when the new server already has Installatron and the destination hosting account is ready.

Confirm the destination account. Make sure the account and the domain you expect to restore to are present on the new server, and open Installatron from that account rather than from a different reseller or administrator context.
Use only the original Installatron archive. Keep the archive intact. A general hosting-panel backup, an extracted folder, or a hand-made site archive will not become an Installatron My Backups entry through this process.
Place the archive in the account backup storage. Use the host-approved transfer method to put the archive in the destination account’s ~/application_backups/ folder. Keep it outside the public web directory and do not change its contents while copying.
Reload My Backups. Return to the destination account’s Installatron screen and reload the My Backups tab. Look for the application identity, original location, backup date, and size that match the archive you moved.
Test before relying on it. Use a staging or otherwise approved low-risk destination for the first restore when possible, then confirm the WordPress login, front page, media, forms, and business-critical path.

If your host uses a different account layout or prevents direct access to that folder, do not guess at another server path. Give the host the destination account, application URL, and backup date and ask it to place the valid archive in the account’s Installatron backup location, then have you reload My Backups.

Path 2: Use a host-managed or remote backup location

Use this path when a customer changes hosts, moves to a new cPanel or DirectAdmin server, or needs a small number of existing backups recognized on a new server.

Confirm the archive type. It must be an archive originally created by Installatron, not a generic account backup or a hand-made site archive.
Prepare an approved destination location. In Installatron, backups can be held in the account’s backup area or in a configured remote backup location. The destination host should choose the location that matches its retention and access policy.
Transfer the existing archives securely. Keep the backup associated with its intended destination account and avoid changing the source until the destination is verified.
Request an Installatron backup import. An Installatron administrator uses the product’s Import Backup workflow to register eligible archives from the selected backup location. This registration is the step that allows a backup to show in My Backups.
Verify the inventory. Sign in to the destination panel, open My Backups, and check the application identity, backup date, and ownership before relying on the entry.

The official Installatron backup-import reference confirms that a valid Installatron-created archive in the selected backup location can be imported back into My Backups. If your hosting panel does not expose that action to account users, your host’s Installatron administrator should perform it for you.

Path 3: Reconnect remote backup storage

Remote storage can make a cross-server move simpler, but it still needs a destination-side review. The destination host should configure the same approved remote backup location, confirm that it can access the expected data, and register only the archives that belong to the destination account.

Do not assume that adding a remote location immediately repopulates every account’s history. In the Installatron administration UI, backup locations and their refresh controls are separate from the My Backups inventory. A refresh can confirm that a location is reachable; importing or registering an eligible archive is what makes it available to restore for the appropriate account.

Why a backup may still be missing

When an archive is present but absent from My Backups, work through these checks with the destination host:

The archive was copied but never registered. Ask for the Import Backup workflow to be completed from the configured backup location.
The archive is not an Installatron-created backup. General account archives and manually created site archives need a different recovery plan.
The backup belongs to another account. Verify the destination account and application before any import is attempted.
A live-site import was completed instead. The destination application may be tracked even though the historical backup entries were not brought across.
A full server transfer was incomplete. If many accounts lost their backup lists after a server replacement, the administrator should revisit the official service-transfer process instead of importing archives one at a time.

Restore safely after the backup appears

Seeing a backup in My Backups is the checkpoint, not the end of the migration. Installatron restores can replace the files and database tables at the selected destination. Read the restore target carefully and use a staging site, a new migration target, or a clearly approved maintenance window for the first test.

Confirm the destination URL and account before selecting Restore.
Use a non-production or low-risk target for the first verification when possible.
After the restore, test the WordPress login, front page, media, forms, and the part of the site that matters most to the business.
Verify that the destination server’s ongoing backup policy is enabled and that future backups appear in My Backups.
Keep the original source backup until the restored site and the destination inventory have both been accepted.

For the detailed restore screen and overwrite cautions, see How to Restore WordPress by Installatron. For a broader cutover sequence that includes DNS and email checks, use the WordPress migration, DNS, and email cutover checklist.

What to send your new host or server administrator

A concise, safe handoff helps the destination team complete the right operation without exchanging passwords or exposing archive contents. Provide the destination account, the relevant application URL, the backup dates you need retained, the backup-location type, and a note that the request is to make valid Installatron backups appear in My Backups. Include any error wording from the panel, but do not send archive contents, access credentials, or public links to backup files.