❯ Compare
Three ways to do the same job.
Workflows rather than products. Naming other people's software ages badly and turns every line into a claim somebody has to defend — and you recognise your own routine faster than you recognise a feature grid.
| The job | By hand | With a migration plugin | With cwp |
|---|---|---|---|
| Getting production onto your machine | Export, download, import, search-replace, remember the uploads. | One click, and an archive that contains the customer data too. | One command, scrubbed on the way in, uploads left on the server. |
| Sending a change back up | Whatever you remember to copy, in whatever order. | Usually the whole site, database included. | Only the tracked paths, only with a committed source, only after a restore point. |
| Finding out what changed three weeks ago | A backup, a container and a database. | A log of migrations, if it kept one. | git log. |
| Stopping the wrong environment | Reading the prompt before pressing return. | A confirmation dialog you have clicked a hundred times. | A refusal you cannot configure away, and an exit code that says so. |
| Letting an agent do the work | Same risks, faster, more often. | Not designed for it. | The agent works on a copy; the way up is a diff you read. |
| Your local site emailing a customer | Whatever the last person configured. | Whatever the archive brought with it. | Impossible — the guard is installed on every pull and asserted afterwards. |
Where the other two are the right answer
By hand is right when you are doing it once. Setting up a project to move a site you will never touch again is work you do not get back.
A migration plugin is right when the whole site is the unit — a host move, a domain change, handing a finished project to someone else. cwp moves parts of a site repeatedly and deliberately; that is a different job, and it is worse at this one.
cwp is right when the same site keeps changing, in more than one place, and somebody has to be able to say afterwards what changed and why.