Marketing Workflow Versioning: Roll Out v2 Without Breaking v1

You changed the routing rules on Thursday. On Monday a lead who was mid-sequence never got a call, another lead got two, and the report that compared this month to last month is no longer comparing the same workflow. That is what a new version does when it replaces the old one in place. Versioning means the new path runs beside the old one, on a slice of new leads, until you can show it is better. Then you retire the old path after the leads already in it have finished.

The measurement problem underneath that is the one Harvard Business Review described in April 2022: a metric that changes definition midstream stops being a picture of the business. A workflow replaced rather than versioned does the same thing to your baseline. The orchestration frame is how a buyer path is supposed to move.

What breaks when you push a new version with no plan?

Leads already inside the old path lose their next step, because the trigger they were waiting on now points somewhere else. New leads can enter both paths if the entry rule is not exclusive, so they get two messages or two scores. Reporting mixes the two populations and calls the blend an improvement. The pipeline dip people blame on "the change" is often just a broken comparison. None of that requires a bad model. It requires two versions sharing one set of leads.

A version change hits three things at once if you do not separate them. The logic that processes leads who enter after the change. The status of leads already inside the path. The attribution attached to every lead the path has ever touched. A planned rollout isolates the three. An unplanned cutover hits all three on the same night, and the Monday report cannot tell a demand change from a definition change.

Replacing the path rewrites how old leads are attributed.

The most common break is an attribution reset. When a workflow is replaced rather than versioned, the structure that says how a lead entered and progressed is the old path's fields. The new path may use different field names, different stage labels, or a different set of triggers. A lead that was attributed to a named campaign under version one may be re-attributed under version two's rules, or may lose the attribution entirely when version one is turned off. The campaign did not stop working. The field that proved it did was retired with the path. Harvard Business Review makes the comparison point directly: a before-and-after number is only defensible if the metric kept its definition across the change.

A new score model changes leads who are already mid-path.

If version two includes a rebuilt scoring model, leads currently in version one get re-scored under the new criteria the moment they enter the new system. A lead who was warm under version one may score cold under version two, and the reverse happens just as often. The person who was about to call a hot lead now sees a cold one. The weekly pipeline report shows a coverage gap. The gap is a scoring recalibration, not a demand problem, and it will be explained as demand unless the two scores are stored side by side until the parallel run ends.

The first 48 hours can leave in-flight leads with no path at all.

An unplanned cutover orphans leads who are mid-path. Version one is turned off before they finish, and version two has no way to pick up a contact who is already halfway through. The first 48 hours are the window where no path reliably handles that tail. Messages that should have fired do not. The next step the lead was waiting on has no trigger left to fire it. This window is the usual source of the pipeline dip that follows a workflow change, and it is avoidable: leave version one running for every lead already inside it, and let version two take only leads who have not entered yet.

How do you know version two is ready to run beside version one?

Ready is not the same as better. Ready means version two can process leads correctly on its own. Three things have to be true. It has been tested on a held-out set of historical leads with known outcomes, and the output matches what those leads actually experienced. Its trigger map is written down: every entry, every branch, every ending, including what happens when validation fails. Its field contract is signed off, including what it does when a field is missing. The contract itself is in the handoff contract.

Sign-off is not a meeting note that says "looks good." Every system that reads the output has to agree: the CRM, the sequence tool the sales team works from, and any report that reads the fields the workflow writes. If the report still expects version one's stage label, version two is not ready, even if the routing logic is right. A parallel run that writes a new label into an old report will look like a drop on the day it starts.

Freeze four numbers before anyone changes a trigger.

Before the parallel run, freeze version one's numbers for the same window you plan to use later, usually 30 days. Capture weekly lead volume, average and peak. Capture the share of leads that reach the sales step with the required CRM fields filled. Capture median time to the first sales touch. Capture the score-to-meeting rate, from scored leads to booked calls, and the share of closed-won deals with a traceable touch. If reporting cannot produce those four from version one today, fix the measurement before you version anything. A gap in version one will be blamed on version two.

Those four numbers are the control. Volume will move with demand during the parallel run, so you do not use volume to decide whether version two is better. You use it to notice whether the canary slice is large enough to read. The other three, field completion, time to first touch, and score-to-meeting, plus attribution coverage on closed-won deals, are the capability numbers. Write them down with the date you froze them. A number you reconstruct from memory after version two is live is not a baseline.

How do you run both versions without processing a lead twice?

Route a controlled share of new leads to version two. Leave every lead already in version one on version one until that instance ends. No lead is in both.

For a first parallel run, 10 to 20% of new leads is the canary. Make the split deterministic, not random. The last digit of the CRM id is enough, so the same lead always lands on the same version. Random routing creates false variance, including a lead that exits version one and re-enters version two on the next form fill.

Two rules keep one lead on one version.

