Journey versions, publishing and live edits

What it does

Live journeys can be edited without being stopped. Small changes apply to the running journey; anything that changes the customer experience creates a new version, and from then on new entrants get the new version while people already in flight finish on the old one.

Key facts

Lightweight edits — renaming the journey, adjusting the goal percentage, and similar non-impactful changes — are applied to the running journey with no new version.
Major edits create a version automatically. These include swapping an email, adding or removing a channel, adding or changing branch conditions, and deleting content from the flow.
Existing customers stay on the version they entered. Only new entrants get the new version.
Each version keeps its own analytics, so you can compare versions rather than having results merged.
Editing is available for trigger-based journeys, long-running journeys, and one-time journeys scheduled to start in the future.
Editing is not available for a one-time journey that is already running, or one scheduled to start imminently — the Edit button simply isn't there.
Publishing is blocked unless every piece of content in the journey is in "Ready to send" state, and any custom trigger used must be published and integrated.
Stopping a journey is per version. A journey with three versions needs three stops, and stopping cannot be undone.
Change tracking and comments are available on edits, giving an audit trail of who changed what.
Outbound marketing was removed from all environments in May 2026, so there is no legacy journey designer to fall back on — real-time journeys is the product.

When to use / skip

Versioning is not something you opt into, so the real skill is deciding whether to edit at all. For copy fixes inside an email, edit the email — there is separate support for editing email components in a live journey, and it avoids a version entirely. For a typo in a subject line, that is the whole answer.

Create a new version deliberately when the treatment genuinely changes: a new channel, different branching, a replaced message. Accept that you now have two populations receiving different experiences and that your reporting has to account for it.

What to avoid is iterating on a live journey the way you would iterate on a draft. Five versions of a long-running journey means five in-flight populations, five sets of analytics, and five things to stop. If the design is still moving, stop the journey, fix it properly, and republish once.

Configuration decisions

Whether a change is worth a version, or whether the edit belongs in the content asset instead.
Whether the journey should be stopped and replaced rather than versioned, particularly for long-running journeys with big in-flight populations.
How versions map to the client's change control — who approves a republish of a live journey, and does it need the same sign-off as the original.
What the approval workflow looks like before publish, since journey approvals can be built as a customisation of the designer rather than a manual process.
How journeys are promoted between environments and whether journeys are built in production by the marketing team or shipped in solutions.
Naming and documentation, so version 4 of "Nurture 2026" is identifiable six months later.

Gotchas

People in flight keep the old logic, including old branch conditions and old exit criteria. A fix you published to stop a problem does not help anyone already inside the journey.
Multiple versions each need stopping individually. Stopping the one you can see and assuming the journey has halted is a genuine incident waiting to happen.
One-time journeys already running cannot be edited at all. If the send is wrong, the only lever is Stop, which is irreversible.
Content must be Ready to send before publish. On a large journey the block is easy to hit and the offending asset is not always obvious from the error.
A custom trigger that has not yet fired anywhere will block publish, because it is not in a usable state. Developers need to have exercised it first.
Analytics split by version, so campaign-level numbers need aggregating manually if a journey has been versioned mid-flight.
Republishing to change a setting such as frequency cap exemption is still a republish, with all the version consequences that carries.

Consultant notes

Set the expectation early that a live journey is not a document. Marketers who came from a batch email tool assume edits apply retroactively to everyone; they do not.
Demo the version behaviour with a two-population example before go-live, so the first real version change is not the first time anyone sees it.
Agree a change-control rule with the client: content edits are business as usual, structural edits go through the same approval as the original build.
Before go-live, check the journey's content is all Ready to send and every trigger is live — build that into the release checklist rather than discovering it at publish time.
Keep a written record of why each version exists. Analytics will show you the split; only your notes will explain it.

Worth revisiting if Microsoft adds a way to migrate in-flight customers between journey versions.