Siren

Migrate a Tiered Program Group to a Cascade

Convert a two-program tiered program group into a single program bound to a linear-chain collaborator group with an Upline Cascade.

Last updated: June 7, 2026

The tiered affiliate program recipe builds tiers by stacking two programs inside a program group. Standard affiliates earn one rate, VIP affiliates earn a higher one, and the program group makes sure only one program fires per sale. That shape works, and on the Essentials tier it is the right shape.

On Siren Pro there is a different model that removes the second program and the promotion churn that comes with it. You bind one program to a linear-chain collaborator group and use the Upline Cascade calculation strategy. Tiers stop being separate programs a collaborator gets moved between, and become positions in an ordered chain. This guide walks the conversion.

This is the migration that the tiered affiliate program recipe and what is a cascade point you toward. Read both first if you want the conceptual background before you start.

Before you migrate, decide whether you should. This is not a like-for-like conversion, it changes who gets paid. The program-group model pays the seller a higher rate on their own sales. The cascade model pays the people above the seller an override on the seller’s production, and the seller earns nothing from the cascade itself. If your tiers are only about giving a collaborator a better rate on their own sales, with nobody earning above them, do not migrate. Stay on the program-group model. Migrate only if your tiers are really about who earns an override on whose production. The trade-off is explained in full below.

Why switch

The program-group model treats a tier as a rate bracket. Each tier is its own program with its own rate, and a collaborator belongs to exactly one tier at a time. Promotion means editing membership: you remove the collaborator from the Standard program and add them to the VIP program. During the handoff a collaborator can briefly appear in both, which is why the program group exists, to keep only one program firing per sale.

The cascade model treats a tier as a position. There is one program, bound to one ordered chain of collaborators, and a collaborator’s place in the chain determines how rewards flow around them. There is no second program, no program group to keep the tiers mutually exclusive, and no membership churn when someone moves up. You reorder the chain.

The trade you are making is worth being clear about. The program-group model pays the seller a different rate depending on their own tier. The cascade model pays the people positioned above the seller, at a score that depends on their distance from the sale. If your “tiers” are really about who earns an override on whose production (a manager earning on a rep’s sales, a director earning on a team’s production), the cascade is the more direct fit. If your tiers are purely about giving one collaborator a higher rate on their own sales with nobody earning above them, the program-group model is the better match and you should stay on it. See when to use a cascade for the cases the cascade is built for.

Before and after

Before, you have two programs in a program group.

{
  "programs": {
    "standard": {
      "name": "Standard Affiliate",
      "incentiveType": "saleTransactionPercentage",
      "incentiveArgs": { "transactionPercent": 10 }
    },
    "vip": {
      "name": "VIP Affiliate",
      "incentiveType": "saleTransactionPercentage",
      "incentiveArgs": { "transactionPercent": 25 }
    }
  },
  "programGroups": {
    "affiliateTiers": {
      "name": "Affiliate Tiers",
      "sorter": "newestBindingWins",
      "programs": ["standard", "vip"]
    }
  }
}

After, you have one program bound to a linear-chain collaborator group, with an Upline Cascade and per-layer points. The program group is gone, because there is only one program left and nothing to keep mutually exclusive.

The two tier rates (10% and 25%) no longer live on two programs. They become per-layer point values on a single cascade, where the layer is the distance up the chain from whoever made the sale.

How tiers map to chain positions

In a linear chain, every member carries an integer position in their metadata. Lower numbers sit closer to the top. Position 1 is the head of the chain, position N is the tail. Upline means walking toward lower positions, so the member at position 4 has position 3 as their layer-1 upline, position 2 as layer 2, and position 1 as layer 3.

Translate your tiers into an order, top tier first. The collaborator who would have been at the top of your promotion ladder goes at position 1. The next tier down goes at position 2, and so on. A new affiliate joins at the tail, the same way a new affiliate started in the Standard program before.

When an Upline Cascade is bound, the per-layer points decide what each position earns when someone below them makes a sale. Layer 1 is the direct upline (one step toward the head), layer 2 is two steps up, and so on, up to a maximum of five layers. You set pointsAtLayer1 through pointsAtLayer5. A layer set to 0, or left unset, stops the cascade, so nothing past that layer is credited. That zero is the lever for “only pay this many layers deep.”

