Cloning and moving a site

Sooner or later you'll want a copy of a site to experiment on, or you'll want to move a site onto a newer Drupal, or give it a new domain. Your control panel has two tasks for exactly this, and the whole trick to using them safely is knowing which one does what. This page walks you through both, plus a couple of speed switches you can flip from your own shell if you ever need to.

Everything here happens in the Aegir control panel (the web UI you log into) — you click a button, a task runs in the background, and your files come along automatically. There's nothing to copy by hand.

Clone or Migrate Site — which one?

These are the two tasks, and they're easy to mix up. Keep them straight:

Clone makes a full copy of a site under a new domain, on the same platform. Use it when you want a second copy to play with — a staging copy, a sandbox, a "let me try this upgrade on a throwaway first" copy.
Migrate Site moves an existing site to a different platform (for example, a newer Drupal build), or renames it to a different domain. The site doesn't get duplicated — it's the same site, now living somewhere new.

The one rule that saves you the most grief: change only one thing at a time. Don't clone and switch platforms in the same step, and don't move to a new platform and a new domain in the same step. The control panel itself tells you this right on the Clone and Migrate forms — it's the single most common way people get into trouble.

When you want to land a site on a newer platform safely, the recommended path is:

Clone the site on its current platform, so you have a copy to test with.
Migrate that copy onto the new platform.
Check the migrated copy works exactly as expected.
Only then migrate your live site.

Cloning a site (making a copy)

Cloning is how you get a staging copy, or a sandbox to try something risky. The copy is complete and independent — its own database, its own files, its own everything. Changing the clone never touches the original.

To clone a site:

Open the site in your control panel.
In the row of tasks, choose Clone.
In Domain name, type the new domain for the copy (for example, staging.example.com). This is the address the copy will answer on.
Submit.

The task queues, and you'll watch it run in the site's task log. When it finishes, the copy exists on the same platform as the original, with all your content and all your uploaded files carried across automatically. You don't restore anything or copy files yourself — the clone task takes a fresh backup of the source behind the scenes and builds the copy from it.

A couple of things worth knowing about the fresh copy:

HTTPS doesn't carry over. A certificate belongs to one exact domain name, so the copy starts without HTTPS on its new domain. Turn it on for the new domain the same way you did for the original — that's covered in its own topic, HTTPS for your sites.
It's a real, live site. If your clone is only meant for testing, remember it's reachable like any other site. Give it an obvious staging-style domain, and if you want it private, you can Disable it from the task list when you're not using it.

Moving a site with Migrate Site

Migrate Site does two related jobs, and you pick which by what you change on the form:

Move to a newer platform. When a newer Drupal build is available to you as a platform, migrating is how you move your site onto it. You choose the target under Platform and leave the domain alone.
Rename, or promote a copy to live. Changing the Domain name during a migrate effectively renames the site. This is how you promote a dev or staging copy to your live domain: you migrate staging.example.com and set its Domain name to your real domain.

To migrate a site:

Open the site in your control panel.
In the row of tasks, choose Migrate Site.
Change one of these — and only one:
- Platform — pick the target platform from the list to move onto newer code.
- Domain name — type a new domain to rename the site.
Submit.

The form won't let you migrate without changing at least one of Platform, Domain name, or Database server, and it asks you not to change the platform and the domain at the same time. As with cloning, your content and uploaded files move with the site automatically — there's nothing to copy across by hand.

Migrating takes the site briefly offline while it moves, then brings it back. Expect anything from a few seconds to a few minutes depending on how big the site is.

After a rename, HTTPS needs re-doing. A certificate is tied to one exact domain, so when a migrate changes your domain the system turns HTTPS off on the renamed site for you — that's deliberate, because the old certificate isn't valid for the new name. Set it up again for the new domain and you're covered — see HTTPS for your sites.

The safe way to move onto a newer Drupal

Putting the two tasks together, here's the pattern the control panel recommends and the one that keeps you out of trouble:

Clone your live site (keeps its current platform, gives you a copy under a staging domain).
Migrate the clone onto the new platform.
Open the migrated clone and check it thoroughly — content, layout, the things your site actually does.
Happy? Now Migrate your live site onto the new platform too.

You never experiment on your live site, and you find any surprises on the copy first.

Speed switches (optional, from your own shell)

By default, cloning and migrating are already fast, and they run some safety checks first. If you're doing a lot of these — say a bulk of copies — you can turn on two optional switches that trade a little safety, or a little convenience, for speed. These are small control files you create in your own shell (or over SFTP). They live under your account's static/control/ folder, and creating one is all it takes — the file's contents don't matter.

You don't need these for everyday use. Reach for them only if the default speed isn't enough for what you're doing.

FastTrack — skip the pre-flight checks

Before each clone or migrate, the system normally verifies the site and the platforms involved, to catch problems before they can break the job. That's the safe default, and it's what you want for a one-off.

If you're running many clones or migrates back to back and don't want those checks repeated every single time, create this file:

~/static/control/FastTrack.info

With it in place, the site and platform verifications are skipped, so each job starts sooner. The trade-off is real: those checks exist to catch a broken setting or a missing module early, before it can leave a copy half-built. Skip them only when you've already confirmed everything is healthy and you're doing this in bulk.

To go back to the safe default, deleting FastTrack.info on its own isn't enough — you also create an empty ClassicTrack.info to switch the pre-flight checks back on. Two steps, in your shell:

touch ~/static/control/ClassicTrack.info
rm ~/static/control/FastTrack.info

The ClassicTrack.info file is what restores the "verify first" behaviour; the system treats it as the on-switch for those extra checks.

MyQuick — parallel database copy

By default, the system already uses a fast, parallel per-table method to copy your database during clone and migrate — so large, complex databases finish in minutes rather than hours. This is on for you out of the box, and there's nothing to switch on.

There's one thing to be aware of. Because of how this fast method packages things, the on-demand Restore task in the control panel needs the older, single-file database format inside a site's backup archive — and the fast method doesn't put one there. In practice this doesn't affect your safety net: the system keeps separate nightly backups of every site regardless.

If you specifically want a fresh backup you can Restore from, you almost never need to touch anything account-wide. When you run the Backup task on a site, the form offers a Backup Mode with three choices:

Classic single file mysqldump only — just the database, in the classic single file.
Site files without any DB — your files, no database.
Site files with classic mysqldump DB — files and a classic single-file database.

Only that last one, Site files with classic mysqldump DB, produces an archive the Restore task can use — and choosing it makes just that one backup bypass the fast method, without changing anything else. So the simplest way to get a restore-ready backup is: run Backup, pick Site files with classic mysqldump DB. Everything else stays on the fast default.

If instead you'd rather your account always produce classic, restore-ready backups — say you take a lot of manual backups and don't want to remember the mode each time — you can switch the fast method off for the whole account by creating:

~/static/control/MyClassic.info

With that file present, backups go back to including the single-file database dump the Restore task expects — at the cost of slower clone, migrate and backup times on large databases. Remove the file to return to the fast default:

rm ~/static/control/MyClassic.info

If none of this sounds like something you need, it isn't — leave both alone, pick the right Backup Mode on the rare occasion you need a restore, and everything just works.

Moving a site to a different server

Everything above keeps a site on the same server. Moving a site (or your whole account) to a different server is a different job, and it's not one you do from your control panel or your shell — it needs server access you don't have. This is something your host or operator handles. If you need it, open a support request and say where the site is going.

Where to go next

New to how sites and platforms fit together? Start with Sites, platforms and clients.
Everyday jobs on a single site — Verify, Backup, Restore, Disable/Enable — are in Everyday site tasks. It's worth running Verify Site on a clone or a migrated site once it lands, just to confirm it's happy.
Turning HTTPS on for a copied or renamed site is covered in its own topic, HTTPS for your sites.
The full list of control files you can create in your account, with exact names, lives in the shared Reference.