You basically want to:

1. Deploy a “clean” version to QA (without some DEV changes), and
2. Later restore those excluded changes back into DEV.

In OutSystems O11 (with LifeTime) you don’t have Git‑style branches, so you need to manage this via versions and/or hotfix-style workflows. Here are the main options and trade‑offs.

1. Use the plan as a snapshot and keep coding in DEV

Important concept: A LifeTime deployment plan “freezes” the versions it will deploy. Even if you change DEV afterwards, the plan will still deploy the versions that were current when you created the plan. Changes after deployment plan creation

So one approach is:

1. Create the deployment plan to QA when DEV is in the exact state you want.
2. Keep developing in DEV (tickets etc).
3. When the other team executes the plan, QA will receive that previously frozen version, not your later DEV changes.

In this approach, you do not need to remove anything from DEV. The “removal” is logically what the deployment plan does by using the older versions. After deployment, your newer DEV changes are still there.

Use this if:

• The DEV version you planned is exactly what you want in QA.
• The “ticket-related” changes happened after you created the plan.

If the “unwanted” changes were already part of DEV before you created the plan, then this alone doesn’t solve it.

2. Temporarily revert DEV to the version you want in QA

If the unwanted ticket changes are already in the DEV version you used for the plan, then:

1. In DEV, open the module in Service Studio.
2. From the module’s history (Manage Dependencies → Versions or via LifeTime), open the last “good” version (before the ticket changes).
3. Publish this older version in DEV.
   • Now DEV matches what you want in QA.
4. Create your deployment plan (or update it) so QA will get this “clean” version.
5. After QA deployment succeeds, re-apply the ticket changes by:
   • Either redoing the changes manually, or
   • Opening the newer version (with the ticket changes) and using Compare & Merge to bring them back in.

This is effectively a manual “branch” based on versions.

Risk: if you forget which version had which changes, this can get confusing. Good naming/notes on published versions help.

3. Treat the QA fix as a hotfix and later propagate back to DEV

If what you really want is:

• QA (and later PROD) should get a smaller, controlled set of changes,
• DEV continues carrying bigger ongoing work,

another pattern is hotfix-like propagation: Production Issues

1. Clone or open the current QA version in Service Studio.
2. Implement only the required fixes/changes (those tickets you do want).
3. Publish to QA.
4. Later, propagate those changes “forward” to DEV using Compare & Merge, so DEV gets them without losing its ongoing work.

This is very similar to OutSystems’ Apply a Hotfix pattern (fixing in a higher environment and then merging back). Production Issues

4. Feature toggles (to avoid “removing” things at all)

For long‑running or risky features that must not go to QA/PROD yet, a common best practice is to always deploy them, but keep them disabled with feature flags: Prevent deploying code through environments

Typical implementation:

• Use a Site Property or a config entity as a “FeatureEnabled” flag.
• Wrap screens/actions/logic for that feature with If FeatureEnabled conditions.
• In DEV you set it to True, in QA/PROD to False until you’re ready.

Then:

• You can safely deploy everything up the pipeline.
• You never need to “remove” and “re-add” code; you just toggle the feature on/off per environment.

This is usually more sustainable once you start having overlapping work streams.

What I’d recommend for your case

Given your description:

• If your deployment plan was created before the ticket changes:

  • Just use that plan as‑is; it will deploy the old versions to QA and you don’t need to remove anything from DEV.

• If you already included the unwanted changes in the plan:

  • Revert DEV (and/or the plan) to the desired version (option 2 above), then recreate the plan.
  • After the QA deployment, re-merge the ticket changes back into DEV using Compare & Merge.

For future work, consider adding feature toggles around long‑running features so you don’t have to manage this via removals and re‑adds.