Applying Stage Gates to Projects: Merge vs Force

When you use Apply Stage Gates to Projects, Fluid takes your current stage gate setup and rolls it out to every project that matches the filters you chose (methodology, project type, category, start date). Before it does that, you pick an Apply mode: Merge or Force.

This article explains, in plain terms, what each mode does and when to use it.

* Both modes recalculate the project's current phase. Merge normally keeps a project from slipping backwards — except when the project's phases have no dates set, in which case the phase is worked out purely from which gates are still open and can move back. See 'What happens to the project's current phase' section below.

† Don't assume Merge never deletes completed work. A completed step inside a still-running package instance is deleted if that step has been removed from the package design. See 'What happens to stage gate packages' section below.

Merge is the safe, everyday choice. Force is the "start fresh" choice and can remove in-progress work, so use it deliberately.

Merge brings each project into line with your current gate setup without throwing away work that's already underway.

When you run Merge:

• Completed gates and their decision history are preserved. Nothing that has already been signed off is lost.

• New gates are added and changed gates are updated in place.

• Gates that are no longer part of the setup are removed.

• The project's current phase is recalculated, but Merge is designed not to push a project backwards under normal setups. (There is one important exception when the project's phases have no dates — see 'What happens to the project's current phase'.)

• Running package instances are kept and refreshed so they match the latest package definition. See 'What happens to stage gate packages' section below.

Think of Merge as "update everything to match the new design, but leave finished and in-progress work intact."

Use Merge when: you've made a change to your gate or package design and want to roll it out across live projects with minimal disruption. This is the right choice the vast majority of the time.

Force is a "kill and reset". It rebuilds each project's gate structure from your current design and recalculates where the project stands.

When you run Force:

• Completed (closed) gates are still preserved — finished sign-offs are kept.

• Every gate that is not yet complete is cleared and recreated from the current design. Any decision or approval that was in progress on those gates is closed off (process items are archived; decisions are cancelled).

• The project's current phase is fully reset — it is cleared first and then worked out again from scratch against the rebuilt gates (see 'What happens to the project's current phase').

• Running package instances are cleared and rebuilt from scratch, rather than refreshed.

Think of Force as "tear down everything that isn't already finished and rebuild it cleanly from the current design."

Use Force when: a project's gates have become inconsistent or were set up incorrectly, and you want a guaranteed clean copy of the current design. Because it discards in-progress work, treat it as a corrective tool rather than a routine one.

It's a common misunderstanding that Merge leaves the project's phase untouched. It does not — both modes recalculate the current phase after the gates are applied. The difference is how they do it:

• Merge recalculates the phase while still treating the project's existing phase as the starting point, so under a normal setup it won't drag a project backwards.

• Force deliberately clears the phase first and then works it out again from scratch, with no memory of where the project was.

The important exception (Merge): if the project's phases have no dates set, Merge has nothing to anchor the phase to, so it works the phase out purely from which gates are still open. In that situation Merge can move the project's current phase back to the earliest phase that still has incomplete gates (or clear it entirely if nothing is outstanding). So on date-less projects, Merge can change the phase in ways that look like a reset — this is expected behaviour, not a fault.

What to remember: if your projects don't use phase dates, don't assume Merge will leave the current phase where it is. Check the phase after applying, the same as you would with Force.

Stage gate packages need their own explanation, because they behave differently from ordinary gates. A quick reminder of the terms:

• A package is a reusable group of steps defined in your methodology.

• A package instance is a running copy of that package on a project (a project can have more than one).

• The steps inside an instance are its child gates (sometimes called sub-steps).

The key rule to remember: child gates are not protected individually the way ordinary completed gates are. They live and die with the package instance they belong to.

• Running package instances are kept. They are not torn down.

• Each running instance is brought into line with the current package design:

  • Child gates (steps) that are no longer part of the package are removed — even if they had already been completed. This is important: in a still-running instance, a finished step is not protected. If you take that step out of the package design, Merge will delete it from the instance and its completed history is lost.

  • Steps that have been added to the package are added to the running instance.

• Completed package instances are frozen and left untouched — once every step in an instance is finished, Merge does not change it, even if the package design changed.

• After any step is added or removed, the package's overall completed/blocking state is recalculated.

So Merge keeps in-flight package instances running and simply re-syncs their steps to the latest design — but be aware that re-syncing can remove completed steps from a still-running package instance when those steps no longer belong to the package.

Worth highlighting: people often assume Merge never deletes completed work. That holds for ordinary gates and for fully-completed package instances, but not for a completed step inside a still-running package instance — if that step has been removed from the package design, Merge will delete it.

• Completed package instances survive untouched — a fully finished package instance and its finished steps are kept.

• Any package instance that was still running is rebuilt from scratch. Because Force recreates the package's parent gate, the running instance is detached and removed, and with it all of its child gates — including the steps that had already been completed. The package instance is then recreated clean from the current design.

In short: running a Force apply on a project with a half-finished package instance will wipe out the completed steps inside that instance. Only fully completed package instances keep their history under Force. This is the main reason to prefer Merge unless you specifically need a full reset.

• Start with Merge. It's safe, preserves work, and is correct for almost every roll-out.

• Only choose Force when a project is genuinely misconfigured or has drifted, and you understand that in-progress gates and partly-finished package instances will be reset.

• If a project has active, partly-completed package instances, be especially careful with Force — consider whether those instances should be allowed to finish first.

• Both modes only ever apply to projects that match your chosen filters. Leaving all filters empty targets every eligible project, so check the "Apply To … Projects" count before you confirm.

• Both modes always keep completed top-level gates — neither mode deletes signed-off decisions on ordinary gates.

• Every apply run is recorded for audit (who ran it, which mode, the filters used, and how many projects were affected).