Two rules, enforced by the platform. Any lead that has entered version one stays there for the life of that instance, however long the parallel run lasts. A new lead that enters version two is flagged as version two immediately, before scoring or routing runs. That flag is how you separate the two populations in the report.

Enforced by the platform means the rule is a branch in the workflow, not a convention the team remembers. A convention fails on the first Friday someone imports a list, or on the first form that writes a lead without passing through the entry node you documented. The flag has to be written before scoring, because a score computed and then labeled is a score you can no longer attribute to a version. If the report cannot filter on the flag, you do not have two populations. You have one blended population and a story about which version produced it.

A 15% slice at 200 leads a week is about 64 leads in 15 days.

Take 200 new leads a week as a worked example. A 15% canary is 30 leads a week. Over 15 days that is about 64 leads, because 15 divided by 7, times 30, is about 64. The arithmetic is illustrative, not a client result. If you need a larger read, extend the window. Do not widen the canary before version two has been shown to behave at the smaller slice.

How do you move active leads from version one to version two?

Leads already in version one should generally stay until they reach an ending: a booked call, a disqualification, or an age-out. The exception is a lead that has sat longer than the path's designed maximum, often 30 to 45 days depending on the sales cycle. Those can enter version two's logic as if they were new, and only if you have written the fallback for fields version one never captured.

Leads in the first half of version one stay. Leads past scoring and not yet at the sales touch can move if version two's handling of that stage has been tested. If version two requires a field version one did not collect, every such field needs a default, and you need to know whether that default changes the score the rep will see. Write the mapping before any batch moves. An example: version one's free-text stage "MQL" maps to version two's cold, warm, or hot band. Warm if the lead entered version one within 30 days, cold otherwise, and cold is the fallback. A table like that has to exist for every field the two versions captured differently.

Every field version two requires needs a fallback for leads version one already holds.

Migrated leads arrive missing whatever version one never asked for. Before any batch moves, write the fallback in a table: the version-one field, the version-two field, the rule, and the value you use when the rule cannot decide. The sales person who receives the lead has to know when a score was computed on a fallback rather than on a captured value. A warm band that means "entered within 30 days" is a different fact from a warm band that means "the model scored them warm," and the note on the contact should say which one it is.

The second row is the one teams skip, and it is the one that corrupts the score. Writing zero looks like a small company. Leaving the field blank and naming the reason keeps version two from treating a migration gap as a fact about the lead. The table is an operating frame, illustrative and not a client result. Build the same four columns for every field the two versions captured differently, and do not run the batch until the table is finished.

How do you tell whether version two is actually better?

Compare the four frozen numbers to the same four on the canary, over the same calendar window. Volume moves with demand. The capability numbers tell you whether the workflow is doing its job: field completion at the sales step, score-to-meeting rate, time to first sales touch, and attribution coverage on closed-won deals.

Volume alone cannot separate a better workflow from a better month. A canary that books more meetings during a trade-show week has not proved the path. That is why the comparison uses the same calendar window for both versions, and why the capability numbers, not the lead count, decide the cutover. Which of those numbers matters most depends on the path, and what to track across the first 90 days is in AI agent performance metrics.

The window has to cover a real sales cycle.

The window has to cover a real cycle. If the median time to closed-won is 45 days, a 30-day window will undercount attribution. Use 30 days as the minimum for lead-to-sales-touch metrics, and 60 days if you want pipeline influence in the decision. IBM's Institute for Business Value study of agentic workflow adoption (n=2,500) found that orchestration evaluated at 30 days showed 40% less measured impact than the same systems evaluated at 90 days, because the compounding had not shown up yet.

Read that 40% as a reason to wait, not as a reason to declare version two a failure at day 30. A path whose value shows up as a second meeting, or as a closed-won deal with a traceable touch, cannot finish that story inside a window shorter than the cycle. If you must decide earlier, decide only on the metrics that can move inside 30 days, such as field completion and time to first sales touch, and say in the log that attribution coverage was not in the decision.

Write the go or no-go rule before you see the numbers.

Set the go or no-go rule before you see the results. A workable minimum for retiring version one: version two improves at least 10% on two of the four capability metrics, and no metric falls more than 5% relative to version one. If it wins on three and loses on one, investigate the loss before a full cutover. A path that improves the sales handoff and quietly reduces attribution is not an improvement until you know why.

Writing the rule first is what keeps a disappointing metric from being redefined after the fact. If attribution coverage falls 12% and the rule says 5% is the most you will accept, the cutover waits. You do not get to call attribution "less important than we thought" in the same meeting where you read the drop. The 10% and 5% figures are an operating frame, illustrative and not a client result. Replace them with your own thresholds before the run starts, and then leave them alone until the window closes.

When is it safe to retire version one?

Two conditions. The threshold above is met and written down. No active leads remain in version one. The second is the one teams skip. A workflow turned off with leads still inside it does not finish them. The trigger fired, the path started, and the ending never runs.

