Cloning a client's store to staging copies every order, every address and every email on it. Most agencies do this weekly without thinking about it.
Everything that makes agency work on ordinary sites routine becomes a liability once the database holds customers.
Staging copies of a store contain real names, addresses and order history. Customer data is scrubbed as part of cloning rather than left for somebody to remember.
A staging store with live payment keys can take a real payment from a test order. Gateway configuration is kept separate between environments so that cannot happen by accident.
Nobody deploys to a store in late November. Change windows are agreed per client, so the freeze is enforced rather than remembered.
Your clients' busy periods overlap. Capacity is allocated per store so one client's sale is not another client's outage.
Backups and restores are per site, so recovering one client's mistake never involves touching anybody else's.
An agency running client stores is a processor of everybody else's personal data. That is a different position from building brochure sites, and it changes what staging has to do.
Agency risk concentrates because client peaks coincide. The measure is whether twenty stores can all have their best day at once.
The difference from ordinary agency work is that every database you touch belongs to somebody's customers.
| Setting | What we do | Why |
|---|---|---|
| Environment cloning | Customer and order data scrubbed as part of the copy | A staging clone of a store contains real names, addresses and purchase history, and agencies create those weekly without treating them as copies of personal data. |
| Payment configuration | Kept separate per environment with live keys excluded | A staging store carrying production gateway credentials can take a genuine payment from a test order, which is discovered by the customer rather than by you. |
| Deployment freezes | Enforced per client rather than agreed verbally | Nobody intends to deploy during Black Friday, but a freeze that lives in a calendar invite is not a control. |
| Capacity allocation | Per store rather than pooled across clients | Retail peaks coincide, so pooled capacity means every client's best day is also every client's riskiest one. |
| Restore granularity | Per site, never account-wide | Recovering one client's mistake must not put another client's store into a rollback they never asked for. |
Every plan includes free migration, daily backups, SSL and 24/7 support.
Move the client stores across — migration is free, every store included.