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 Ægir 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:

1. Clone the site on its current platform, so you have a copy to test with.
2. Migrate that copy onto the new platform.
3. Check the migrated copy works exactly as expected.
4. 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:

1. Open the site in your control panel.
2. In the row of tasks, choose Clone.
3. In Domain name, type the new domain for the copy (for example, staging.example.com). This is the address the copy will answer on.
4. 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:

1. Open the site in your control panel.
2. In the row of tasks, choose Migrate Site.
3. 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.
4. 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.

Switching between www and non-www — renaming example.com to www.example.com, or the other way around — is an ordinary one-step rename: type the other variant into Domain name and submit. The form recognises that the name you're renaming to is the site's own automatic www companion (the alias that appears on its own once the name resolves — see Site aliases and redirects) and lets the rename through; when the tasks finish, the companion has flipped to the old spelling, so both variants keep answering, and any other aliases you've added come along untouched. The one case that still gets refused with "The domain name you have specified is not unique or not allowed" is when you'd added that variant yourself as a manual alias — remove it from the site's aliases first, save, and then rename.

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.

If you find yourself renaming the same site over and over — a dev, staging and production cycle, say — bear in mind that each rename disables HTTPS and forces a fresh certificate under the new name. For that kind of back-and-forth it's usually smoother to keep the versions as separate clones and move your live domain between them as an alias than to rename one site again and again, so you're not re-issuing a certificate on every switch.

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:

1. Clone your live site (keeps its current platform, gives you a copy under a staging domain).
2. Migrate the clone onto the new platform.
3. Open the migrated clone and check it thoroughly — content, layout, the things your site actually does.
4. 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.

When a migrate needs a hand

Migrations are designed to be safe: the task checks the ground before it moves anything, and if it fails partway it rolls the site back to where it started. Two situations are still worth knowing about — one where the form stops you before you begin, and one where a failure needs you to finish the recovery by hand.

A target platform is greyed out

On the Migrate form, every candidate platform is listed with a small comparison line — how many of your site's packages would be upgrades on that platform, how many raise warnings (packages missing from the target, or carried there in an older version), and how many are errors — with a Compare platforms link for the details. A platform you can't select — greyed out — means that comparison found at least one error: a module that's enabled on your site exists on the target platform at an older database schema than the one your site's data is already at. Moving there would be a downgrade for that module's data, which is a straight road to corruption, so the panel refuses to offer the platform rather than let you try.

What to do about it:

1. Click Compare platforms and find the packages marked as errors — that's your exact list of blockers.
2. If a flagged module is something you don't actually use, disable and uninstall it in the site, then run Verify Site. Only enabled modules count, so the platform un-greys once Verify has re-read the site's packages.
3. If you do use it, you need a target platform carrying the newer version of that module. On a platform of your own, that's a rebuild with updated code; for a platform your host provides, ask them.

There's one more possibility on older (Drupal 6/7) sites: the recorded number is simply wrong. A module's schema version lives in the site's system table, and a misbehaving update or a module that came and went can leave an inflated value behind — making a perfectly good target look like a downgrade. If you've checked the module's own update history and the target's version really is current, you can correct the schema_version value for that module in the site's system table using the database GUI (see Database GUI), then run Verify Site and reload the Migrate form. Be sure before you edit — this is the one place on this page where you're changing data by hand.

If a failed migrate can't roll itself back

A failed Migrate normally cleans up after itself: the site comes back on its old platform as though nothing happened. On a bad day — a task interrupted at the wrong moment, a server hiccup mid-move — the automatic rollback itself can fail, leaving the site's record in the panel pointing at something broken.

This is exactly the situation the safe pattern at the top of this page exists for. If you kept a clone before migrating — say old.example.com, still sitting untouched on the old platform — the recovery is two steps:

1. Delete the broken site first. Run Delete Site on the failed example.com. This isn't just tidying up: the panel won't let any other site take a domain while a site by that name still exists, so the broken record has to go before the name is free again.
2. Rename the clone into place. Run Migrate Site on old.example.com, keep it on the old platform, and change only its Domain name to example.com. That's the rename move from earlier on this page — your recovery copy becomes the live site again.

Then remember what a clone deliberately ships without: scheduled cron is off (turn it back on — see Scheduled cron for your sites) and HTTPS needs setting up for the recovered domain (HTTPS for your sites).

If you didn't keep a clone, don't improvise — the site's data is still there, and your host can recover from the pre-migrate backup that every migrate takes automatically. Open a support request, name the site and the failed task, and let them restore it.

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.

There is one do-it-yourself exception: taking a complete copy of a site away with your own login — the database, the site's directory, and the codebase — which is covered in Exporting your site. And for the opposite trip, bringing in a site that lived outside the Ægir world entirely, see Importing an existing site.

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.
• Bringing in a site from outside the Ægir world — a standalone Drupal, a local copy — is Importing an existing site; taking a complete copy away is Exporting your site.
• Account control files like this page's FastTrack.info family are indexed, with exact names and locations, in the shared Control-file reference.