A marketing campaign changes many live systems at once. A landing page, an ad, an email and a pricing table all go live within hours of each other. Most teams check them by hand, from memory, and find the mismatch after a customer does.
Software teams faced the same problem and solved it with a discipline called release management. This guide explains what that discipline is, how each part translates to marketing, and where the translation stops.
What release management means in software
Release management is the set of rules for how a change reaches production. It answers four questions. What exactly is changing? Who reviewed it? Did it pass its checks? What do we do if it is wrong?
Engineers answer those questions with four practices: version control, code review, automated testing and rollback. Each practice exists because the cost of a bad change is higher once it is live. Together they turn a release from an act of hope into a routine with evidence.
Marketing has the same exposure. The difference is that nobody wrote the routine down. The practices below are the ones worth copying.
Version control: know exactly what changed
In software, every change is stored with its author, its date and the version before it. Anyone can see what the system looked like last Tuesday.
For a campaign, the equivalent is a record of every asset and every edit. The ad copy, the page headline, the offer terms and the tracking parameters each have a current state and a history. When results move, the first question is what changed. Without a record, the team reconstructs the answer from screenshots and chat threads.
The term for this in marketing is version control. It does not require new tooling to start. It requires one place where the approved version of each asset is named.
Review: a named person signs off before anything goes live
Code review means a second person reads a change before it merges. The reviewer is named, and the decision is attached to the change.
Marketing review usually happens in a chat message or a comment on a document. The approval exists, but it is hard to find and easy to dispute. A better routine names the approver, fixes the order of approvals and freezes the work once it is submitted, so the thing approved is the thing that ships.
Launch uses two approvals in a fixed order: brand, then legal. A committed launch is read only for everyone except the current approver. See the approval workflow entry for the general pattern.
Testing: evidence that the campaign is ready
Software teams run automated tests before every release. A test either passes or fails, and a failing test blocks the release.
The marketing version is a preflight: a set of requirements checked against the live assets before anything goes live. Do the prices agree everywhere they appear? Does the conversion tag fire? Do the UTM parameters match the plan? Has every claim been reviewed?
The important property is that a person cannot mark a requirement complete. The system evaluates it. That is the difference between a checklist and a check. Launch's Preflight evaluates 21 requirements in six groups, and a blocking requirement holds the launch. The marketing launch checklist lists the questions worth asking before you automate any of them.
Rollback: a plan for being wrong
Engineers keep the previous version ready, so a bad release can be undone in one step. Marketing rarely has this. When a wrong price goes live, someone hunts for the original copy and edits five systems in whatever order they remember.
The marketing term is rollback, and the practical version is simple. Before go live, record the previous state of every asset that changes. Decide who has authority to revert. Write down the order in which the systems are reverted.
The record: what happened, who did it and when
Every mature release process ends with a log. It shows each change, who made it and when. The log is what makes a post-mortem short and a compliance review possible.
Launch writes every action to an append only log with the actor and a timestamp. No module can edit an entry, and the minimum retention is two years. Read more in Logs.
Where the analogy stops
Marketing releases differ from software releases in three ways. The assets live in many separate systems, so there is no single repository to version. Copy and offers change for commercial reasons on short notice. And some of the reviewers, legal above all, are outside the marketing team.
These differences argue for the practices, not against them. The more systems and reviewers a release touches, the more it needs a shared record and a check that does not depend on one person's memory.
For the longer argument, read why marketing never got a release process. For the general term, see marketing release management.
A first step this week
Pick your next campaign and write down four things. List every place the offer appears. Name the person who approves it. Record the current state of each asset. Decide who can revert it and in what order.
That page is a release process in outline. It will show you where your team relies on memory. The second guide in this pair, why price parity breaks, shows one of those gaps in detail.