Query the CRM for any lead with a version-one instance that is not at an ending. The off date has to be at least one full dwell time after the last version-one entry. If the last lead entered on 28 July and the dwell time is 30 days, version one cannot safely turn off before 27 August.

Five checks come before the old path turns off.

Five checks before you turn it off. The evaluation threshold is met and documented. Every active version-one lead is at an ending or has been moved with a written fallback. Version two is taking 100% of new leads. Reporting treats the two populations consistently in attribution. The sales team has been told about any scoring or routing change that affects which leads they work first. Who owns that briefing is in the cutover playbook.

Work the list in that order. Turning on 100% of new leads before the threshold is documented is how a canary becomes a cutover by accident. Briefing the sales team last means the first morning of full traffic is also the morning they learn the score means something new. The owner of the path is the person who can say all five are true, with a date next to each. If nobody can say the fifth one, version one stays on.

Keep version one for at least 90 days after you turn it off.

Do not delete version one. Archive the trigger map, the field contract, and the performance snapshot, for example as a version-stamped note dated the day you froze it. A concrete name is enough, such as a note titled with the path, the version, and the freeze date. Keep it at least 90 days. If version two underperforms in month two, the archive is the control that tells you whether you have a regression or a demand shift.

The archive is also how you answer the question that shows up six weeks later: what did this lead's score mean on the day it was assigned? Version two's current model cannot answer that if version one's model was deleted. Ninety days covers a typical second look at the monthly report. Longer is reasonable if your closed-won cycle is longer than that. Shorter means you will be reconstructing the old path from memory the first time the numbers move the wrong way.

How do you document version two so version three takes hours, not weeks?

Three artifacts. The trigger map lists every entry, every branch, and every ending. The field contract lists every field the workflow reads, what it expects, and what it does when the field is missing or invalid. The version log records what changed, why, and who owns it.

A version log entry has four fields, and the why is one sentence.

A log entry has four fields: the version, the date, the owner's name, and a change summary in two parts. What changed, at the field level, not "rebuilt the workflow." Why it changed, as the specific failure in version one. If you cannot say why version one was replaced in one sentence, the replacement is not ready. The owner is the named person in the human handoff rules, not a shared inbox. A dated entry that says "version two, 31 July, named owner, company size is now an integer because version one stored the word large and scoring ignored it" is a finished entry. "Rebuilt routing" is not.

The useful page is the difference between the two trigger maps.

The most useful artifact is the difference between the two trigger maps, not version two's map alone. The difference shows which branches were added, removed, or changed, so a new person can see the history without reading the whole archive. For a path that passes fields between systems, the difference should include the contract comparison from the handoff contract: which fields version two now requires, which fallbacks changed, and which failure branch is new.

Every log entry should include the handoff: the fields passed to the next system, the format of each, and the acceptable blank rate. An example: utm_source may be blank for up to 8% of leads, and above that the form capture is broken. That threshold is how the next owner notices field decay before it becomes a revenue surprise. The 8% figure is an operating example, illustrative and not a client result. Set the rate from version one's frozen baseline, and write the number you will treat as broken.

With those three artifacts in place, the next version is a structured edit. A team running one routing path can expect the first rollout to take on the order of two weeks, and a later rollout to take a few hours, once the map, the contract, and the log already exist. That timing is an operating frame, illustrative and not a client result. It assumes the baseline was frozen before the work started. It does not assume a particular tool.

How does versioning connect to return over time?

BCG's 2025 research on the AI value gap (n=1,000 or more) found that 4% of companies create substantial value from AI while 60% report little or no impact. The difference is not which tools they bought. It is whether they protect the measurement baseline when systems change. Replacing a workflow resets the baseline. Versioning it adds a data point you can compare. That is the operational practice the 4% have and the 60% do not.

The protocol in this post is the readiness check, the frozen baseline, the canary, the migration table, the evaluation rule, and the retirement checks. None of those is a model upgrade. Together they are how a before-and-after survives the next change, so the conversation about the path can start from the four numbers you froze rather than from a blended month. When version two wins, route to it for new leads only, and leave the leads already inside version one there until they finish. If you are about to ship a second version of a path that already books meetings, get your free Systems Plan. We will freeze the four numbers before anyone turns the old trigger off.

How we know this.

Harvard Business Review, April 2022, "Do Your Marketing Metrics Show You the Full Picture?", is the source for keeping a metric's definition stable across a change. IBM Institute for Business Value, n=2,500, is the source for orchestration measured at 30 days showing 40% less impact than the same systems measured at 90 days. BCG, 2025, n=1,000 or more, is the source for 4% creating substantial value and 60% reporting little or no impact. The canary percentages, the 10% and 5% go or no-go rule, the 8% blank-rate example, the two-week and few-hour rollout frame, and the 200-leads-a-week arithmetic are an operating frame. At 30 leads a week, 15 days is about 64 leads (15 divided by 7, times 30). That example is illustrative, not a client result.