For example, if you want the immediate upline to earn the most and the layer above that to earn less:

  • pointsAtLayer1: 100
  • pointsAtLayer2: 50
  • pointsAtLayer3: 0

A sale by the member at the tail credits their layer-1 upline 100 points and their layer-2 upline 50 points. Layer 3 is 0, so the cascade stops. The member who made the sale earns nothing from the cascade, because the triggering collaborator is never credited by it. Their own payout, if they should have one, comes from a separate calculation strategy (usually fixed) bound to the same program.

How per-layer points become payouts

The per-layer numbers are scores, not dollars on their own. They feed into whatever incentive structure the program uses to turn scores into payouts, which is the same decision you made when you set the rate on each tiered program.

With a fixed-per-incentive structure, each layer’s points become a literal payout, so 100 points pays out as a fixed amount you configure. With a performance-weighted pool, the scores become weights for splitting a fixed pool, so 100/50/25 becomes a 4:2:1 split of whatever the pool holds. Pick whichever matches how you want the old tier rates to translate.

Step-by-step conversion

  1. Confirm you are on Siren Pro. Linear-chain collaborator groups and cascade calculation strategies are Pro features. The program-group tiered model runs on Essentials, so if you are not on Pro yet, leave the existing setup in place until you upgrade.
  2. Create a collaborator group and set its structure to Linear Chain. See create a collaborator group for the full walkthrough.
  3. Add your collaborators to the group. These are the same WordPress users who were enrolled in your Standard and VIP programs, so no new accounts are created.
  4. Drag the members into tier order, top tier first. The top of the list becomes position 1. Siren writes the positions from the visual order when you save, so you do not type position numbers by hand.
  5. Pick the single program you will keep. You can reuse the Standard program or the VIP program as the base, since you are about to replace how its reward is calculated. Bind that program to the collaborator group you just created.
  6. On the program’s edit screen, set the calculation strategy to Upline Cascade. The strategy only appears in the picker when the bound group is a linear chain or parent-child structure, because a flat group has no layers to walk.
  7. Set the per-layer points. Translate your old tier rates into pointsAtLayer1 through pointsAtLayer5, leaving the layers you do not need at 0. Configure how scores become payouts (a fixed amount per point, or a pool split) to match the rates you charged before.
  8. Keep the seller earning on their own sales. In the old model each seller earned their tier rate on their own sales. The cascade never credits the seller, only the people above them, so without this step sellers stop earning on their own production entirely. Bind a separate calculation to the same program for the triggering collaborator’s own payout, using the incentive that matches what they earned before: a percentage of transaction to reproduce a percentage rate, or a fixed amount for a flat one. Note that this own-sale rate is now uniform across the chain. The per-tier difference in what sellers earned on their own sales does not survive the move to a cascade, which is the trade-off described above.
  9. Deactivate the second program and the program group. Once the single program with its cascade is live, the second tier program and the program group that bundled them are no longer needed. Set them to inactive rather than deleting them, so the historical conversions and obligations they credited stay intact as a record of what was already paid.

What is preserved and what is rebuilt

Preserved without changes:

  • Collaborator accounts. Every collaborator is a WordPress user, and that user account is untouched. You add the same people to the new group.
  • Tracking aliases. Referral codes and coupon codes are stored as aliases on the collaborator, not on the program, so published links keep working.
  • Historical conversions and obligations. Records created by the old programs stay as history. The conversion shows which program credited it, so past earnings remain visible.

Rebuilt during the migration:

  • The two tier programs collapse to one program with a cascade calculation. The rate that used to live on each program becomes a per-layer point value.
  • The program group is removed. It existed to keep the tier programs mutually exclusive, and with one program there is nothing to keep exclusive.
  • Promotion changes from a membership edit to a position change. Instead of moving a collaborator from the Standard program to the VIP program, you reorder them within the chain. Removing someone from the middle shifts the positions below them up so the chain stays contiguous.

One detail to plan for. Switching an existing collaborator group’s structure does not migrate per-member metadata, so if you reuse a group that was previously flat and switch it to Linear Chain, the existing members come across but their position is unset until you order them. Set the order explicitly after the switch. If you create a fresh Linear Chain group, as the steps above do, you order members as you add them and this does not apply.