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. If you ever run a lot of these and need extra speed, two optional switches you can flip from your own shell have their own page — Faster cloning and migration.

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.

Strictly speaking, the Clone form does let you pick a different platform for the copy — a Clone and a Migrate in a single step. The form itself advises against it, and so does this guide: it changes two things at once, and a failed attempt leaves half-built leftovers right next to your production site. The supported route is the two-step: Clone on the site's current platform first, then Migrate the copy to the new platform. The shortcut isn't blocked — but if it goes wrong, the cleanup is yours. 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, dev.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 few things worth knowing about the fresh copy:

Scheduled cron is off. A clone deliberately arrives with scheduled cron switched off, so the copy never runs background jobs — or sends anything — behind your back while it sits there as a sandbox. If the copy is meant to live a real life of its own, switch its cron back on — see Scheduled cron for your sites.
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 a recognised test-copy name (next bullet), and if you want it private, you can Disable it from the task list when you're not using it.
The name you pick buys real protection. A handful of labels mark a site as a test copy to the platform itself: dev, devel, test, testing, tmp, temp and temporary — either as the first label of the domain (dev.example.com) or as a whole label between dots inside it (www.dev.example.com). On such a name, anything identifying itself as a search-engine crawler or bot gets a 404 instead of your sandbox, so the copy stays out of search results, and outside pings to the site's cron URL are ignored too. A name like staging.example.com earns none of this. The first-label form has one extra advantage: dev.example.com still gets a real Let's Encrypt certificate when you enable HTTPS later, while a name with the label between dots gets a self-signed placeholder instead — see HTTPS for your sites for that rule and its override.

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 copy to your live domain: you migrate dev.example.com and set its Domain name to your real domain. Mind the order when the copy is taking over from an existing site: no site can take a domain while another site by that name still exists, so first free the name — rename the old live site out of the way, or delete it if you're done with it — and only then rename the copy into place.

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.

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:

Clone your live site (keeps its current platform, gives you a copy under a test-copy domain like dev.example.com).
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.

One pre-flight check before any Migrate: make sure the site has no database updates already pending — from the shell, drush @site-alias updbst lists them, and if it shows any, run them (on the current platform) before you migrate. A Migrate finishes with its own database-update run, and a site that enters the move with updates already queued is the classic way that final step fails half-way through the task.

Faster clone and migrate (in bulk)

Cloning and migrating are already fast, and safe by default. If you run a lot of them and want to trade a little safety or convenience for extra speed, two optional control-file switches — FastTrack (skip the pre-flight verifications) and MyQuick (the parallel per-table database copy, and the classic-dump opt-out the Restore task needs) — have their own page: Faster cloning and migration. You don't need either for everyday use.

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:

Click Compare platforms and find the packages marked as errors — that's your exact list of blockers.
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.
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:

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.
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.
Running these in bulk and want more speed? The two optional switches, FastTrack and MyQuick, are on Faster cloning and migration.
Account control files like the FastTrack.info family are indexed, with exact names and locations, in the shared Control-file reference.