Moving Between Staging And Production

Most real sites live twice: a production site visitors see and a staging or local copy where changes are tried first. Canvas is built for that workflow. This page explains how a development environment is recognised, what that means for your license seats, and the right moves for the two directions of travel: copying production down to staging, and promoting a site up to a live address.

How Canvas Recognises A Development Environment

Canvas classifies the site by its address. localhost, 127.0.0.1, addresses ending in .local, .test, .dev or .localhost, and hostnames carrying markers such as staging., dev. or stage., along with the domains of common local development tools, are treated as development environments. The Canvas > License screen shows the verdict in its Environment row, as Local / Dev or Production, so you never have to guess how a given copy is being counted.

The consequence that matters: a development environment does not count against your plan's site allowance. Activate your license on as many staging and local copies as your workflow needs, and only the production sites consume seats. The Canvas service keeps the authoritative list of recognised patterns, so newly popular hosting providers' staging domains are recognised without a Canvas update.

Copying Production Down To Staging

Copy the site however you normally do, files and database together, and let the copy come up on its staging address. The license comes along in the copied database, the copy is recognised as a development environment, and no seat is spent. If the License screen on the copy warns that the licensed domain differs from the address the site is running on, that is an accurate description of a staging copy and safe to leave as it is; production remains the licensed home of that activation.

Promoting A Site To A New Address

When a site genuinely moves, staging promoted to live, a domain rename, or a host migration with a new address, the activation should move with it. Canvas handles most of this itself: on your next visit to the WordPress admin it detects that the site's address no longer matches the licensed one and migrates the activation automatically.

When the automatic move cannot complete, you get two manual handles, and either one finishes the job:

  • An admin notice reports that the site domain has changed, with a Re-activate Now button.
  • The Canvas > License screen shows which domain the license was activated on and which one the site is running on now, with a Migrate License button.

A migration moves the activation, it does not create a second one, and the screen records the move in a "Moved to this domain" row while keeping the original activation date. If the old site also stays live as its own website, that is not a migration: leave its activation alone and activate the new site with the same key as an additional seat.

Pitfalls

A staging copy is consuming a seat. Recognition is by hostname, and a staging site on an ordinary looking address (a plain subdomain with no development marker) reads as production. Check the Environment row on Canvas > License; if it says Production and the copy is disposable, select Deactivate there when you are done, which frees the seat.

"Migration failed. Please re-activate your license." The service refused or could not complete the move. Select Deactivate on the License screen and then activate the key again on the new address, which achieves the same end state.

The staging copy shows a domain warning forever. Expected, and harmless: the copy carries production's licensed domain in its copied database. Migrate only if this copy is about to become the live site.

Was this page helpful?